The "(other)" row in GA4, and why it hides your best data
When a report shows a big (other) row, GA4 is not broken: it hit a limit on how many unique values it will keep and bundled the rest together. On high-traffic or high-variety sites, that can swallow exactly the detail you wanted.
What is really happening: cardinality
To keep reports fast, GA4 caps the number of distinct values (the "cardinality") it will store per dimension per day. Go over the cap, usually on dimensions like page path, item name, or a custom dimension with thousands of values, and everything beyond the top rows gets collapsed into (other). The data was collected; it just is not broken out.
Why it matters
If your long tail of products, landing pages or campaigns is where the interesting performance lives, (other) hides precisely the rows worth analysing. You end up optimising around your top ten and blind to everything else.
How to get the detail back
- Use the Explore reports instead of standard reports; they apply higher limits and can avoid (other) for the range you query.
- Narrow the date range so fewer unique values compete for the cap.
- For serious analysis, the BigQuery export has no cardinality limit at all, giving you every row.
- Prune noisy custom dimensions that explode cardinality for no benefit.
Knowing when (other) is harmless versus when it is masking your real performance is the kind of judgement a proper audit brings.
Want us to check your tracking in 10 seconds?
Pop in your domain and we will show you what is firing, what is not, and where data is leaking. Free, no signup.
Check my tracking freeGet a plain-English audit
We check your live GA4, Google Tag Manager and consent setup by hand and tell you exactly what is wrong. The audit comes off any build.
See how it works & pricingDatahound are analytics and ad-tracking specialists. We fix broken GA4, Google Tag Manager and server-side tracking so every sale, form and call gets counted. Back to datahound.agency · All tracking guides · GA4 data thresholding explained