High Cardinality

Cardinality is the number of unique values a dimension holds. Google defines a high-cardinality dimension as one with more than 500 unique values in a single day. High cardinality matters because every extra value adds rows to a report, and once a report exceeds its row limit, Google Analytics 4 hides the surplus behind a single row labelled (other).

The data is still collected. It is the report that runs out of room.

Why High Cardinality Matters

High cardinality costs you the long tail, which is usually the part you were looking for. GA4 keeps the highest-volume rows and collapses the rest, so your biggest campaigns survive and your small tests disappear into (other).

The failure is quiet. Nothing errors, no setting changed, and the tagging was correct. A dimension simply accumulated enough distinct values to push the table past its limit, and GA4 summarised instead of listing.

Two consequences follow. Totals stay correct, because (other) still counts the sessions and conversions it absorbed. Breakdowns do not, because you can no longer attribute those numbers to anything. Google notes that once values are combined this way, Analytics shows approximations in the affected breakdowns.

What Counts as High Cardinality

Google’s guidance is 500 unique values per day per dimension. That number is a warning line, not a hard limit: Google is explicit that a dimension crossing it is not blocked, only more likely to push a report into (other).

A rough working scale:

• Low cardinality: under 50 values. Device category, medium, country. Never a problem.
• Medium cardinality: 50 to 500 values. Source, campaign name, landing page on a small site. Safe alone, risky in combination.
• High cardinality: over 500 values a day. Page path with query strings, item ID, transaction ID, any custom dimension holding an identifier.

Separately, Google documents a property-level ceiling: “Google Analytics 4 has a cardinality limit of 50,000 values. Thereafter, cardinality control is implemented.”

One honest gap: Google does not publish the row limit for report tables. The documentation says only that it “varies depending on” property type and query complexity, and that Analytics 360 limits are higher. Exact figures circulate widely in the industry but are not in Google’s documentation, so treat any number you read as an estimate.

Dimensions That Go High-Cardinality First

The usual causes, roughly in order of how often they break a report:

• Page path or page location including query strings. Every unique parameter combination becomes its own value, so one page can generate thousands.
• Item ID and transaction ID. An ecommerce catalogue with hundreds of thousands of items produces exactly that many values.
• Custom dimensions holding identifiers. User IDs, session IDs, and timestamps are the worst offenders. Google’s guidance is direct: do not create user identifiers as custom dimensions, use the User-ID feature instead.
• Site search terms. Effectively unbounded on any site with search volume.
• utm_content and dated utm_campaign values. Campaign values carrying a date, an ad ID, or a creative name multiply fast, because each one combines with every source and medium already in the account.

That last one is the case marketers control directly. How many distinct values your tagging generates is a design decision, covered parameter by parameter in a UTM framework that scales.

How to Check Cardinality in GA4

There is no cardinality report, so you count values instead.

1. Open Explore and start a blank exploration.
2. Add the dimension you suspect as the only row dimension.
3. Add Sessions or Event count as the metric.
4. Set the date range to a single day. Cardinality is measured per day, so a longer range misleads.
5. Read the row count at the bottom of the table. Above 500, the dimension is high-cardinality by Google’s definition.

Two faster tells in standard reports. A visible (other) row means that table already overflowed. A warning about (other) with no visible row means it overflowed and a filter is hiding the row.

How to Reduce High Cardinality

Cardinality accumulates, so the fix is to generate fewer distinct values rather than to clean up afterwards.

1. Use existing dimensions before creating custom ones. Google’s first recommendation. Registered custom dimensions add rows to the same tables.
2. Strip query strings from page paths. Configure GA4 to remove URL query parameters so one page reports as one value.
3. Never put identifiers in custom dimensions. Use the User-ID feature for users. Send transaction and item IDs as event parameters without registering them, which keeps them available in BigQuery and audiences at no reporting cost.
4. Prefer standard reports. They are built on aggregate tables and hit limits later than explorations or Data API queries.
5. Control your campaign vocabulary. Cap the values allowed in utm_content, keep dates and IDs out of utm_campaign, and retire values that no longer earn their place.
6. Export to BigQuery. The event-level export has no row limit and no (other) row. It is the only genuinely uncapped option on a standard property.

Analytics 360 properties have one more option: expanded data sets re-expand (other) to as many as 2 million rows, capped at 100 expanded data sets per property. Anything beyond that still collapses.

Frequently Asked Questions

What is cardinality in GA4?

Cardinality in GA4 is the number of unique values a dimension holds. Device category holds a handful; Page path on a large site can hold hundreds of thousands. Google classifies any dimension with more than 500 unique values in one day as high-cardinality, because those push report tables toward their row limit fastest.

Why does GA4 show (other)?

GA4 shows (other) when a table needs more rows than its limit allows. Analytics keeps the most common dimension values and condenses the rest into that single row. It is a row-limit overflow, not a tracking error, which is why auditing your tags will not remove it. It appears in reports, explorations, and Data API responses alike.

What is the cardinality limit in GA4?

Google documents two numbers. A dimension with more than 500 unique values in a day counts as high-cardinality, and the property-level cardinality limit is 50,000 values, after which cardinality control is applied. Google does not publish the row limit for individual report tables, stating only that it varies by property type and query complexity.

Is data in the (other) row lost?

No. The sessions, users, and conversions inside (other) are still counted, and report totals remain accurate. What you lose is attribution: you cannot tell which page, campaign, or item produced those numbers. The event data is untouched, which is why the same period queried in BigQuery returns full detail.

How do you fix high cardinality dimensions?

Reduce the number of distinct values at collection rather than in reporting. Strip query parameters from page paths, keep identifiers out of custom dimensions, reuse existing dimensions, and constrain the values your campaign tagging can produce. For analysis that needs every value, use the BigQuery export, which has no row limit.

Most campaign-side cardinality comes from inconsistent tagging, so fix the value set where links are built with linkutm’s UTM rules.