(other)
Analytics shows an (other) row when the table behind a report or exploration has more rows than its limit allows. It keeps the most common values and folds the rest into (other). Remove secondary dimensions, filters and comparisons first, use a standard report where one exists, then stop registering custom dimensions that hold a different value for every visit.
At a glance
- Where it shows
- In a report, an exploration or a Data API response, as a row named (other), sometimes written other.
- What stops
- Nothing stops. Every visit still counts in the totals, but the values grouped under the row cannot be read one by one.
- How serious
- No penalty. The grouped rows hide which pages, sources or campaigns sit inside them.
What it means
Every table in Analytics has a row limit. When a report needs more rows than that, Analytics sorts the values from most to least common, keeps the top ones, and puts the rest under (other). Google's example is a property with 150,000 unique pages and a 100,000 row limit, where the last 50,000 are grouped together.
The row is about how many distinct values the report has to hold, which Google calls cardinality. A dimension with two possible values adds little. A page path, a campaign name or a custom value that changes on every visit adds a row for each one, and a report that combines dimensions can need one row for every combination.
What actually triggers it
A secondary dimension, a filter or a comparison on the report
Google says a standard report with one dimension is rarely affected, while reports with secondary dimensions, filters or comparisons are more likely to show the row, because they need tables with many dimensions.
An exploration instead of a standard report
Google says standard reports have aggregate tables that make the row less likely, so the same question asked in an exploration can hit the limit sooner.
A custom dimension with a different value for every visitor or visit
Google's guidance treats any dimension with more than 500 values as high cardinality and warns against using a custom dimension as a distinct identifier for each user. A lead ID, a timestamp or a full address registered as a custom dimension does exactly that.
A large site or a busy property on a standard account
The limit depends on the property type, the report and the query. Google says Analytics 360 properties have higher limits than standard ones, and properties with large and complex data are more likely to pass them.
Fix it in this order
- Remove any secondary dimension, filter or comparison from the report and check whether the (other) row goes.
- If the question can be answered in a standard report, use that rather than an exploration.
- In Admin, under Custom definitions, look for custom dimensions that hold a unique value per user, visit or lead, such as an ID or a timestamp.
- Send those values as event parameters without registering them as custom dimensions, or use the User-ID feature for user identifiers.
- When every row is needed, read the data from the BigQuery export, where Google says unregistered parameters stay available without affecting the property limits.
Google notes the data quality icon can warn about the (other) row even when the row is not visible, for example when a filter hides it. The warning means the grouping still affects the numbers on screen.
Lead and call tracking is one of the things we sell, and it goes in before any ad budget is spent. A status like “(other)” is the kind of problem we fix as part of it.
Often confused with
The visit has no value for that dimension. Under (other) the values exist, but there were too many to show one by one.
A channel label for sessions no default channel rule claims. It has nothing to do with row limits.
Data thresholds applied
Analytics withholds rows to protect the identity of individual visitors, usually on smaller properties. (other) groups rows because there are too many of them.