Tags: analytics concept

Cardinality

Date: 2026-08-16

---

How many distinct values a property takes. Tools cap it, and past the cap everything gets swept into “(other)” — silently, with no record of what was lost, and it’s the values you most wanted that go first.

---

What it is

Cardinality is the count of unique values in a property.

low          device        3 values      mobile, desktop, tablet
medium       category     40 values
high         product_id   12,000 values
unbounded    page_url     millions       every parameter combination
             search_term  millions       free text

Unbounded is the category that causes problems, because it grows without limit as traffic grows.

What happens at the limit

Analytics tools store pre-aggregated tables per dimension. Beyond a threshold of distinct values, everything past the top N is bucketed:

requested: conversion rate by search_term

  wool socks          412 sessions   3.4%
  merino              208            4.1%
  walking socks       190            2.8%
  ...
  (other)          84,000            1.1%   ← 60,000 distinct terms

The (other) bucket is unrecoverable. You can’t drill into it, you can’t find out what was in it, and you can’t tell whether the answer you wanted was in there. Worse, the aggregate rate for (other) is meaningless — it’s an average across tens of thousands of unrelated things.

[CHECK: cardinality limits are tool- and tier-specific and change — verify yours rather than assuming a threshold.]

In plain terms: the tool quietly stops counting the long tail and doesn’t tell you which part of your question it stopped answering.

Where it comes from

• Identifiers as properties. product_id, order_id, user_id — high by nature, and sometimes necessary
• URLs with parameters. Every UTM combination is a distinct page path unless stripped — UTM Governance
• Free text. Search terms, form input, error messages
• Concatenated values. mobile|paid|uk|new multiplies four low-cardinality dimensions into one high-cardinality field
• Variables in event names. The failure Event Taxonomy Design exists to prevent — product_viewed_wool_socks creates one event name per product
• Timestamps as properties. Every event has a unique value

Handling it

Bucket at collection. Store the useful shape rather than the raw value:

price_pence      2400        →  price_band      "£20–30"
search_term      free text   →  search_length   "1 word" / "2–3" / "4+"
                             →  search_matched  true / false

Keep both where you can — the bucketed version for reporting, the raw in the warehouse.

Split into dimensions. mobile|paid|uk|new as four properties is four low-cardinality fields you can cross freely, rather than one field with hundreds of values.

Keep high-cardinality analysis in the warehouse. A warehouse has no cardinality limit — it has a cost curve instead, which is a budget question rather than a silent truncation. This is one of the clearer arguments for Warehouse-First Analytics.

Don’t send what you won’t query. Every unique value is storage and index cost forever — Events and Properties.

Checking for it

select count(distinct property_value) as distinct_values,
       count(*)                       as events
from events
where property_name = 'search_term'

Run it across your properties periodically. Two signals worth acting on:

• A property near the tool’s threshold — it’s about to start truncating, or already is
• A property whose distinct count grows linearly with traffic — it’s unbounded, and it will only get worse

Add it to the property checks in Guide - Auditing a Tracking Plan — a property specified as five values holding four thousand is a variable that leaked in, and it’s usually a symptom of a taxonomy problem rather than a storage one.