How data is stored and displayed

[GA4] About the (other) row

What is the (other) row

The (other) row is a row that appears in a report, exploration, or Data API response when the number of rows in a table exceeds the table's row limit. When this happens, Analytics surfaces only the most common dimension values and condenses less common values under the (other) row.

For example, if the row limit for the table supporting the Pages and screens report is 100k, but the property has 150k unique pages, then Analytics will sort the rows from most to least common and then group together the last 50k rows under the (other) row.

Note: You might notice that, sometimes, the values of the ‘(other)’ row can appear the same as of the ‘other’ row.

Why you see the (other) row

Each dimension in Analytics can have a number of assigned values. The number of values assigned to a dimension is its cardinality. For example, the Is key events dimension might have 2 assigned values ('true' or 'false'). In contrast, the Page path dimension might have a different value for each URL path on your website.

Many tables include multiple dimensions. For these tables, the number of rows needed can be as many as the multiplication of the number of values for each dimension. For example, if a report includes the Device dimension (3 values: desktop, tablet, and mobile) and the Age dimension (6 age groups), then the table can have up to 18 rows, depending on if you collect data for each combination of the dimension values.

Any dimension with more than 500 values should be considered a high-cardinality dimension, as it will significantly increase the cardinality of all the tables storing that dimension, and increase the likelihood that those tables will have some data condensed in the (other) row. The 500 values per dimension is not a limit, but a guidance. The most values collected for your dimensions, the higher the risk of having data condensed in the (other) row.

Note: You may see “other” and “(other)” in your reports. Both values are used to express high-cardinality and there is no significant difference between them.

What are the limits

The table row limit varies depending on the following factors:

Property type: Analytics 360 properties have higher limits when compared to the limits for standard properties.
Individual report or exploration: Some reports (for example, the Pages and screens report) have higher cardinality dimensions, and therefore have higher limits.
Query complexity: 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 best practices can help you reduce the likelihood of seeing the (other) row:

Use existing dimensions before you create custom dimensions. For example, use the predefined gaming dimensions (for example: Character, Virtual currency type) instead of setting up custom dimensions for the same data.
Don't use high-cardinality dimensions unless necessary since these dimensions will get your property closer to, or beyond, the row limits.
Don't use a custom dimension to create a distinct identifier for each user. Instead, use the User-ID feature.
Use standard reports whenever possible because standard reports have aggregate tables that decrease the likelihood of data being condensed under an (other) row.

Note: You may see a warning about the (other) row in the data quality icon, but no (other) row appears in the report or exploration. This may happen when the (other) row affects the results, but is not necessarily visible in your current view. For example, if you've applied a filter to the report that hides results grouped under the (other) row, you won't see the (other) row but you will see the warning.

If you need to measure high-cardinality data, consider sending the data through event parameters and user properties, without registering the data in custom dimensions. By not registering custom dimensions, you can still use the data in BigQuery, Audiences, Segments, and other features, without affecting the property limits.

Was this helpful?

How can we improve it?