20 October 2026·4 min read
When data thresholds hide your rows — the Google signals trade-off
Your demographics report is nearly empty and the user totals do not match your other reports. GA4 withholds rows to stop individuals being identified, and the data that triggers it is what Google signals brings in. What you gain and what you give up, side by side.
Symptom
You open the demographics or interests report and the table is nearly empty. The same period clearly shows thousands of users elsewhere, but the moment you split by age or gender the total collapses. Narrow the date range and the few remaining rows disappear too; the finer the segment, the smaller the number.
The data quality indicator at the top of the report says thresholds have been applied to it. It does not say what to fix.
Cause
Data thresholds are how GA4 stops individual people being identified from a report. When a report contains demographic, interest or search-term signals and the number of users in that slice is small, GA4 withholds the row entirely rather than showing it. There is no switch to turn this off — it is applied while the report is being assembled.
And the thing that brings those signals into your reports is Google signals. The same treatment applies when your reporting identity uses signed-in user data. So thresholding is not GA4 malfunctioning; it is one of the costs of having Google signals on.
There is a point here that reads as the opposite of our own diagnosis. AnalyticScan's ST-05 warns when Google signals is off. To someone whose rows are being withheld, that can sound like "so turn it off, then". It is not a contradiction — these are two different defects.
| With signals on | With signals off |
|---|---|
| One person's laptop and phone count as one person | Each device counts as a separate person and user counts inflate |
| Demographics and interests reports have data in them | Those reports are empty |
| Rows covering few visitors may be withheld by thresholds | There is less reason for thresholds to apply |
| EU visitors need to have consented | — |
Neither column is free. We keep the warning because of the first row on the right: one person counted once per device is a real measurement defect, it is the kind report readers usually do not know they have, and every conversion rate and return-visit rate computed on top of it is slightly wrong. We nevertheless keep it at two points, and as a warning rather than a failure, because of the third and fourth rows on the left — that is how the verdict admits that turning it on is not free either.
The only thing we actually read for this check is whether Google signals is enabled. Consent mode configuration is not exposed by the GA4 Admin API, so we hold no such field at all. That is also why the check's name no longer mentions consent — we are not going to list something we do not look at. And if having it off was a deliberate choice, the report says so.
How to check in GA4
1) Separate "withheld" from "absent". Open the same period and the same segment once more with the demographic dimension removed. If the user count jumps when the dimension goes away, the data was not missing — it was hidden.
2) Widen the date range. Thresholds apply when a slice covers few users. If stretching seven days to twenty-eight brings the missing rows back, that confirms it. Put the other way round: the less traffic a site has, the more often it meets this.
3) Look at the current signals setting. Admin → Data collection and modification → Data collection. If it is off and rows are still withheld, look at your reporting identity next.
Deciding which way to go
If counting people correctly comes first, turn it on. Cross-device double counting moves the denominator under every user metric, so conversion rate, return-visit rate and audience size all shift with it. The price is that finely sliced reports will hide rows.
If you must see the hidden rows, work in this order. Widen the date range first. If that is not enough, drop the demographic and interest dimensions from that report and keep only the splits you actually need — channel, landing page, device. Switching the reporting identity to device-based is also an option, but that gives up cross-device stitching, which walks straight back into the problem you just fixed.
If you need the raw rows themselves, that is the BigQuery export. Thresholding is applied while a report is assembled, so it does not apply to the raw events the export delivers. The export only starts accumulating from the day you switch it on, though.
If you have EU visitors, consent comes first. Signals is only meaningful on traffic that has consented, and consent status is precisely the thing we cannot verify for you. Check your consent management setup yourself before turning it on.
In one line
Thresholding is not GA4 breaking; it is the price of having Google signals on. We warn when it is off, but we are not going to tell you to turn it on while hiding the bill — whether cross-device accuracy or fine-grained rows matter more is the property owner's call.