High Cardinality in GA4: Why You See (other) in Reports and How to Fix It

TL;DR: What high cardinality means and why GA4 groups your data under (other)

High cardinality in GA4 occurs when a dimension, often a custom one from Google Tag Manager, has too many unique values. 

GA4 then stops displaying each value individually and groups the excess into the (other) row. The data remains collected but is not individually visible.

In summary:

• High-cardinality dimension: Any dimension with more than 500 unique values per day. This is Google’s classification, not a strict reporting limit.
• What triggers (other): GA4 enforces a 50,000-row-per-report-per-day limit. When this is exceeded, the remaining rows are grouped under (other).
• Most commonly, (other) is caused by custom dimensions in GTM that capture unique IDs, free-text strings, raw timestamps, or concatenated variables.
• To resolve this, audit your custom dimensions, determine which values should remain in GA4 versus your data warehouse, group high-cardinality values in GTM before they reach GA4, and use User-ID and Reporting Identity appropriately. If you need assistance, we offer a free assessment.

What is high cardinality in GA4?

Cardinality refers to the number of unique values a dimension can have. For example, device_category is low-cardinality (mobile, desktop, tablet, smart TV), while a custom dimension for transaction_id is high-cardinality, matching your transaction volume.

GA4 limits the number of unique values displayed in a report. Many teams misunderstand which thresholds apply in different contexts.

The 500-value threshold (what it actually means)

According to Google, a dimension with more than 500 unique values per day is considered “high-cardinality.” This is a classification, not a report filter. It identifies dimensions that may be grouped into (other) if a report exceeds its row limit. 

A dimension can have many distinct values over time and still report correctly, as long as no single day’s report exceeds the row limit.

The 50,000-row report limit (what actually triggers (other))

Standard GA4 reports are limited to 50,000 rows per day. If a report with high-cardinality dimensions exceeds this, GA4 retains the top rows by metric and groups the remainder into (other). 

This is based on row count, not the 500-value threshold, sampling, or data thresholds. Reports with a secondary dimension or Explorations can display up to 2,000,000 rows per day.

This distinction is important because many sources incorrectly state that GA4 reports are limited to 500 unique values per day. The 500-value figure indicates risk, while the 50,000-row limit determines when the issue appears.

Standard vs. GA4 360 cardinality limits

GA4 360, the enterprise tier, increases row limits to 1,000,000 for standard reports and 5,000,000 for Explorations, with higher event-parameter caps. 

However, the same issues can still occur, just at higher volumes. The remainder of this post refers to standard GA4 unless otherwise noted.

Why page_location and page_path are fine (built-in dimensions get special treatment)

The Pages and screens report uses page_location and page_path as primary dimensions, both of which are built-in. Google provides this report with a higher cardinality allowance than the standard row limit, allowing sites with millions of unique URLs to maintain usable Pages reports.

This exception does not apply to custom dimensions that capture page URLs with query parameters or combine page paths with other values. These follow standard report rules. Carefully evaluate any custom dimension that mirrors a URL or page identifier.

Why your GA4 reports are filling with (other)

As part of our tracking and analytics services we audit GA4 and five common patterns account for nearly all (other) issues.

Custom dimensions with unique IDs (user IDs, transaction IDs, session IDs)

The most common cause of high cardinality is sending unique identifiers as custom dimensions. We have audited properties that send client_id, user_id, session_id, lead_id, transaction_id, and quote_id as event-scoped custom dimensions. 

Each is unique to the event or user, causing cardinality to increase with each event. For user-level identification, use GA4’s User-ID feature. Custom dimensions should not store primary keys.

Free-text values (product names, search terms, page titles with query strings)

Free-text fields may appear low-cardinality, but in practice, they often are not. For example, a retailer with 12,000 SKUs has 12,000 product names. 

Including variants such as size, color, or configuration can increase this to 80,000 distinct values. Typos, abbreviations, or translations further increase the count. 

Internal site search terms and page titles with dynamic query strings or session tokens can also quickly exceed the 50,000-row limit.

Unbounded timestamps in event parameters

We often see properties capturing full ISO timestamps as custom dimensions, which are unique to the millisecond. This results in a new value for every event, causing (other) to appear immediately. 

If absolutely needed, timestamps at this granularity should be stored in BigQuery rather than as GA4 custom dimensions.

Date strings stored at day or second granularity instead of month or week

A similar issue arises when storing publication_date or event_date as YYYY-MM-DD, resulting in 365 new values per year. This may seem manageable until combined with another dimension. For most analyses, such as comparing quarterly article performance, month-level granularity (YYYY-MM) is sufficient. 

The GTM solution is discussed in Step 3.

Binding multiple variables together

Another common issue is creating a single custom dimension by concatenating multiple variables, such as product, blog_topic, tag, and author.

Each variable may be manageable individually, but concatenating them increases the number of unique values. For example, 12 product lines, 8 blog topics, 20 tags, and 40 authors result in up to 76,800 possible combinations.

In practice, not every combination will occur, but exceeding 50,000 unique combinations in a single day is sufficient to trigger (other). We have audited properties where a single “page taxonomy” custom dimension caused most content reports to be dominated by the (other) category.

If analysis requires all four variables, send them as separate custom dimensions and pivot in your reports. Concatenation should be reserved for data warehouse joins, not GA4 dimensions.

When (other) is not a cardinality problem

Before addressing custom dimensions, confirm that cardinality is the actual cause. Three similar issues are often confused with cardinality, but require different solutions.

Sampling vs. cardinality (two different things people conflate)

Sampling occurs when an Exploration exceeds the query quota for the selected date range or property tier, and is indicated by a warning at the top of the report. Cardinality is different; all events are retained, but dimension values beyond the row limit are hidden. If (other) appears in a standard report, it is not due to sampling. 

A sampling banner in an Exploration indicates a separate issue.

Data thresholds for Google Signals

When Google Signals is enabled, GA4 applies a data threshold to suppress values if the user count is low enough to risk identification. Suppressed rows are grouped into (other). This is a privacy feature, not related to cardinality. 

If disabling demographics and interests removes (other), this is the cause. To resolve, widen the date range or disable Google Signals, though this will remove demographic data.

Consent Mode and modeled data

Consent Mode v2 models behavioral data for users who decline consent. Modeled events are included in totals, but if a dimension value cannot be confidently assigned, GA4 groups those events under (other) for that dimension. 

If you suspect this is the cause, review Reporting Identity settings. Switching from Blended to Observed provides the unmodeled view.

The custom dimension problem most teams miss

Many discussions on this topic focus solely on GA4 and recommend simply creating fewer custom dimensions. While technically correct, this approach overlooks the root cause: the upstream data layer feeding those dimensions.

How GTM data layer values become GA4 custom dimensions

The typical process is as follows: a developer adds a value to the GTM data layer (such as a SKU, publication date, content tag, or user-account flag), a Data Layer Variable retrieves it, a GTM tag sends it to GA4 as an event parameter, and a Custom Dimension is created for reporting. 

Each step is correct in isolation, but the process often fails to consider whether the value, at its current granularity, should be included in GA4 reports.

Why your developers’ useful IDs become your analysts’ worst nightmare

Engineers prioritize precision, using transaction_id as a primary key or full ISO timestamps for accuracy. Analysts, however, focus on aggregation and prefer summarized data, such as transaction counts by week, source, or device. 

When detailed data is sent to GA4, it is often grouped under (other), making reports less useful. 

This is a translation issue between data precision and reporting needs.

The GTM-first lens: cardinality is created upstream of GA4

The key perspective is that cardinality issues should be addressed in GTM rather than GA4. 

Once high-cardinality data is in GA4, options are limited, and historical data remains at the wrong granularity. GTM allows you to control the level of detail before data reaches GA4, making it the most effective place to implement fixes. 

The GTM-to-GA4 pipeline is where small adjustments can have the greatest impact on reporting.

Real industry examples we see across client GA4 properties

The five patterns above appear differently across industries. The ones we see most often, anonymized:

Ecommerce (SKUs, product names, search query strings)

Each SKU, variant, and internal search query represents a unique value. For example, a retailer with 15,000 SKUs and 3 variants has 45,000 unique item_name values daily, with even more when search queries are included. 

This often causes Ecommerce purchases and Items reports to collapse, especially when a secondary dimension is applied. 

As a result, reporting on product performance by customer type becomes unreliable for items beyond the top sellers.

Healthcare (provider IDs, location IDs, condition-page URLs with parameters)

Multi-location healthcare organizations encounter cardinality issues with provider directory pages (one URL per provider), location pages combined with appointment types, and condition pages whose URLs include the condition, body part, and treatment plan. 

Adding patient-portal session IDs or scheduling-tool IDs can quickly exceed 50,000 unique URLs, even without a content surge.

Higher education (program codes, course IDs, faculty IDs, application stage flags)

Universities typically have fewer URLs than ecommerce sites but greater per-page complexity. A standard catalog may include 200 programs, 1,500 courses, 600 faculty profiles, and a multi-stage application funnel. 

The most common issue is custom dimensions that combine funnel stage with program code, reflecting the “binding multiple variables” pattern.

Enterprise software and B2B SaaS (user IDs, account IDs, free-text product names, full timestamps)

B2B SaaS properties frequently unintentionally include user-identifier dimensions in GA4. We have audited properties with over 12 user-identifier custom dimensions, full ISO timestamps as event parameters, and free-text product names that change with each release. 

Different teams often implement their own tracking independently, resulting in GA4 becoming an unreadable central repository.

The 5-step framework to fix high cardinality in GA4

We follow this sequence for clients. For small properties, the process can be completed in an afternoon. For mature properties with extensive tagging and custom definitions, it may take two to three weeks.

Step 1: Audit your GTM data layer and custom dimensions

Retrieve the complete list of event-scoped and user-scoped custom dimensions in GA4 (Admin → Custom Definitions). 

For each, answer four questions: 

• What analytical question does this dimension address? 
• What is the expected unique-value count per day? 
• Is the scope appropriate? 
• Could this be derived from a built-in dimension? 

Cross-reference with your GTM container to identify the tag and Data Layer Variable for each. If you cannot answer the first question, consider removing that dimension.

Step 2: Decide what belongs in GA4 vs. your data warehouse

GA4 is designed for aggregated behavioral analytics, not as a data warehouse. Send to your warehouse any data that requires joins with CRM, billing, or product systems; user-level precision beyond 60 days (or use User-ID as described in Step 4); granular timestamps; and high-cardinality dimensions alongside behavioral metrics. 

Retain in GA4 data such as channel and page conversion attribution, device and geography engagement, and campaign-to-revenue analysis. Use BigQuery export to transfer data that does not belong in GA4.

Step 3: Bucket high-cardinality values in GTM before they reach GA4

The solution should be implemented upstream. For example, converting YYYY-MM-DD to YYYY-MM in GTM often resolves high cardinality. 

Use a GTM Custom JavaScript variable as shown below:​

function() {  var rawDate = {{dlv - publication_date}};  if (!rawDate) return undefined;  var d = new Date(rawDate);  if (isNaN(d.getTime())) return undefined;  var month = ('0' + (d.getMonth() + 1)).slice(-2);  return d.getFullYear() + '-' + month; }

This change reduces a 365-value-per-year dimension to just 12. Apply similar strategies to free-text fields by normalizing case, removing whitespace, or mapping to a controlled vocabulary. 

Group product attributes by category or family, and either remove user identifiers or use User-ID. 

For concatenated variables, stop combining them in GTM; instead, send each as a separate event parameter and pivot in reports.

Step 4: Use User-ID and Reporting Identity correctly

For user-level identification, use the User-ID feature. Send your application’s user ID via the user_id event parameter (not as a custom dimension) so GA4 can link sessions across devices without increasing dimension cardinality. 

Select the appropriate Reporting Identity: use Blended (User-ID → Signals → device) for cross-device tracking with User-ID, Observed (User-ID → device) when User-ID coverage is high, and modeling is not needed, or Device-based when User-ID is unavailable. 

Reporting Identity is set per property in Admin. 

Many teams default to Blended, which interacts with Consent Mode and Google Signals data thresholds.

Step 5: Document, version, and govern your tagging

Cardinality issues often recur due to a lack of ownership of the GTM container. 

Follow these three rules: 

1. Maintain a single tagging specification listing every event, parameter, custom dimension, scope, and intended use.
2. Use GTM workspaces and versioning to prevent direct edits in production.
3. Require every new custom dimension request to undergo a review using the four questions from Step 1. 

For small teams, this review can be performed by a single analyst; for larger teams, use a Slack channel, a ticket queue, or a quarterly audit. The standard remains consistent.

Decision tree: Should this value be a GA4 custom dimension?

Use this decision tree whenever a team member proposes adding a new custom dimension. It takes 30 seconds and helps prevent future (other) issues.

1. Is this value unique per user or per session? Yes → go to 2. No → go to 3.
2. Do you need to identify the user in GA4, or just count them? Identify → use GA4 User-ID, not a custom dimension. Count → drop it; built-in user metrics already do this.
3. How many unique values will this dimension take per day? Under 500 → safe to add. 500 to ~10,000 → bucket or normalize in GTM first. Over 10,000 → send to BigQuery instead.
4. Do you need to join this value to data outside GA4 (CRM, billing, product)? Yes → BigQuery export, not a custom dimension. No → continue.
5. Is this value being combined with other variables in one dimension? Yes → split into multiple dimensions, do not concatenate. No → safe to add.

What we look at first in a client’s GA4 audit

When DeltaV runs a tagging audit, we go in a specific order. None of this is proprietary, and there is no reason a competent in-house analytics lead cannot do it themselves.

The Custom Definitions list (and what counts as “too many”)

We start with the Custom Definitions list (Admin → Custom Definitions) and the GTM container, side by side. 

A well-governed mid-market property usually has 8 to 15 active custom dimensions. We have seen 60+ on properties that have not had governance in years. Volume alone is not the issue. 

The concentration of high-cardinality definitions is. Five poorly scoped custom dimensions can cause a report to collapse. Forty narrow, controlled-vocabulary dimensions can be fine.

BigQuery export as a release valve

If the warehouse is the right home for some of the data, we recommend exporting to BigQuery. It is free at modest volumes and gives you event-level data without cardinality limits. The catch is that the warehouse has to be owned by someone. 

A BigQuery dataset that nobody uses just doubles your maintenance surface.

When to flag it for your stakeholders

A custom dimension capturing user IDs, transaction IDs, full timestamps, or several concatenated variables is worth surfacing at the leadership level. Not because it is a crisis, but because the cost of the fix is small and the cost of bad data informing next quarter’s strategy is not. 

We tell clients: your data is not gone. It is just unreadable in the tool you are looking at. There is a path to making it readable.

Next steps: get a GA4 audit

If you are looking at an (other) row in a report you care about and you do not know which custom dimensions are causing it, that is what we look at first.

DeltaV runs GA4 and GTM tagging audits for marketing leaders, evaluating whether their analytics setup is telling them the truth.

The audit covers your custom dimensions, event taxonomy, data layer, and the GTM-to-GA4 pipeline behind most of the cardinality problems above.

Request Assessment