GA4's (other) Row: How Cardinality Hides SaaS Data

You open a GA4 report to find the page path that drives your best conversions, and instead of the path you see a line labelled (other) holding a huge chunk of your traffic. The data is not gone — GA4 collected it — but at the report level it has been swept into an anonymous bucket you cannot break down. This is cardinality collapse, and for SaaS products it hides exactly the values you most want to see, because SaaS URLs and identifiers are high-cardinality by nature.

This post explains what the (other) row is, why high cardinality triggers it, how one bad dimension poisons reports it does not even appear in, why the problem lands hardest on SaaS analysis, and how to fix it at the source. The takeaway: cardinality is a reporting-layer limit you manage by controlling what you send in, not a mystery you clean up after the fact.

What the (other) row actually is

The (other) row is GA4's overflow bucket. When a report would exceed its size limits, GA4 stops listing individual dimension values and groups the remainder into a single (other) line. Google's cardinality documentation defines the trigger: a dimension is high-cardinality when it has more than 500 unique values in a single day, and reports are capped at 50,000 rows per day. Past those thresholds, the tail of values is aggregated away, so the report still totals correctly but no longer shows you the parts.

The critical nuance is that this is an aggregation applied when the report is built, not a deletion at collection time. As practitioners tracking the behavior note, the underlying data “remains collected but is not individually visible.” That distinction matters for the fix: because GA4 still holds every raw event, the detail is recoverable through the event-level BigQuery export even though the standard interface will not show it. The (other) row is a symptom of the reporting layer's limits, not evidence that your tracking failed — a different failure mode from the outright gaps we cover in GA4 traffic under-counting.

What drives cardinality up

High cardinality comes from dimensions that take on a huge number of distinct values, and SaaS products manufacture them constantly. Page paths and titles that embed unique IDs are the classic source — every /invoice/48213 or /users/9f2a is a new value, so a product with thousands of objects generates thousands of unique paths a day. Full URLs with query strings multiply the problem, since each unique parameter combination counts separately. Custom dimensions holding user IDs or email addresses, and unbounded event parameters like search terms, do the same. Each unique value is one more row, and the count climbs past 500 far faster than teams expect.

The reason this catches people off guard is that the offending values usually look like the point of the analysis. You instrument the exact page paths, IDs, or campaign strings because you want to analyze them — and that specificity is precisely what pushes the dimension over the cardinality line. It is the same tension between richness and usability we describe in GA4's dashboard card limit and metric sprawl: more granularity is not free, and past a threshold GA4 stops rewarding it and starts hiding it.

How one bad dimension poisons the whole property

The most damaging property of cardinality is that it is not contained to the dimension that causes it. Because the 50,000-row limit applies to the total size of a report, a single high-cardinality dimension inflates the row count for the entire table — and can force even low-cardinality dimensions in the same property into (other). As practitioners put it, even one high-cardinality dimension can negatively affect the cardinality limit of most of the data you see, so you can hit the row limit even when the dimensions in your current table are all low-cardinality themselves.

That spillover is why cardinality is a property-level hygiene problem, not a per-report annoyance. A stray custom dimension capturing user IDs, set up once and forgotten, can quietly degrade the fidelity of unrelated reports across the account, and because each individual report still returns a plausible total, nothing announces the degradation. It is contamination that spreads from the source, the same structural pattern we flag in our work on the SaaS analytics data-quality audit, where the fix is always to constrain inputs rather than to keep patching outputs.

Why SaaS analysis is hit hardest

SaaS products are cardinality machines, and the values that overflow are usually the ones that matter. Your application URLs carry account and object IDs, so any attempt to analyze in-product behavior at the page level runs straight into the limit — the feature, screen, or workflow you want to measure is encoded in a path that is unique per record. When those paths collapse into (other), you lose the ability to see which specific surfaces drive activation or retention, which is the whole reason you were looking.

Attribution and content analysis suffer the most acute version of this. A campaign value or landing-page path hidden inside (other)cannot be credited, compared, or optimized, so channel reporting develops a blind spot exactly where a high-performing but high-cardinality campaign lives. And any conversion rate computed against a collapsed dimension is unreliable, because a large, unbreakable chunk of the denominator sits in a bucket you cannot inspect. This is why we treat cardinality as a first-class data-integrity issue rather than a cosmetic one, alongside the collection-layer defenses in the GA4 hostname include filter.

Fixing it at the source

The durable fix is to stop sending unbounded values into reported dimensions. Normalize page paths before they reach GA4 so /invoice/48213 becomes /invoice/{id}, turning a million unique URLs into one meaningful value you can actually analyze. Keep user IDs, emails, and raw search terms out of the custom dimensions you report on — those genuinely high-cardinality identifiers belong in the BigQuery export, not in the standard reporting layer. Use content grouping to roll detailed paths into the handful of categories you actually make decisions on. The target is simple: keep each reported dimension under 500 daily unique values so it never trips the collapse.

When you genuinely need per-value detail at high cardinality, go to the data layer built for it rather than fighting the report limits. The standard guidance for removing (other) is the BigQuery export, which holds raw event-level data with no cardinality aggregation, so you query every value directly. We walk through that pipeline and its trade-offs in decoding the GA4 BigQuery export problem. The two moves are complementary: normalize at the source to keep the standard reports clean and comparable, and reserve BigQuery for the genuinely high-cardinality questions that will always overflow a 50,000-row table.

A cardinality checklist for SaaS teams

Make it a short, repeatable audit. First, list every dimension you report on and flag the ones that can exceed 500 daily values — page paths with IDs, full URLs, and any custom dimension holding an identifier. Second, normalize those at collection: strip IDs from paths, drop query strings you do not analyze, and route true identifiers to BigQuery instead of a reporting dimension. Third, add content groups for the categories you actually use, so detailed paths roll up into values that stay well under the limit. Done once, this keeps the entire property's reports out of the(other) collapse.

Then make it recurring, because cardinality creeps back. A new feature ships a new URL pattern, a well-meaning teammate adds a custom dimension, and the property drifts toward the limit again — often degrading reports far from the change. Fold a cardinality check into the same cadence as your broader data-quality audit so someone confirms, each quarter, that the dimensions you depend on are still showing real values and not an anonymous bucket. Managed this way,(other) stops being a recurring surprise and becomes a limit you designed around — your product's real page paths, campaigns, and surfaces stay visible in the numbers your team acts on.