GA4 (other) rows, thresholds & sampling unexplained

Symptom and cause

Symptom

An (other) row swallows part of a breakdown, rows vanish when you drill down, or the same report shows different numbers on different days, and nobody can say why.

Cause

(other) from tables past their row limit, usually a high-cardinality custom dimension; data thresholds withholding small rows; sampling above the event quota; dashboards hitting Data API quotas. Nobody labelled which applies where.

Where it's caught

An (other) row in a report with secondary dimensions; the thresholding notice or sampling percentage nobody reads; rows that come back when the date range widens; dashboard totals that disagree with the GA4 UI itself.

Why GA4 shows (other), hides rows or samples

(other) is a row limit. Every report and exploration caps how many rows it will hold. When a table needs more, GA4 keeps the most common values and groups the rest under (other). Google publishes no single limit: it varies by property type (Analytics 360 is higher), by report, and by how complex the query is. Any fixed figure you read on a blog is an example, not Google's number. Secondary dimensions, filters and comparisons make (other) more likely. One dimension with few values is rarely affected; one with very many values, such as full page URLs, still can be.

What fills the table is cardinality: how many distinct values a dimension takes. Google counts more than 500 distinct values in a day as high. Rows multiply, too: three device types by twenty countries means up to 60 rows. In the audits on file, the cause is usually one of two. A built-in dimension that keeps its query string, such as Landing page + query string, where every gclid, fbclid and utm tag makes a new row. Or a custom dimension (a field someone told GA4 to report on, in Admin) set up on a value that changes every time: order id, timestamp, user id.

Moving the table into an Exploration does not reliably help. Google points the other way: use standard reports where possible, because they sit on pre-built summary tables. Anyone pulling GA4 through the Data API can check directly: the response metadata carries dataLossFromOtherRow when rows were rolled into (other).

The two other effects get blamed on (other) and need different fixes.

Data thresholds are a privacy rule. GA4 holds back data when showing it could let someone work out who an individual user is. Google names two cases: demographic data (including demographic audiences) and search query data. Short date ranges make both more likely. Blended and Observed reporting identity are also subject to thresholds when there is not enough signed-in activity. Thresholds are system defined and cannot be changed. Thresholded rows are left out of the table, and the data quality indicator says "Google Analytics has applied thresholding". The Data API reports it with its own flag, subjectToThresholding, separate from the (other) flag.

Sampling is a quota. When a query needs more events than the property allows, GA4 reads part of the data and scales it up. The limit is 10 million events per query on a standard property. Analytics 360 starts at 100 million and can go to 1 billion if you ask for more detailed results in Explore. The data quality icon shows the percentage of data used. Dashboards have a quota of their own: the Data API gives each property a fixed token quota per hour and per day, heavier requests use more tokens, and charts error when the quota runs out.

None of this is a tracking fault by itself. The fault is a report where rows merge, vanish or move and nobody has written down why. That is R-502.

Landing page + query · source / medium	Sessions	Share	Verdict
/ · google / organic	41,200	46%	named
/collections/sale?gclid=… · google / cpc	18,600	21%	named
/products/…?fbclid=… · meta / paid_social	9,300	10%	named
(other)	19,800	22%	row limit, unlabelled

a fifth of sessions under (other), no note on the tile

How to catch it

1. Name the effect first. A row labelled (other) is the row limit. A note in the data quality indicator saying thresholding was applied is a threshold. A percentage of data used is sampling. Three different causes; do not fix one for another.
2. For (other): remove the secondary dimension, filter or comparison and run the report again. If (other) shrinks or disappears, the table was over its row limit.
3. Then find the field that fills it. If the report uses Landing page + query string or a full page URL, switch it to Landing page or Page path and screen class, which drop the query string. If (other) collapses, click ids and tracking tags were making a row per visit. If not, open Admin → Data display → Custom definitions and look for a custom dimension on order id, timestamp or user id. To test one, put it alone in an exploration over 7 days: if nearly every row has one event, it is the culprit.
4. For thresholds: widen the date range. Google's own advice is that more days mean more users per row, and rows held back on a short range often come back. Take demographic dimensions and demographic audiences out of the report and check again. If the rows return, a threshold was the cause.
5. For sampling: shorten the date range in the exploration and watch the percentage in the data quality icon. Standard reports are less exposed than Explorations, though a filter on a large property, such as by country, can still sample a standard report. If a dashboard chart errors or moves with no change to the data, compare it with GA4 over an old, closed date range: a match there points to the Data API quota, not the data.
6. Ask what the report says about any of this. If no tile carries a note on (other), thresholds or sampling, that is the finding.

What putting it right involves

1. Report on the clean version of the field. For landing pages, use Landing page or Page path and screen class rather than the query-string version. Do not strip gclid or fbclid at collection to tidy a report: Google Ads and Meta rely on them for attribution.
2. Retire custom dimensions set up on order ids, timestamps, user ids or raw URLs. Before archiving one, check which reports, explorations and audiences use it. Send those values as event parameters without registering them: Google's (other) row page says the data stays usable in BigQuery, audiences and segments. Use the User-ID feature for user identity, not a custom dimension.
3. Ask thresholded questions in a form GA4 will answer. Widen the date range, take demographic dimensions out of reports that do not need them, and coarsen the breakdown. Then compare the report under Device-based reporting identity, a property setting in Admin. The switch does not touch collected data and can be undone. Thresholds themselves are a privacy control and cannot be adjusted.
4. Keep exploration queries under the sampling quota: shorter date ranges, fewer segments, a standard report where one exists. Where a number must be exact over a long range, query the BigQuery export, which holds the raw events GA4 received. A standard property's daily export stops at 1 million events a day, so confirm the export is complete before trusting it. For dashboards, fewer charts per page and an extract or BigQuery source for the heavy tables keep them inside the Data API quota.
5. Label it. Under every tile that can be affected, write which effect applies, for example "page level, may include (other)", "thresholded under 7 days", "sampled over 90 days". Keep the labels in the metric register (R-501).
6. Check after one full reporting cycle. The same question over the same closed date range should return the same number in the dashboard, the GA4 interface and BigQuery, or a labelled difference.