Cardinality / (other) Row

Analytics

Also: High Cardinality · (other) in GA4 · Cardinality Limit

What it isData bucketed into (other) when rows exceed limits
Caused byToo many unique values in one dimension
EffectReports show less detail than reality
FixReduce dimension values or use BigQuery

Quick definition

Cardinality refers to the number of unique values a dimension can hold in an analytics report. When that count exceeds the platform's row limit, Google Analytics 4 (GA4) groups the overflow into a single row labelled (other), hiding the detail behind a catch-all bucket.

How it varies across Australia

The (other) row appears more often than most teams realise. Sites with large product catalogues, complex URL structures or poorly governed UTM parameters are most exposed. The share of traffic disappearing into (other) tends to grow quietly over time rather than arriving all at once.

See data and tracking scores across Australian industries

What it actually means

Every analytics report has a row limit. In GA4 standard reports that limit sits at a few hundred rows per dimension. When the number of unique values in a dimension exceeds that limit, GA4 stops listing them individually and dumps the remainder into a single (other) row. This is cardinality causing data loss in plain sight.

High cardinality dimensions are the usual culprits. A page path dimension on a large ecommerce site might have tens of thousands of unique URLs. An event parameter that captures free-text input, or a UTM campaign field populated differently by every team member, will blow past the row limit fast. The (other) row absorbs all of it without warning.

The practical effect is that attribution, conversion rate analysis and campaign reporting all become unreliable for the traffic hiding in (other). You can see total conversions. You cannot see which pages, campaigns or sources they came from if those rows were bucketed.

GA4 is not unusual in having cardinality limits. Google Ads, Meta Ads Manager and most data visualisation tools enforce similar caps. The difference is that GA4 makes the problem visible by labelling the bucket (other), while other platforms simply drop the rows silently.

The clean fix is to export raw event data to BigQuery, where cardinality limits do not apply. The operational fix is to govern the dimensions that feed your most important reports, keeping UTM values, event names and custom dimensions to a manageable set of controlled values.

The (other) row is not a reporting quirk. It is a data quality problem wearing a label.

How it shows up

The (other) row appears at the bottom of GA4 exploration reports and standard reports when a dimension has more unique values than the row limit allows. The percentage of data in (other) tells you how much detail is hidden. If (other) accounts for a meaningful share of sessions or conversions in a report, the numbers above it are incomplete.

You can spot cardinality problems in GA4 by checking the data quality icon (the orange exclamation mark) in the top-right of an exploration. GA4 also surfaces a cardinality warning in the exploration settings when limits are being hit. In BigQuery exports, every event row is retained regardless of dimension cardinality, which is why direct BigQuery queries are the authoritative source when standard reports show (other).

The Australian context

Australian ecommerce sites often hit cardinality limits faster than equivalent US peers because product catalogue URLs tend to include state-specific or postcode-specific parameters. A URL like /product/123?state=nsw&postcode=2000 creates a unique page path for every state and postcode combination, inflating dimension cardinality across the entire catalogue without any tracking intentionality.

Where people get this wrong

Ignoring the (other) row because the total numbers look right.Totals can still be accurate while the breakdown underneath is useless. The (other) row hides the distribution, not the sum.
Using free-text fields as UTM campaign or content values.Every unique string creates a new dimension value. A campaign field filled in ad hoc by different people generates dozens of near-identical values that fragment reporting and accelerate cardinality limits.
Assuming BigQuery export solves everything automatically.BigQuery removes cardinality limits but requires clean event schema design. Exporting poorly structured events to BigQuery produces unlimited rows of data that still cannot be analysed cleanly.

Related terms

Common questions

Why does GA4 show an (other) row in my reports?

GA4 limits how many unique dimension values it shows per report. When your data has more unique values than the row limit allows, the overflow gets grouped into a single (other) row. It usually appears when dimensions like page path, campaign name or custom parameters have too many unique values.

How do I get rid of the (other) row in GA4?

The cleanest fix is exporting your events to BigQuery, where cardinality limits do not apply. For standard reports, reduce the number of unique values in high-cardinality dimensions by standardising UTM parameters, cleaning up URL structures and consolidating custom event parameters.

Is cardinality the same as data sampling in GA4?

No. Cardinality groups too-numerous dimension values into (other). Sampling reduces the number of events analysed for very large queries. Both distort reports but they are different problems with different fixes. BigQuery resolves both.

Does the (other) row affect conversion tracking?

Yes. Conversions from sessions or campaigns that fall into (other) are counted in the total but cannot be attributed to a specific page, source or campaign. If a meaningful share of your conversions come from (other), channel-level and page-level conversion analysis is unreliable.

Keep exploring

About New Rebellion

New Rebellion is a marketing intelligence consultancy. We build tools, score Australian businesses on how their marketing actually performs, and publish Debrief every day. This dictionary is part of how we work in the open.

How we think →