If you experience an issue with a chart, report, or data source, check this guide to see if it's listed, and if so, click Steps to resolve to learn how you might further investigate and fix the problem.

Basic hygiene steps

Some issues with Looker Studio can be caused by temporary network errors or backend glitches. Try these basic hygiene steps before you spend a lot of time troubleshooting a problem. After you try each step, check to see if the issue is resolved.

Possible errors / symptoms

Access issues

If you are a Google Workspace or Cloud Identity customer, your organization's administrator must enable Looker Studio before you can use it.

Possible errors / symptoms

Connection issues

Data connection issues can occur for several reasons. Some issues are expected, such as when you don't have the proper credentials to view the data in a data source that's been shared with you. Other reasons include broken or incomplete configurations, deleted data sources, loss of authorization to the data, and so on.

Try these steps to resolve problems connecting to your data set.

Possible errors / symptoms

Chart configuration issues

Charts with incomplete or incompatible chart configurations will display errors.

Possible errors / symptoms

User interface / functionality issues

If Looker Studio suddenly stops working or otherwise misbehaves, incompatible extensions or add-ons could be causing the problem.

Possible errors / symptoms

Blending issues

The most common issues people experience with blends can be put in the following buckets:

• Misconfigured joins
• Missing or incorrect data source connections
• Issues with / confusion over the blend results

Misconfigured join example errors / symptoms

Missing or incorrect data source connection example errors / symptoms

Google Analytics 4 quotas exceeded

Beginning November 7, 2022, Looker Studio reports that connect to Google Analytics 4 data are subject to Google Analytics Data API (GA4) quotas. You can monitor your report's GA4 data usage via the Google Analytics Token Usage dialog.

View token usage

1. Edit your Looker Studio report.
2. To see your report's overall token usage, right-click the report canvas, then choose Google Analytics token usage.
3. To see the token usage for a specific component, right-click the component, then choose Google Analytics token usage.

For the overall usage of Google Analytics 4 tokens, you can view:

• The number of quota tokens used by the entire report or per page for the current user session
• The number of quota tokens remain available before the quota is reached
• The number of quota tokens are consumed by each chart, sorted by those that use more tokens

For token usage by a specific component, you can view:

• The number of quota tokens have been consumed by each request
• The time that each request finished
• Whether or not the request was served from cache, where a red X indicates that the request was not served from cache and an encircled green checkmark indicates that the request was served from cache

Quota exceeded errors

Reports that exceed these quotas may display one of the following error messages:

Strategies for troubleshooting more complex issues

When you're trying to diagnose less obvious problems with Looker Studio, the first step is to identify where the problem is occurring.

For example, is the problem generalized, or is it restricted? Is it a problem with all your reports, or a specific report? Does it happen with every component type, or only with a specific component? Does the issue appear in multiple browsers or only in a specific version of a specific browser?

See also: What you need to use Looker Studio

The next step is to reduce the number of variables.

Generally, this means trying to isolate the problem to the fewest possible factors, by minimizing the data or simplifying the report. For example, if you suspect a problem with the data, try to use filters or edit the data set to reduce the number of rows by half. If the problem goes away but reappears when you include the other half of the rows, then you'll know the issue is somewhere in that second half of the data.

Similarly, if the problem is with a specific chart, first try creating a simple version of the chart with the minimum number of fields and simplest style options, and then gradually increase the complexity to see if the issue is caused by a specific field or setting.

Report a problem to Google

If you can't resolve the problem, you can report it to Google. To help us diagnose the problem, please be ready to provide the following information:

• A complete description of the problem.
• Steps to reproduce the problem.
• Any error messages or error IDs that appear.
• A link to a test report or data source that demonstrates the problem.

The speed with which a Looker Studio report loads and responds to viewer changes, such as applying filters or changing the date range depends on a number of factors, including:

• the performance of the underlying data set
• the amount of data being queried by the visualizations in the report
• the complexity of those queries
• network latency

Some of these factors are beyond your (or Looker Studio's) ability to control. For example, there may not be much you can do to improve the responsiveness of the underlying data platform or speed up your network connection. There are, however, some things you can do to fine tune your report performance in Looker Studio.

Adjust the data freshness rate

Looker Studio already uses some performance tuning features internally (and we are always working to make these better). For example, Looker Studio improves report performance by fetching the data from a temporary storage system called the cache. Fetching cached data can be much faster than fetching it directly from the underlying data set. Fetching cached data also minimizes costs for paid services, such as BigQuery, by reducing the number of queries that need to be served directly from the data set.

The frequency with which data in the cache is updated is called the data refresh rate. The actual refresh rates vary by connector, but if possible, consider making the refresh interval longer. This can help your report performance by using the cache to answer repetitive queries, the tradeoff being possibly not having the most up to date information.

Learn more about managing data freshness.

Use an extracted data source

By default, data sources maintain a live connection to your underlying data set. When the cache (described above) expires, or if you execute a new query that can't be served from the cache, Looker Studio goes to your data set to get the data. You can avoid these potentially slow data fetches by extracting up to 100MB of data from any existing data source into an extracted data source.

Choose the specific fields you need, apply filters, and add a date range to create a snapshot of your data. This can make your reports and explorations load faster and be more responsive than when working with a live connection to your data. The tradeoff here is that the extracted data source is static: your data won't change in the report until the data source itself is refreshed. This may only be a minor inconvenience though, as you can schedule an extracted data source to update automatically.

Learn more about extracting data.

Accelerate BigQuery data sources with BI Engine

BigQuery BI Engine is a fast, in-memory analysis service. By using BI Engine you can analyze data stored in BigQuery with sub-second query response time and with high concurrency.

BI Engine integrates with Looker Studio to accelerate data exploration and analysis. With BI Engine, you can build rich, interactive dashboards and reports in Looker Studio without compromising performance, scale, security, or data freshness.

Get started using Looker Studio with BI Engine.

You can display clickable links in your data using a table. There are 2 ways to get these links:

• Directly from your data set, using the URL field type
• Generating the link using the HYPERLINK function

URL field type

When you create a data source, Looker Studio will detect valid URLs in the data set and assign the URL field type to that dimension. (If Looker Studio doesn't detect the URLs automatically, you can set the field type to URL manually.)

URL fields display the full link in charts. In tables, this link is clickable.

HYPERLINK function

The HYPERLINK function lets you construct links in calculated fields. The HYPERLINK function takes a URL and a link label as input. The output is a clickable link when displayed in a table (in other charts, the link text is not clickable).

Only certain protocols are supported in both URL fields and the HYPERLINK function. See the HYPERLINK article for details.

At a glance

Have you seen this error message?

This error means you've asked Looker Studio to do something with an already aggregated ratio metric that it can't do. For example, you've applied a filter based on a calculated field to a chart that contains a ratio metric.

The solution is to select a non-ratio field in the chart (e.g., use Impressions instead of CTR), or remove or change the filter.

In depth

Ratio metrics show the relative sizes of two or more values. For instance, the Google Ads metric , e.g. Clickthrough rate (CTR) is the number of clicks that your ad receives divided by the number of times your ad is shown. In Google Analytics, Bounce Rate is single-page sessions divided by all sessions, while Entrances / Pageviews calculates the ratio of visitors entering your site and beginning a new session compared to the number of pageviews. 

In Looker Studio, you get the error above when you filter a chart that includes ratio metrics in a way that requires the product to recalculate the ratios.

Here are 3 things to help you understand this issue:

1) Data from data sets such as Google Analytics, Google Ads, YouTube, and Google Marketing Platforms products is already aggregated by the time it gets to Looker Studio. For example, when Looker Studio requests a Google Ads metric such as CTR (click-through rate), the data is already processed into the appropriate aggregation type.

2) Because of the above, calculated field functions are applied to your data post-aggregation. It's not possible (nor would it generally make sense) to go back into the raw data and look at every unique instance of that metric. For example, if you try to create a calculated field with the formula SUM(Impressions) in a Google Ads data source, you'll get the error:

Re-aggregating metrics is not supported.

That's because Impressions is already aggregated (and its aggregation type, Auto, can't be changed).

3) For consistency, all calculated field functions in Looker Studio are available for use with all data source types, even if the underlying system doesn't natively support that function. For example, you can use the CONCAT function to join multiple values in any data source, even if the underlying system doesn't have a CONCAT function of its own. Instead of "pushing down" the CONCAT function to the underlying system, Looker Studio requests the data and performs the concatenation itself.

Aggregation failure example

So what does all that have to do with the "Unable to aggregate ratio metrics" error? Let's go a little deeper with the CONCAT example to find out.

Suppose you create a calculated field called Campaign : Click Type in a Google Ads data source, using the following formula:

Looker Studio issues queries for Campaign and Click Type individually, and then performs the concatenation. The results are grouped, so there is no duplication of records.

You can now use that concatenated field in your charts, and the metrics you include are aggregated properly. For example, we could use Campaign : Click Type as the dimension and CTR as the ratio metric in a table:

But now, let's say you apply a filter to show only those records where the Click Type is Headline:

This will break the chart:

Why it breaks

The filter asks Looker Studio to include each record returned by the Campaign : Click Type if it contains "Headline." That field is a concatenation of 2 dimensions: to fulfill this request, Looker Studio has to refetch those dimensions, and then apply the filter. The problem is the presence in the table of the ratio metric, CTR. Google Ads ratio metrics are computed before Looker Studio requests them. Looker Studio has no way to access the raw data and recompute the new ratios for the records that just contain "Headline" in the concatenated field.

The solution

The solution in cases like this depends on the data you are trying to show. In this example, you could either replace the CTR metric with a non-ratio metric, such as Impressions. Or, instead of filtering on the concatenated Campaign : Click Type field, put the filter on just the standard Click Type field, which would achieve the same result.

The chart now works:

Related resources

Google Analytics Dimensions & Metrics Explorer

Google Ads Glossary

If your reports or data sources aren't showing all the information you expect, check the following:

Missing data in reports

Is the data cached?

If the report is missing some recently added data, you can refresh the cache by editing your report and in the upper right,  clicking  . You must be an editor of the report to use this feature.

Is the data filtered?

Edit the report, then click Resources > Manage Added Filters to see if there are any filter properties in the report. If there are, check their setup to make sure that's not the cause of the missing data.

Missing fields in data sources

Is the data source out of sync with the data set?

If the data source is missing some recently added fields (columns), you can add them by editing the data source, then in the lower left, clicking REFRESH FIELDS. Learn more. 

Is your Google Sheets data source missing rows or column?

If the rows (data) or columns (fields) of your Sheets data source are still not appearing after refreshing the fields as described above, make sure the data source connection includes the proper range and options. You must be the owner of the data source to do this.

1. Edit the data source.
2. On the left, click EDIT CONNECTION.
3. Review the connection options, on the right. Be sure any specified range includes all your data, and that you are including hidden and filtered fields, if appropriate.

Sheets connector options.

Is it a connector limitation?

Connectors based on fixed schemas, which includes many of the Google product connectors, may not deliver all the fields of the underlying data set. If your data source appears to be missing fields that you know are in the original product, it's possible that field is not supported in Looker Studio. You can check the issue tracker to see if the field has already been requested, or if not, file a feature request. 

Learn more about connectors.

To display metrics with negative values in a chart, set the Axis min option to (auto): 

1. Edit your report.
2. Select the chart.
3. Select the STYLE panel.
4. Locate the main axis settings: for default charts, this will be the left axis, but could also be right or bottom, depending on how you've customized your chart.
5. Change the Axis min value to (auto) by deleting the current setting. 

Here's an example of how charts look with Axis min 0 versus Axis min (auto):

1. Data in the top charts contains mixed negative and positive values.
   1. Charts on the left are set to use Axis min: 0.
   2. Charts on the right use Axis min: (auto).
   3. Note how the last two dimension values ("Green" and "Blue") appear in the charts.
2. Data in the middle charts only contains positive values. In this case, there is no difference between 0 and (auto) settings.
3. Data in the bottom charts only contains negative values. Here, using the (auto) setting on the right provides the correct visualization.

We recently (October 2019) made improvements to how fields in your data sources are defined and aggregated by default. These changes make it easier to model your data, and make calculated fields more robust.

You don't need to take any action. Charts and calculated fields used in your reports will work as before the upgrade.

What's changed?

We've made the following improvements:

Refined the definitions of "dimension" and "metric"

Dimension -- A set of unaggregated values by which you can group your data. As before, dimensions in your data source appear as green fields.

Metric -- A specific aggregation that you can apply to a set of values. Because a metric itself has no defined set of values, you can’t group by it. As before, metrics in your data source appear as blue fields.

You can treat any dimension as a metric in your charts: simply drag the field from the list to the metrics section of the chart configuration, then select the type of aggregation to apply. Dimensions containing non-numeric data (e.g. text, date) will be aggregated using Count Distinct (CTD).

 

Introduced default aggregation

We've changed the "Aggregation" column in a data source to "Default aggregation." This is the aggregation method that is used when you include that field in a chart in a Looker Studio report, unless you override it.

For data sources based on flexible schema data sets, such as Google Sheets, BigQuery, CSV file upload, etc., fields containing unaggregated numeric data appear as dimensions with a default aggregation of Sum. You can use these fields as either dimensions or a metrics in your charts. If used as a metric, the values are summed, however, you can still change the aggregation method in the chart itself.

Metrics in your data source always have a default aggregation of Auto, which can't be changed. This includes already-aggregated data from fixed schema data sources, such Google Analytics and Google Ads, as well as calculated fields you create that include a specific aggregation method.

Learn more about aggregation and data modeling.

Made calculated fields more robust

If you create calculated fields without specifying an aggregation function in the formula, the result is an unaggregated dimension. To create an aggregated metric, include the desired aggregation function. For example:

Profit / Revenue results in a numeric dimension. You can set the field's aggregation manually in the data source, or in charts that use this field.

vs.

SUM(Profit) / SUM(Revenue)results in a metric. The aggregation is Auto, and won't change even if the underlying fields' default aggregation changes.

Learn more about calculated fields.

Why do I see "deprecated" fields in my data source?

A small number of older data sources may contain fields marked as "deprecated." These are unaggregated numeric fields that have been copied and converted to dimensions with a default aggregation of Sum. The original fields still exist in the data source and still appear as before the upgrade in any charts or controls, but you won't be able to add them to new components.

Example of an upgraded data source.

In the example above, the original Price and Qty Sold fields have been deprecated (rows 8 and 11). Their original aggregation of Sum has been set to Auto (Sum). New, upgraded versions of those fields have been added to the data source (rows 7 and 10). These appear as numeric dimensions (green) with default aggregations of Sum.

The Order Total calculated field (row 9) still references the deprecated fields and still works as before. New calculations based on Price or Qty Sold should use the new fields, not the deprecated versions.

Filtering by email address works by comparing the address of the logged in viewer to a field in your data source that contains valid email addresses. For each row in your data, the filter checks to see if the viewer's email matches the address in that row.

Consider the following data:

If this data was filtered by email address, and alan@example.com viewed the filtered report, he'd only see the data
"abc" and "efg." If mary@example.com viewed the same report, she'd see the data "efg" and "ghi."

This is fine if you have a 1:1 relationship between viewers and the data. But what if you wanted also wanted manager@example.com to see the data? That is, you want many people to see the same rows of data. (This is known as a many:many relationship.)

Filter by email only works on one address per row, so you can't simply put a list of addresses in your email field. For example, this won't work:

Solution: Use data blending

You can create a many:many relationship between email addresses and your data by blending a table of addresses with your data, using any common field as a join key.

Fruit stand example

You manage a produce company, and want show your sales representatives how they are performing at the various fruit stands they service. Multiple sales people can service multiple stands. To filter the data so your sales people only see their data, you could do the following:

Step 1: Create an access control list table

In this step, you'll create an access control list (ACL) table that contains the email addresses of the authorized sales people, paired with a data field (a fruit stand name) that can be used as a join key in the blend.

Access control list (ACL) table

Note that salesrep1 can see data for Fruit Stand A and Fruit Stand B, while salesrep2 can see data for Fruit Stand A and Fruit Stand C.

Step 2: Create the data table

The data table tracks the sales each representative made to each fruit stand.

Data table

Step 3: Apply the email filter to the ACL table

Edit the data source for the ACL table and choose the Sales Rep Email field as the filter.

Step 4: Blend the ACL table with the data table

If you blend the ACL table with the data table with no email filter applied, you'll see all the records for both sales representatives. But with the email filter applied, blending the ACL table with the sales data table filters that data according to which sales person is viewing the report. Here's what each representative would see when they view the report:

Problem

A chart in your report displays an "Invalid field name error."

Why it breaks

Certain connectors support characters in their field names that Looker Studio is unable to process. For example, Looker Studio does not handle BigQuery fields that contain Unicode characters and special characters like ampersands, colons, and so on.

Learn more about BigQuery flexible column names.

Solution

To resolve this issue, rename the fields from the underlying dataset and then reconnect the data source.