Parameter cardinality and high-cardinality rows
Cardinality is the number of distinct values a parameter or dimension takes. When an event parameter has very high cardinality — many unique values — reports can exceed row limits and collapse the overflow into an (other) row, hiding detail. Understanding cardinality helps you design parameters that stay analysable: bucket continuous values, avoid unique-per-event strings, and reserve high-cardinality fields for where they are truly needed.
What cardinality is
Cardinality counts how many distinct values a field holds. A boolean has cardinality two; a free-form search term can have thousands. GA4 has row limits per report and per dimension; when distinct values exceed the limit, the surplus is grouped into an (other) bucket (Google Analytics Help on high cardinality). So a parameter's cardinality directly controls how much per-value detail you can actually see.
Designing for analysability
Keep parameters analysable by bucketing: report price bands instead of exact prices, page templates instead of every URL, coarse categories instead of free text. Reserve genuinely high-cardinality fields (like transaction_id) for joins, not for slicing reports. Lower cardinality also reduces the chance a value is unique enough to identify someone — a privacy benefit alongside the reporting one.
- Cardinality = number of distinct values
- Overflow beyond row limits lands in (other)
- Bucket values; avoid near-unique strings as dimensions
How it appears in analytics and logs
A large (other) row in a report signals the dimension's cardinality exceeded the row limit, so individual high-cardinality values are aggregated away.
Diagnostic use case
Keep reports from collapsing into an (other) row by limiting parameter cardinality — bucketing values and avoiding unique-per-hit strings as dimensions.
What WebmasterID can help detect
WebmasterID favours coarse, aggregate dimensions; the cardinality trade-off applies to any event system and is documented here for report design.
Common mistakes
- Using free-text or unique IDs as report dimensions.
- Ignoring a growing (other) row in reports.
- Sending near-unique values that risk identifying users.
Privacy and accuracy notes
Very high-cardinality values can edge toward identifying users. Avoid near-unique parameters; keep values coarse and non-identifying. This is educational, not legal advice.
Related pages
- Event parameters: adding context safely
Event parameters are the key-value details attached to an event: which button, which product, which step. They are what turns a bare event name into something analysable. The craft is choosing a small, stable set of parameters with consistent names and values — and the discipline is keeping every one of them free of personal data, because parameters are stored and widely visible in tooling.
- Item-scoped event parameters
Item-scoped parameters are parameters attached to each entry inside an e-commerce event's items array — item_id, item_name, price, quantity, and custom item parameters — describing the product rather than the event as a whole. They contrast with event-scoped parameters that describe the event (currency, value, transaction_id). Knowing the scope determines where a parameter belongs and how it can be reported in GA4.
- Analytics sampling: when reports estimate
Sampling is when an analytics tool computes a report from a fraction of the data and extrapolates. It keeps big queries fast, but it adds estimation error — worst for small segments and rare events, where a few sampled sessions get scaled into a confident-looking number. Knowing when a report is sampled is the first defence.
- Event Explorer
Design parameters that stay analysable.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.