What should a team validate first when ga4 cardinality problems: what (other) means and how to fix it appears?

Reproduce the problem in the live implementation, isolate whether it is scoped to one report or flow, and compare it against at least one secondary source before changing the setup.

How do I know whether the fix actually worked?

You need before-and-after evidence in the browser and in the downstream report. A clean-looking dashboard without validation is not enough.

When should this become a full GA4 audit instead of a quick fix?

If the issue touches attribution, consent, revenue, campaign quality, or data trust for more than one workflow, it is usually safer to audit the surrounding implementation than patch only the visible symptom.

GA4 Cardinality Problems: What (Other) Means and How to Fix It (2026)

What is GA4 cardinality and why does (other) appear?

GA4's reporting interface has a limit on the number of distinct values (cardinality) it can display per dimension per day. When a dimension exceeds this limit, the remaining values are grouped into a single (other) row. The cardinality limit for GA4 standard reports is approximately 500 unique values per dimension per day for free properties.

Once exceeded, you lose the ability to see individual values for those sessions in standard reports — they're all lumped into (other). GA4 still collects and stores the raw values (accessible in BigQuery) but standard reports and Looker Studio become unreliable for high-cardinality dimensions.

The four most common causes

Cause 1 — Page title includes dynamic user data

Example: <title>Dashboard - John Smith | MyApp</title>

If GA4 collects the page title as a dimension and each user's name creates a unique page title, a site with 600+ daily active users will have 600+ unique page title values per day — immediately exceeding the limit.

Fix: Sanitise page titles in GTM before passing to GA4:

Pass this sanitised variable as page_title in the GA4 Configuration tag.

Cause 2 — Page URL includes session-specific parameters

Example: /products?session_id=abc123xyz&user_ref=unique_token

If unique session IDs or user reference tokens appear in tracked page URLs, every session creates a unique page_location value.

Fix: Strip session-specific parameters from the page URL before GA4 receives it (see also the PII prevention post). Use a GTM custom variable that removes known session/user parameters from the URL.

Cause 3 — Custom dimensions with unbounded value sets

Example: Using item_id as a GA4 custom dimension on a site with 2,000+ SKUs.

If 600+ unique SKUs are viewed in a single day, the item_id custom dimension exceeds the limit.

Fix: For product-level analytics, use BigQuery (which has no cardinality limit) rather than GA4 custom dimensions. If you need product-level analysis in the GA4 UI, bucket SKUs into categories or ranges rather than using individual IDs.

Cause 4 — Sending transaction IDs or order numbers as custom dimensions

A busy e-commerce site with 700+ daily orders sends transaction_id as a custom dimension. Each transaction has a unique ID → 700+ unique values per day → (other) from day one.

Fix: Transaction IDs are high-cardinality by design. Never send them as GA4 custom dimensions. Analyse transaction-level data in BigQuery where cardinality is unlimited.

How to diagnose cardinality issues

Step 1 — Check for (other) in standard reports

Want to see which hidden implementation gaps are affecting your GA4 data quality?

Start free audit

GA4 → Reports → Engagement → Pages and screens

Look for (other) in the Page title dimension. High volume (other) (>5% of page views) indicates cardinality issues with page title.

Similarly in:

Events report: (other) in Event name column (unusual — event names are typically low cardinality)
Acquisition reports: (other) in source/medium (often channel group issues, not cardinality)
Custom dimension reports: (other) in any custom dimension report

Step 2 — Quantify the cardinality in BigQuery

If distinct_values significantly exceeds 500, cardinality is the cause of (other) in your reports.

Step 3 — Identify the problematic values

If the top 50 titles all have 1–5 occurrences (instead of thousands), they are individually unique — confirming a dynamic user data problem.

Design patterns that prevent cardinality

Pattern 1 — Bucketing instead of exact values

Instead of: page_views_count: 1456 (unique per user) Use: page_views_bucket: '1000-2000' (bounded set of buckets)

Instead of: order_value: 237.45 (thousands of unique values) Use: order_value_tier: 'medium' (low/medium/high buckets)

Pattern 2 — Page type instead of page title

Instead of: page_title (unique per content item on large sites) Use: page_type: 'product_detail' (bounded: 5–20 types across a typical site)

Page type is an event-scoped custom dimension with low cardinality. It enables analysis by page type (which types of pages generate the most conversions?) without the cardinality problem of individual titles.

Pattern 3 — Using GA4 for bounded dimensions, BigQuery for unbounded

GA4 custom dimensions (bounded): page_type, customer_tier, subscription_plan, lead_type, device_category

BigQuery analysis (unbounded): product_id, transaction_id, user_id, session_id, search_query

This split respects GA4's architectural limits while keeping high-cardinality analysis where it's technically appropriate.

Recovering (other) data from BigQuery

If you have GA4's BigQuery export enabled, all raw parameter values (including those grouped into (other) in GA4 reports) are available in BigQuery:

This query returns the full distribution including values that appear as (other) in GA4 standard reports — enabling analysis that the UI can't support.