6 October 2026·3 min read
When an (other) row appears in your reports — cardinality limits
Expand a dimension and one (other) row is holding a large number you cannot open. GA4 collapses the rest once a day's distinct values exceed the limit. What the offending values look like, and how to cut the variety at collection time.
Symptom
You expand a dimension in a report and, a few rows down, there is a single row labelled (other). The number on it is large. Clicking does nothing, and no filter will break it apart. The dimension was created precisely to compare individual pages or products, and the values you wanted are all inside that one row.
Open the same dimension in an exploration and it looks much the same. With no way to segment, there is effectively no analysis left to do with it.
Cause
GA4's standard reports do not read raw events; they read tables aggregated once a day. When the number of distinct values arriving in a day exceeds what that table can hold, GA4 keeps the top values as their own rows and merges everything else into a single (other) row. That is cardinality overflow.
What matters is the variety of values, not the volume of traffic. A quiet site still hits the limit if its parameters carry a different value on every hit. These are the shapes that turn up in real scans.
| What was put in the parameter | Why the daily distinct count climbs |
|---|---|
| Full URL including the query string | One page becomes a new value per ?utm_... / ?sid= combination |
| Order number, transaction id, member id | One new value per record |
| Timestamps, sort keys | Different every second |
| Product name concatenated with options | One per colour and size combination |
| Raw on-site search terms | As many as visitors type |
AnalyticScan looks at custom dimensions: how many distinct values arrive per day, and whether an (other) row is already present. Past 300 distinct values a day it warns; past 500, or with (other) already showing, it counts against the score.
Sending identifiers as-is creates a second problem. If an email address or phone number rides along inside those values, it stops being a cardinality issue and becomes a Google policy violation.
How to check in GA4
1) Narrow down which dimension. In the report showing (other), switch the dimension one at a time. Usually the built-in dimensions are fine and one specific custom dimension is the culprit.
2) Look at the shape of the values. Reading the top few rows of that dimension is normally enough. Trailing numbers, hashes or a question mark give it away.
3) Narrow the date range to a single day. The limit applies per day, so a month viewed at once hides the reason. A day at a time also shows when the growth started — typically a release date.
How to fix it
The fix belongs in collection, not in the report. There is no way around reducing the variety of values before they are sent.
- Normalise URLs. Strip the query string and keep the path, or turn paths that embed an id —
/product/10293— into a template such as/product/detail. - Keep identifiers out of custom dimensions. If you need to look up an individual order or member, that is a job for the BigQuery export, not for reports. The export keeps the raw event rows.
- Send products as groups. Replace the product name with category, price band or brand — values whose variety stops in the dozens. Per-product performance belongs to ecommerce
itemsdata and the item reports. - Use the built-in dimension for site search. There is no reason to receive the same value a second time as a custom dimension.
New values start arriving correctly the next day. What was already collapsed into (other) does not come back, though — GA4 does not recompute past data, so the detail for that period is gone for good.
In one line
(other) is not GA4 breaking; it is a signal that a dimension is receiving too many kinds of value. Check today whether your parameters are carrying identifiers or full URLs. Fix it now and today's data survives — yesterday's does not come back.