Two different mechanisms make GA4 reports incomplete: one hides rows, the other estimates totals. Here is how to tell which one you are looking at, how to avoid each, and how unsampled raw rows work in a cookieless tool.
Thresholding and sampling are different problems. Thresholding withholds rows so small groups of users cannot be singled out. Sampling answers a query from a subset of events so Google can return it quickly. The first leaves gaps in a table; the second leaves a margin of error on every number.
Exact thresholds, quotas and conditions change. This page describes the mechanisms and tells you where to check current Google documentation for the numbers.
A Universal Analytics veteran opening GA4 for the first time meets three behaviors that did not exist in the same form before: reports that silently drop rows, explorations that say they used a fraction of your data, and a table row literally named (other). All three trace back to the same architectural fact. GA4 is an event-based system sitting on a very large shared backend, and it has to make trade-offs between speed, cost and privacy for every query it answers.
Those trade-offs fall into two families. Privacy controls decide what Google is willing to show you, regardless of whether it has the data. Performance controls decide how much of your data it is willing to scan to answer a question. Thresholding belongs to the first family. Sampling and the cardinality limit that produces (other) belong to the second.
The distinction matters because the fix is different. You cannot sample your way out of a privacy rule, and you cannot threshold your way out of a quota. Before you start changing report settings, identify which mechanism you are actually hitting.
Thresholding is GA4 declining to show you rows whose user counts are small enough that someone could, in principle, work out who those users are. The classic example: a report that breaks users down by age bracket and interest category for a page with modest traffic. A row such as "women, 25 to 34, interested in gardening, visited the pricing page" might describe a handful of people. Google withholds it.
What triggers it is the part you need to read in the current documentation, because the conditions have been revised over time. The broad pattern is stable. Thresholding is most likely when a report includes demographic or interest dimensions, or other data tied to Google signals, and least likely in plain pageview and event reports that carry no such data. The reporting identity setting on the property also influences how much data falls into this territory. Check current Google docs for the exact rules that apply to your property.
GA4 puts a small icon in the report header when thresholding has been applied, with a tooltip saying the report contains thresholded data. No icon does not prove no thresholding happened somewhere upstream, but the icon is the supported signal. Two symptoms outside the icon are worth knowing:
You have fewer levers than you would like, and none of them are free. Removing the demographic or interest dimension from the report is the most direct: a report without them is less exposed. Widening the date range increases user counts per row, which helps small groups clear the bar. Changing the property's reporting identity changes what the report is built from, with trade-offs for how users are counted. And exporting to BigQuery gives you event-level rows, where the report-layer thresholds are not what you are querying, though you take on the responsibility of handling that data correctly. Check current docs before you rely on any one of these, because they are exactly the settings Google adjusts.
Sampling is a statistical shortcut. Instead of reading every event in your date range, GA4 reads a subset and extrapolates. The result is an estimate, with a margin of error that grows when the subset is small relative to the whole or when the segment you are measuring is rare.
In GA4 it is mostly an Explorations phenomenon. The standard reports in the left-hand navigation draw on pre-aggregated tables, which is why they are fast and generally not sampled. Explorations run ad hoc queries against event data, and each query has a quota on how many events it may scan. A busy site asking for a long date range with a custom segment is the textbook way to exceed it. The quota differs between standard properties and GA4 360, and Google has changed it before, so check current docs for today's figure instead of trusting a number from a blog post, including this one.
An exploration that has been sampled shows an indicator at the top of the report with the share of available data used. Treat anything below 100% as an estimate. The practical consequences:
Shorten the date range, drop or simplify segments, or break one big question into several smaller ones and combine the results yourself. Compare against the standard report, which is generally unsampled, for any headline figure. For anything you will put in front of a client or a board, pull event-level data from BigQuery and compute the answer directly. The export link is free (BigQuery storage and queries past Google Cloud's free tier are billed separately), and it takes the exploration quota out of the equation. It only collects from the day you link it, so there is no backfill: start before you need it.
A table with an (other) row is hitting a cardinality limit: a dimension with too many distinct values for GA4 to list individually, so it groups the long tail into one bucket. Page paths with query strings, custom parameters with free-form values and campaign names typed by hand are the usual culprits. This is not privacy filtering and it is not sampling. The data is there; GA4 just will not enumerate it in that report.
The fixes are on your side of the fence. Keep dimension values low-cardinality: do not put timestamps, IDs or full URLs with parameters into event parameters you intend to report on. Standardize campaign names, which also pays off in your UTM hygiene. And check current docs for how cardinality interacts with the reporting surface you are using, because the standard reports, Explorations and the Data API do not all behave identically.
If your numbers look wrong, work through this table before changing any settings. The first column is the symptom, and the rest tell you which mechanism it points to.
| Mechanism | What happens | Typical trigger | How GA4 signals it | Way out |
|---|---|---|---|---|
| Thresholding | Rows withheld from a report | Demographic, interest or other signals-based data with small user counts | Icon in the report header | Drop the dimension, widen the range, or query event-level data |
| Sampling | Totals estimated from a subset of events | Explorations over large ranges or segments, past the query quota | Percentage-of-data indicator on the exploration | Shorten the range, simplify the segment, or use BigQuery |
| (other) row | Long tail grouped into one bucket | Too many distinct values in one dimension | A row named (other) | Lower-cardinality parameters, standardized names |
| Consent gaps | Visitors never recorded | Consent denied, or consent mode modeling in use | None in the report itself; compare with server logs or another tool | Check your consent setup and mode |
The last row is not a GA4 reporting rule at all, but it belongs here because it produces the same complaint: "the numbers are lower than I expected." On any site that shows a consent banner, the people who decline are missing from a cookie-based tool's observed data by design (consent mode can model some of them back in). That gap is invisible in the report and can be larger than anything thresholding or sampling takes. We cover the legal side in whether Google Analytics is GDPR compliant.
A short diagnostic that takes a few minutes and keeps you from tuning the wrong knob.
(other) bucket you have not expanded.None of these steps change data. They only tell you which mechanism applies, which is the whole job before you decide whether the report is good enough for the decision at hand. If you are thinking about getting your history out of GA4 before moving on, read how to export your GA4 history first, since retention limits apply to the same event-level data.
A cookieless tool sidesteps these mechanisms by being structurally simpler, not by being cleverer. GhostMetrics stores one row per event, with a small fixed set of columns. There is no sampling layer because the dashboard is not answering ad hoc queries across a quota-limited warehouse: every stored row feeds the totals you see. And the raw export, as CSV from the "Export data" button or as JSON from the API, contains every stored row and every column, on every plan including free. The export ships with a manifest.json describing each column.
The privacy protection is also built differently. GhostMetrics does not withhold small groups from a report. Its approach is to avoid collecting identifiers in the first place: no cookies, no localStorage, no stored IP addresses (they are hashed), no personal data and no cross-session identifier. It honors Global Privacy Control and Do Not Track by collecting nothing from those visitors. The trade-off is that there are no demographics or interest data to threshold, which is also a capability you give up. Country, city and organization panels still show small counts as they are, so think before you publish a dashboard for a low-traffic site. Read how cookieless tracking works for the mechanics.
Be careful with the word, because unsampled is not the same as complete. Four honest limits apply:
sessionStorage and cleared when the tab closes. There is no returning-visitor concept and no multi-session user.The point is not that cookieless data is better in every respect. It is that every limit is a documented, visible one that you can inspect in the raw rows, rather than a rule applied inside the report.
Thresholding and sampling are real irritations, and neither makes GA4 a bad product. For some jobs it is the strongest option on the market, and no cookieless tool replaces it.
The honest split: if you run paid acquisition and need to prove return on ad spend, keep GA4 and treat thresholding and sampling as constraints to engineer around with BigQuery. If you mainly want to know which pages, referrers and campaigns bring readers, and you would rather not manage a consent banner or interpret quota indicators, a simpler tool answers that with fewer caveats. Our GA4 alternative guide and the broader alternatives roundup compare the field.
Plenty of teams keep GA4 for ads and add a cookieless tool for everyday reporting. The cost is a second script and a second dashboard; the benefit is a cross-check. When GA4 shows a thresholded or sampled number, you have a second source with no such layer to test it against. Install takes one tag in the head of your pages:
<script defer src="https://ghostmetrics.nullagency.io/gm.js" data-site="YOUR-SITE-ID"></script>Expect the two tools' totals to differ for reasons unrelated to sampling: different definitions of a session, different handling of consent and privacy signals, and different bot filtering. Compare trends over weeks, not single-day figures. For a full move rather than a parallel run, see migrating from Google Analytics to GhostMetrics.
GhostMetrics is cookieless web analytics with no cookies, no localStorage and no stored IP addresses, so there are no analytics cookies for a consent banner to cover and no sampled report to second-guess. Install one script tag and you are live; no plugin, no tag manager, no build step. The free plan is free forever: one website, unlimited pageviews, real-time dashboard, every view, full history.
Raw event export as CSV or JSON is available on every plan, including free, with a manifest.json describing each column. Pro is $9.99/mo flat with unlimited pageviews and a 30-day free trial (card required to start, nothing charged for 30 days, cancel anytime). It adds unlimited websites (fair-use ceiling of 250) and a public shareable dashboard URL.
Disclosure: GhostMetrics is built by Null Agency and we use it on this site, so we are not a neutral party about our own product. Google's thresholding and sampling rules, quotas and report indicators change over time; check Google's current Analytics documentation for the exact conditions that apply to your property.