Sampling, thresholding and precision in Explore

Two separate mechanisms can make an exploration differ from the truth.

Sampling kicks in when a single query touches more than 10 million events (1 billion on 360). GA4 reads a representative subset and scales it up. The indicator at the top right of the tab shows a green tick (This exploration is based on 100% of available data) or a warning with the sampled percentage; hover it for the exact figure. Sampling is per query, so a narrower date range, fewer dimensions or a segment that reduces the events scanned can bring you back under the limit. Properties on 360 also get a Data quality toggle for Faster results vs More detailed results, trading speed for a larger sample. For the long tail (small segments, rare events), sampled results can be badly off; headline totals are usually fine.

Thresholding is different: rows are withheld, not estimated, to stop anyone inferring the identity or demographics of individuals. It applies when the query involves Google signals data or demographic dimensions, or when the reporting identity includes anything beyond device ID and a row would represent very few users. The indicator shows an orange icon with Thresholding applied. Remedies: widen the date range, remove demographic dimensions, or switch Admin > Reporting identity to Device-based (reversible, report-time only). Standard reports are also thresholded, but never sampled.

(other) rows are a third effect: tables with too many distinct dimension values, especially high-cardinality custom dimensions, get their tail collapsed into (other). Explorations suffer less than reports but are not immune; lowering cardinality at collection time is the real fix.

And always the retention window: a query beyond it simply has no data, with no indicator at all.

When none of these workarounds suffice, the answer is the BigQuery export: raw, unsampled, unthresholded and kept as long as you like.