Why Does "Other" Appear in Google Analytics 4?
Seeing "(other)" pop up in your Google Analytics 4 reports can be frustrating, making you feel like your data is incomplete or inaccurate. This isn't an error but GA4's way of handling massive amounts of data by bundling less common values together. This article explains exactly why the "(other)" row appears, which dimensions cause it, and provides actionable steps you can take to see your full data.
What Exactly Is the "(other)" Row in GA4?
The "(other)" row in Google Analytics 4 is a catch-all category for data that exceeds GA4's processing limits for a specific dimension. When a dimension has an enormous number of unique values on a single day, GA4 processes and displays the most common ones first. Once it hits its internal limit, it groups all remaining values into the "(other)" row.
Think of it like this: Imagine you're a bouncer at a club with a VIP list of 500 people. On a very busy night, 800 people on the list show up. To keep the line moving, you let the first 500 in and then tell everyone else they're now in the "general admission" group, even though they were on the list. GA4 does the same with your data to keep reports loading quickly.
This happens because of a concept called high cardinality. Understanding this is the key to solving the issue.
Why Does "(other)" Appear? The High-Cardinality Problem
Data is organized into dimensions and metrics. Metrics are numbers (like Sessions, Users, Conversions), and dimensions are the descriptive categories you measure those numbers against (like Country, Device Category, or Landing Page).
What is Cardinality?
Cardinality refers to the number of unique values within a dimension. Some dimensions have low cardinality, while others are naturally high.
- Low Cardinality Example: The Device Category dimension has only three possible values: Desktop, Mobile, and Tablet. This is low cardinality.
- High Cardinality Example: The Page path and screen class dimension could have thousands or millions of unique values for a large website with many pages, especially if it uses dynamic URL parameters. This is high cardinality.
Other potential high-cardinality dimensions include user IDs, transaction IDs, session IDs appended to URLs, individual product SKUs, or granular marketing campaign parameters.
Free PDF · the crash course
AI Agents for Marketing Crash Course
Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.
How High Cardinality Triggers the "(other)" Row
Standard GA4 reports rely on pre-aggregated data tables to load quickly. To manage server performance, Google sets a daily processing limit on the number of unique values (rows) each of these tables can handle. For standard free GA4 properties, this limit can be around 50,000 unique values per dimension per day.
When you have a dimension that exceeds this limit on a given day, GA4 processes the top 50,000 values and dumps the rest into the "(other)" category. This aggregation happens at the daily processing stage, which is why "(other)" seems to appear permanently in your standard reports once it's there.
Crucially, this is a distinct issue from traffic being "unassigned," which happens when GA4 can't attribute a session to a specific traffic source. "(other)" is about having too much organized data, not unorganized data.
Common Reports Where "(other)" Appears
You’re most likely to encounter the "(other)" row in reports that use dimensions with a high potential for unique values. Here are the usual suspects.
1. Landing Page and Page Path Reports
This is probably the most common place to see "(other)". Websites generate high cardinality when URLs contain dynamic parameters. These parameters are additions to the end of a URL that often contain unique identifiers.
For example, you might see URLs like this:
/blog/post-title?session_id=A9CGE5124GSD/product/item-name?user_id=883193JFK3S/landing-page?fbclid=IwAR2a8f…(A Facebook click identifier)
Each unique session_id, user_id, or fbclid creates a new, distinct URL as far as GA4 is concerned. A few thousand visitors can easily generate a few thousand unique page paths, quickly exceeding the daily limit and triggering the "(other)" row.
2. Traffic Acquisition Reports
Poorly structured UTM campaigns can also create a cardinality issue. The dimensions Session campaign, Session source / medium, or Session manual ad content can become bloated if you use overly dynamic or unique values.
For example, if you include a unique click ID or timestamp in your UTM parameters, you are creating a new campaign for every single click:
Bad Practice: utm_campaign=summer_sale_click_987654321
Every click creates a unique campaign name, leading to an explosion of unique values and, eventually, the "(other)" row.
3. Custom Dimensions
Creating custom dimensions is powerful, but it's also the easiest way to accidentally cause high-cardinality issues. Never collect values that are unique to every individual user or event as a custom dimension for reporting in the standard UI.
Common Mistakes:
- Creating a custom dimension for
user_id. - Using a custom dimension to track
transaction_id. - Passing a device's
client_idas a custom dimension.
These values are inherently unique for every user or session. Storing them this way guarantees that you will hit cardinality limits almost immediately, rendering your reports meaningless.
How to Fix and Avoid the "(other)" Row in GA4
Now for the good part: how to fix it. The right approach depends on whether you want a quick workaround to see the data right now or a long-term solution to prevent it from happening again.
Solution 1: Use Explorations for Unsampled Data (The Quick Fix)
This is the fastest and most effective way to see your data without the "(other)" row. GA4's Explorations pull from the raw, unprocessed event-level data instead of the pre-aggregated daily tables used in standard reports. They are not subject to the same cardinality limits.
If you see the "(other)" row in your Landing Page report, you can simply recreate that report in Explorations.
How to do it:
- Navigate to the Explore tab in the left-hand GA4 menu.
- Click Blank exploration to start a new exploration.
- In the Variables column on the left, click the "+" icon next to Dimensions. Search for and import "Landing page + query string".
- Click the "+" icon next to Metrics. Search for and import metrics like "Sessions", "Users", and "Conversions".
- Drag the "Landing page" dimension from the Variables column to the Rows box in the Tab Settings column.
- Drag your chosen metrics from Variables to the Values box in Tab Settings.
Your Exploration report will now show all of your landing page data, and the "(other)" row will be gone. You can replicate this process with any dimension that is causing issues.
Free PDF · the crash course
AI Agents for Marketing Crash Course
Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.
Solution 2: Clean Up Your Data Collection (The Long-Term Fix)
The best long-term strategy is to stop sending high-cardinality data to GA4 in the first place.
Clean Up Your URL Query Parameters You can tell GA4 to ignore specific URL parameters that don't add analytical value. This prevents them from creating unique page paths.
- Go to your GA4 Admin panel.
- Under Property, click on Data Streams and select your web stream.
- Under Google tag, click Configure tag settings.
- On the next screen, click Show all, then select Configure your domains.
- If this setting isn't available, find the section for URL Query Parameters elsewhere in the stream configuration (the interface changes). Here, you can list all parameters to exclude, separated by commas (e.g.,
fbclid, msclkid, session_id).
Now, GA4 will ignore these parameters when processing page paths, dramatically reducing cardinality.
Standardize Your UTM Naming Conventions
Enforce a strict, standardized UTM naming convention across your marketing team. Avoid using dynamic, unique values in utm_campaign, utm_content, or utm_term. Use clear, descriptive, and reusable categories instead.
Good: utm_campaign=summer_sale_2024
Bad: utm_campaign=summer_sale_txid_1aX2bG...
Use Dedicated Features, Not Custom Dimensions For unique identifiers, always use GA4's dedicated features instead of custom dimensions.
- For tracking users across devices, implement the built-in User-ID feature.
- Transaction IDs are captured automatically with ecommerce events.
Leveraging these saves your custom dimensions for what they're truly meant for: segmenting users and events based on metadata with a reasonable number of unique values (like "Subscription Tier" or "Content Topic").
Solution 3: Export to BigQuery (The Power User's Fix)
For businesses with very large datasets, the ultimate solution is to set up the free native integration between GA4 and BigQuery. This sends a raw, unsampled copy of your event data directly to your own data warehouse in the Google Cloud Platform.
In BigQuery, there is no "(other)" row because you have access to a perfect, untouched log of all your data. You can query it with SQL without any cardinality limits. This is the gold standard for deep, reliable analysis.
Final Thoughts
The "(other)" row in GA4 isn’t a bug but a signal that your dimensions have too many unique values for standard reports to handle. It's GA4’s efficiency mechanism, designed to keep the platform fast by bundling high-cardinality data after hitting its daily processing limits.
At Graphed, we designed our platform to eliminate these kinds of headaches. You connect your Google Analytics account in seconds, and our system syncs with your raw data behind the scenes. That means when you use plain English to ask a question like, "What were my top viewed pages last month?", we build a report for you instantly using the complete, unfiltered data. There’s no risk of hitting cardinality limits or seeing an "(other)" row, just a clean, accurate report you can trust.
Related Articles
How to Create Facebook Ads API for Claude Code
Create a Meta Marketing API access token that never expires, using a system user, so Claude Code can pull Facebook ad reports and manage campaigns.
ClickHouse vs Postgres: When to Switch to Columnar
Comparing ClickHouse vs PostgreSQL means matching storage architecture to workload. Row storage wins for transactions. Columnar wins for scan-heavy analytics.
Google Ads for Orthodontists: Get More Booked Consults
Most orthodontic Google Ads campaigns waste money on low-intent searches. The problem is structure, not the platform.