High cardinality and the (other) row
Every analytics tool has limits on how many distinct values a dimension can hold in a report. When a high-cardinality dimension — like full URLs or custom IDs — exceeds the limit, the overflow is bundled into an aggregate (other) row. Detail you expected vanishes into it, and totals look complete while breakdowns are not. This page explains the cause and the workarounds.
Why (other) appears
Reports cap the number of distinct values a dimension can show. Dimensions with very many unique values — full page URLs with query strings, search terms, IDs, or unbounded custom dimensions — blow past that cap. Everything beyond the limit is grouped into a single (other) row that preserves the total but loses the per-value detail.
The total still adds up, which is why this is easy to miss: the breakdown is incomplete even though the sum looks right.
- Reports cap distinct values per dimension
- High-cardinality dimensions overflow the cap
- Overflow collapses into one (other) row
Reducing it
Lower cardinality where you can: strip volatile query parameters, group values into sensible categories, and avoid stuffing unbounded identifiers into custom dimensions. Use a more specific date range or filter to bring the value count under the limit, or query the raw events directly when you need a value that is hiding in (other).
How it appears in analytics and logs
A large (other) bucket in a breakdown means many distinct values were collapsed for cardinality, not that the underlying traffic is unknown.
Diagnostic use case
Recognise when a large (other) row means a dimension exceeded cardinality limits, so missing detail is understood rather than mistaken for missing traffic.
What WebmasterID can help detect
WebmasterID's Event Explorer works on underlying events, so you can investigate specific high-cardinality values that a standard report would fold into (other).
Common mistakes
- Reading (other) as unknown traffic rather than collapsed detail.
- Putting unbounded IDs into a dimension and exceeding limits.
- Leaving query strings in URLs, exploding cardinality.
Privacy and accuracy notes
Cardinality limits are a reporting constraint; high-cardinality custom values should still avoid carrying personal identifiers in the first place.
Related pages
- 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.
- An analytics data-validation checklist
Before you act on a report, validate the data that produced it. This checklist walks the recurring failure points — duplicate tags, unfiltered bots, internal traffic, wrong time zone, broken events, sampling — and gives a concrete check for each. Run it after any tracking change and periodically, so a metric you trust is a metric you have verified.
- Pageviews: what the metric counts
A pageview is recorded when a page is loaded (or a virtual page is rendered in a single-page app). It is the oldest web-analytics metric and the easiest to misread: pageviews count loads, not people, and modern apps and prefetching can inflate or hide them. This page defines the metric and its caveats.
- Event Explorer
Reach values a standard report folds into (other).
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.