Summary
Create an Exploration to query the raw, granular data. The (other) row appears when a dimension has too many unique values for the pre-aggregated tables behind standard reports, so the smaller values get grouped together. Explorations run against event level data, which brings the individual traffic sources back into view.
Nitin Batra is a Google Analytics 4 certified professional who configures GA4 properties and builds Exploration reports to diagnose high cardinality and attribution issues for client accounts.
Last updated: August 16, 2026
To see the traffic sources hidden inside the (other) row of a Traffic Acquisition report, create an Exploration to query the raw, granular event data instead of the pre-aggregated standard report tables.
- Create an Exploration to query the raw, granular data.
- Change the property’s attribution model in the Admin settings.
- Refresh the standard report until the (other) row disappears.
- Delete the report and wait 24 hours for it to be recalculated.
The correct answer is: Create an Exploration to query the raw, granular data.
Key Takeaways
- – The next step is to create an Exploration to query the raw, granular data, because Explorations read event level data instead of the aggregated tables that produce the (other) row.
- – The (other) row is caused by high cardinality, meaning too many unique values in a dimension for the daily summary table to hold, so GA4 groups the smallest ones together.
- – Standard reports are built for speed from pre-aggregated tables, while Explorations run a fresh query against underlying event data, which is why the two can show different levels of detail.
- – Refreshing the report, changing the attribution model or waiting for recalculation does nothing, since (other) is a reporting limit and not a processing delay. Explorations also have their own quota and sampling limits, so wide date ranges can still return incomplete results.
Why does GA4 show an (other) row in the Traffic Acquisition report?
Standard reports are served from daily aggregate tables that can hold a limited number of rows. When a dimension such as Session source / medium collects more unique values than that limit in a day, GA4 keeps the highest volume values and pushes the rest into a single (other) row. It is a reporting cardinality limit, not lost or unrecorded data.
Will an Exploration always remove the (other) row completely?
Usually yes for short date ranges, because Explorations query event level data. Very large properties with long date ranges can still hit quota or sampling thresholds, and you may see (other) again. Shortening the date range or filtering to one medium at a time is the practical fix.
Does changing the attribution model fix high cardinality in reports?
No. Attribution models decide how credit for conversions is distributed across touchpoints. They have no effect on how many unique dimension values a report table can store, so switching from data driven to last click will not reveal anything hidden inside (other).
How do I reduce the (other) row appearing in the first place?
Cut down the number of unique values you send. Strip unnecessary or unique parameters from UTM tags, keep campaign names consistent in lowercase, and avoid pushing session IDs, timestamps or user identifiers into source, medium or campaign fields. For very large properties, the BigQuery export gives you unaggregated data with no cardinality limit at all.