When you view a report that surfaces a large amount of data, you might notice less common values grouped under an (other) row. In this article, you’ll learn why Google Analytics uses the (other) row and how to avoid and address the (other) row when it appears.
Overview
Behind the scenes, Google Analytics loads the data in your standard reports and the Data API using pre-processed database tables. For example, when you open the Landing page report, an underlying database table includes the Landing page dimension and each default metric in the report. By using pre-processed database tables, Analytics is able to surface your data quickly, allowing you to reference the information you care about more easily.
In contrast, explorations load your raw event and user-level data directly without relying on pre-processed database tables. By surfacing your raw event and user-level data, Analytics is able to surface more detailed results, though it may take more time to load.
What causes the (other) row
Google Analytics sets limits on the amount of data in the underlying database table used for a standard report. If you collect data that has more unique values than the row limit for the table, Google Analytics will group together the less frequent values and label them as (other).
For example, let's say you have two dimensions in a table — the Device dimension with 3 unique values (i.e., desktop, tablet, mobile) and the Age dimension with 6 unique values (i.e., 18-24, 25-34, 35-44, 45-54, 55-64, 65+). Additionally, you have collected data for all possible combinations of the two dimensions (i.e., a user is 18-24 and uses a desktop, another user is 18-24 and uses a tablet, and so on). In this example, the table will have 18 rows (or 3 x 6). If the limit on the table were 15, then the last 3 rows would be grouped together under (other).
session_source=S1, session_medium=M1, user_count=200
session_source=S2, session_medium=M2, user_count=100
session_source=S3, session_medium=M3 user_count=10
session_source=S4, session_medium=M4, user_count=5
session_source=S1, session_medium=M1, user_count=200
session_source=S2, session_medium=M2, user_count=100
session_source=(other), session_medium=(other), user_count=15
What are the limits
The limits for standard reports vary depending on the following:
- The property type: Analytics 360 properties have higher limits when compared to the limits for standard properties. The exact limits vary depending on the following other factors.
- The individual report: Some reports (for example, the Pages and screens report) have higher cardinality dimensions, and therefore have higher limits.
- The complexity of the report: While a standard report with one dimension is rarely affected by an (other) row, reports with secondary dimensions, filters, or comparisons are more likely to include an (other) row. This is because they need database tables with many dimensions. Properties with large and complex data are more likely to exceed the cardinality limits.
Best practices to avoid the (other) row
The following are best practices you can follow to avoid the (other) row:
Use predefined dimensions
- Use predefined dimensions before you create custom dimensions. For example, use the predefined gaming dimensions (e.g., Character, Virtual currency type) instead of setting up custom dimensions for the same data.
- Only collect dimensions with 500 or more different values when necessary. These dimensions will affect the table limits used by many other dimensions. When you include a dimension with more than 500 different values in a report, the row limit could apply to most of the data in the property when you use a custom report or add filters, secondary dimensions, or comparisons in a standard report. Sometimes, data that isn't shown in the report contributes to the row limit.
- Avoid using a custom dimension to create a distinct identifier for each user. Instead, use the User-ID feature.
Use standard reports
- Use standard reports whenever possible because standard reports have aggregate tables that decrease the likelihood of data rolling up under an (other) row.
- If you see an (other) row in a report, consider looking at the same data in explorations. If you use Analytics 360, and an exploration begins to sample data, you can request unsampled exploration results.
Address the (other) row
There are a few things you can do when you see the (other) row. The following provides a brief description of when to use each option:
| Option | What it is | When to use it |
|---|---|---|
| Create an exploration | If you see the (other) row, you can open the data quality icon at the top of the report and click Create an exploration. This option creates an exploration with the same query applied at the lowest sampling rate. | Consider this option for one off-questions, or when you want to investigate data with filters or comparisons. |
| Export your data to BigQuery | You can link your property to BigQuery Export and request the same data in BigQuery. Learn more | Consider this option to avoid the (other) row and for unsampled results. |
|
Automatic expanded data sets (Google Analytics 360 only) |
If data repeatedly groups into the (other) row in a commonly viewed report, Analytics enables automatic expanded data sets. Learn more |
You don't need to take an action to use automatic expanded data sets. |
|
Expanded data sets (Google Analytics 360 only) |
When you request an expanded data set, Analytics creates a special table for the report going forward. Since you can only create up to 100 expanded data sets, you should use them for your most frequently accessed reports. Learn more |
Consider this option for reports you plan to use repeatedly. |
