Cardinality in GA4: why there is an (other) row in your report

Cardinality is the number of unique values in a dimension. Device category has three: desktop, mobile, tablet. That is low cardinality.

Page location on a shop with filters and search parameters runs into the hundreds of thousands. That is high cardinality, and that is where the trouble starts.

GA4 builds its standard reports from daily tables with a maximum number of rows. When a dimension goes past that, GA4 keeps the most common values and adds everything else together in one row: (other).

The numbers still add up. Your totals stay correct, because the dropped values sit inside that one row.

What you lose is the breakdown. You cannot see which pages, campaigns or products ended up in (other), and you cannot filter or segment on them.

Worse, it does not come back. Once GA4 has aggregated a day, the detail for that day is gone from reporting. Cleaning up your tagging tomorrow helps tomorrow, not last month.

You usually notice it first in the standard reports. Explorations fetch their data differently, but (other) shows up there too once your query produces too many unique combinations.

• page_location with query strings. Every ?filter=red&sort=price&page=3 is its own value. Add gclid, fbclid and a handful of utm_ parameters and a single product page becomes thousands of rows. By far the most common cause.
• A custom dimension filled with an order ID or transaction ID. Unique per event by definition. One sale, one new value. This inflates a report within a week.
• A timestamp as a dimension value. Same story, faster. Accurate to the second means literally every hit is a unique value.
• A username, email address or customer number in a dimension. High cardinality, plus a personal data problem on top.
• Product names carrying their variants. "T-shirt blue M", "T-shirt blue L", "T-shirt red M". A hundred models across five sizes and eight colours is four thousand item names. Put the variant in item_variant and keep item_name at model level.

Keep unique IDs out of custom dimensions. This is the hard rule. Order IDs, session IDs and timestamps do not belong in a dimension you use in reports. If you need transaction-level analysis, do it in BigQuery.

Clean up your URLs. Strip the parameters that add nothing to your analysis before the tag fires, or use the query parameter exclusion setting on the GA4 data stream. Which parameters to keep and why, we covered in the article on query parameters.

Shorten your date range. GA4 applies the limit per day. Ask for a report across three months and the unique values pile up. The same analysis per week or per day often gives you the breakdown you were after.

Use fewer values per dimension. Group where you can. A dimension with twenty product categories is workable. One with four thousand article names is not.

Go to BigQuery when you need value-level detail. The export holds every event separately, with no aggregation and no (other). There you can group by order ID.

SELECT
  REGEXP_REPLACE(
    (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'page_location'),
    r'\?.*$', '') AS page,
  COUNT(*) AS views
FROM `my-project.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20240101' AND '20240131'
  AND event_name = 'page_view'
GROUP BY page
ORDER BY views DESC

Run that same query without the REGEXP_REPLACE and you see how many unique URLs you generate per day. That number is your actual cardinality problem.

• Look for (other) in your reports. If it ranks high in the list, you are missing more than you think.
• Take order IDs, transaction IDs, timestamps and usernames out of your custom dimensions. Check the ones that have been running for years too.
• Clean up your URLs, or exclude the redundant query parameters on your data stream.
• Split an analysis into shorter periods before you conclude the data is missing.
• Enable the BigQuery export for anything you need at unique-value level. It is the only place where (other) does not exist.