GA4 Data Thresholds and Retention in 2026: Why Paid Traffic Reports Go Empty
GA4 data thresholds are the most common reason a paid traffic report comes back half empty. The pattern is familiar: you open last Tuesday’s numbers, add a breakdown by age or device, and half the rows disappear. Or you build an exploration covering last year and GA4 returns nothing past a certain month. Or you reconcile conversions with Google Ads and find a gap that attribution and conversion windows do not explain.
In most of those cases the tags are fine. Two mechanisms inside GA4 are doing it: data thresholding and data retention. The first hides rows with too few users. The second deletes user-level data once a period expires. Both are on by default, both change your numbers silently, and both can be managed — partially.
Below: how to tell them apart, what actually triggers a threshold, which workarounds are legitimate, which property settings to fix today, and how to stop making budget decisions on reports that quietly had data cut out of them.
Two different mechanisms people conflate
| Property | Data thresholding | Data retention |
|---|---|---|
| What it does | Hides report rows at query time | Deletes user-level data permanently |
| When it fires | Few users in a row plus sensitive dimensions | When the configured period expires |
| Reversible | Yes — change the query, the data is still there | No — deleted is deleted |
| Visible in the UI | Yes, a warning icon above the report | No, explorations just come back empty |
| Configurable | Indirectly, via identity and Google Signals | Yes, directly in property settings |
| Affects BigQuery Export | No | No |
That last row is the one media buyers should remember. BigQuery Export happens before thresholds are applied and is not bound by GA4’s reporting retention. If paid traffic drives meaningful revenue, that alone justifies turning the export on — our walkthrough of GA4 BigQuery Export for paid traffic covers limits, schema and the queries worth starting with.
GA4 data thresholds: what they are and when they fire
A threshold is a privacy guard. GA4 hides a row when that row could identify an individual. If the slice “women 25–34, city X, campaign Y, Tuesday” contains three users, showing it is risky.
Google documents the mechanism but does not publish the numeric threshold, and states plainly that it cannot be adjusted by users and is set dynamically based on data volume and context. The empirical figure circulating in the industry is roughly 50 users per row. Treat that as a rough planning benchmark, not a documented rule — it is unconfirmed and varies from query to query.
Three conditions that trigger it
- The query includes sensitive dimensions. Demographics (age, gender), interests (affinity, in-market), or anything derived from Google Signals.
- Google Signals is enabled and reporting identity uses it. Without Signals, a large share of thresholds simply never arises.
- The row has few users. The finer the slice, the higher the odds.
They work together. A campaign report with no demographics over a month is almost never cut. The same report split by age and by day gets cut routinely.
The hidden multiplier: the Date dimension
This is the trap that costs the most time. Daily rows contain fewer users than an aggregate by definition, so adding Date acts as a threshold multiplier. The same query over 30 days returns data; split by day it returns half of it. The daily figures then fail to sum to the period total — not a bug, a direct consequence of thresholding.
If “sum of days ≠ month total” in a report containing demographics or Signals data, it is almost always a threshold rather than a tracking fault. Auditing tags at that point is wasted effort.
Where this hits paid traffic specifically
- Demographics by campaign. Trying to see which age bracket converts in a campaign spending $30 a day usually returns nothing at all.
- City-level geo breakdowns. The standard slice for local campaigns, and a standard threshold casualty.
- New campaigns and tests. The first fortnight has few users per row by definition — exactly when decisions get made.
- The Analytics Data API. Thresholds apply there too, not just in the interface. If a Looker Studio dashboard or a connector keeps losing rows, this is often why.
- Funnels and cohorts. Any demographic split of a funnel sharply raises the chance of empty steps.
How to spot a threshold
GA4 shows a warning indicator above the table explaining that a data threshold has been applied. It is small and easy to miss — train yourself to check that corner whenever a number looks implausibly low.
A faster test: run the same query with the Date dimension removed. If noticeably more data appears, it was a threshold.
Six ways to get the data back
You cannot switch thresholds off — there is no setting. You can build queries that do not trip them.
1. Switch reporting identity to Device-based
Admin → Reporting identity. Three options: Blended, Observed, Device-based. The first two pull in Google Signals; Device-based relies on the device identifier alone. Switching to Device-based removes most thresholds at the cost of cross-device stitching. Importantly, this is a display setting: it does not change collected data and can be switched back at any time. Test it freely.
2. Drop the Date dimension
If daily granularity is not needed for the question at hand, remove it. A weekly or monthly aggregate almost always clears the threshold where a daily split does not.
3. Widen the date range
Same mechanic in reverse: more users per row, better odds. For campaign demographics use 28–90 days rather than 7.
4. Remove dimensions you do not need
Every extra dimension fragments rows. If the question is “which campaign produces purchases”, do not also add device, city and age to the same table. Ask one question at a time.
5. Turn off Google Signals — deliberately
The most drastic lever, and one with real costs. Disabling Signals removes a large share of thresholds, but also removes cross-device reporting, demographics and interests, and any remarketing audiences built on Signals. For a store with a long cross-device journey that is a bad trade. For single-device lead generation it is often a good one. Note that it is not retroactive: historical data stays thresholded.
6. Move heavy analysis to BigQuery Export
The export delivers raw events before thresholds are applied. It is the only way to get a genuinely uncut view by day and demographic. For teams that hit thresholds weekly this is not an advanced option, it is baseline infrastructure — particularly if you already build funnels and cohorts as described in our guide to GA4 Explorations for paid traffic.
Retention: the quiet deleter of history
The second mechanism is permanent. Admin → Data retention. Standard GA4 offers two options: 2 months and 14 months. GA4 360 offers longer periods. Many properties still sit on the 2-month default — which is why “last year’s Black Friday won’t build” is such a common complaint.
What gets deleted and what survives
| Data type | Affected by retention |
|---|---|
| Standard aggregated reports (Reports → Acquisition etc.) | No — aggregates remain |
| Explorations | Yes — nothing beyond the window |
| Any query using user or event-scoped parameters | Yes |
| Funnels, paths, cohorts, segments | Yes |
| Data in BigQuery Export | No — governed by your dataset settings |
The practical rule: at 2 months you will never compare season to season in explorations, not even retroactively. Deleted data does not come back, and raising the setting to 14 months applies going forward only.
The “reset on new activity” option
Next to the retention setting sits a toggle that restarts the clock for a user on each new visit. For long purchase cycles — B2B, high-ticket products — switching it on keeps returning users inside your analysis window. For one-off traffic the effect is marginal.
The two-minute fix, today
- Open Admin → Data retention.
- If it reads 2 months, set it to 14. It is free and has no downside for the overwhelming majority of properties.
- Decide on “reset on new activity” based on your sales cycle length.
- Check every property, not just the main one — staging and regional properties usually sit on the default.
Moving retention from 2 to 14 months is the cheapest analytics improvement that exists. Two clicks, no risk, and a year from now you have seasonality to compare against.
Thresholds, sampling and “(not set)” — three different causes
These three produce the same vague symptom — “the report looks wrong” — and have completely different cures. Mixing them up costs teams weeks of pointless tag debugging.
| Symptom | Cause | Fix |
|---|---|---|
| Rows missing, warning indicator above the report | Data threshold | Drop Date and sensitive dimensions, widen the range |
| Figures marked as estimates, a percentage of events processed | Sampling | Narrow the range, simplify the exploration, move to BigQuery |
| A large “(not set)” row | Parameter missing at event time | Fix tagging: tag order, parameter passing |
| Nothing before a fixed past date | Data retention | Raise the setting going forward; the past is gone |
| Exactly one day off versus Google Ads | Time zone mismatch | Align property time zone with the ads account |
Sampling is its own animal: it kicks in for explorations over large event volumes and complex queries, and GA4 states the share of data processed directly on the report card. If that figure is below 100%, the numbers are an estimate and arguing over decimals is wasted effort.
“(not set)” in a campaign or source breakdown is almost always a parameter-passing problem rather than a privacy one. Usual suspects: manual UTM tags conflicting with auto-tagging, a click identifier lost on a redirect, a page firing before the tag initialises. That is fixed on the site, and thresholds have nothing to do with it — see GCLID, GBRAID and WBRAID: keeping the click identifier alive.
Four patterns you will recognise
“This campaign has no conversions, pausing it”
A young campaign on a modest daily budget, a report split by day and device, no conversions in the table. The pause decision is being made on hidden rows. Correct order: a 28-day aggregate without sensitive dimensions first, conclusions second.
“Demographics say only men 35–44 buy from us”
The other brackets failed the threshold and are simply not displayed — which is not the same as “they do not buy”. Narrowing targeting on that table means cutting working segments by hand.
“Looker Studio shows less than GA4”
The dashboard reads the Analytics Data API, where the same thresholds apply, and it usually carries more dimensions than the interface report. Simplify the query or point it at BigQuery.
“Last year’s funnel will not build”
That is retention. At 2 months, historical explorations are unavailable and unrecoverable. The only useful action is switching to 14 months today so next season has something to compare against.
A diagnostic order that saves hours
When a number does not add up, check in this sequence — cheapest first:
- The threshold indicator above the report. Present? Stop looking.
- Remove Date from the query. More data appears? Threshold.
- Switch reporting identity to Device-based. Numbers rise? Google Signals threshold.
- Check data retention. Emptiness starts at a fixed date in the past? Retention, not thresholding.
- Compare property time zone with the Google Ads account. Mismatched zones are the classic “off by one day” cause.
- Only now audit tagging. If the first five are clean, the problem is in collection.
Most “tagging problems” in paid traffic turn out to be thresholds or time zones. For the rest of the reconciliation sequence, see Google Ads and GA4 conversion discrepancy: nine causes and a diagnostic order.
What this changes in day-to-day buying
Budget decisions on thin slices
The expensive mistake is pausing a campaign or audience because “it has no conversions” when the rows were simply hidden. Rule: pause decisions get made on aggregates without sensitive dimensions, never on a fine-grained slice. If you genuinely need demographics to decide, widen the window to 28 days or more.
Audiences and remarketing
Reporting thresholds do not shrink the audiences you send to Google Ads — different mechanism. Audiences do have their own size floor and membership duration, covered separately in Google Ads Audience Manager: the 100-user threshold and membership duration.
Dashboards and automated reporting
If a dashboard reads from the Analytics Data API, thresholds apply there as well. The usual symptom is numbers lower than the GA4 interface, or rows that jump between refreshes. Same cure: remove fragmenting dimensions, or point the dashboard at BigQuery.
Privacy as a design constraint, not an obstacle
Thresholds and retention belong to the same shift as Consent Mode and conversion modelling: measurement is becoming probabilistic rather than item-by-item. The answer is not resignation, it is building a stack where the losses are predictable. For the consent side, see Consent Mode v2 and privacy in 2026; for recovering conversions server-side, see server-side tagging with sGTM.
Property settings checklist for 2026
- Data retention: 14 months, not 2. Verified on every property.
- Reset on new activity: on, if the sales cycle exceeds a month.
- Reporting identity: know which one is set and be able to switch it for diagnosis.
- Google Signals: enabled deliberately, with the trade-off understood.
- BigQuery Export: connected if paid traffic is a meaningful revenue source.
- Property time zone matching the Google Ads account time zone.
- Cost data import configured for non-Google channels — see GA4 campaign data import.
Seven items, half an hour once, and from then on you argue about numbers instead of settings.
FAQ
What user count triggers GA4 data thresholds?
Google does not publish a number and states that the threshold is set dynamically based on data volume and context, and cannot be adjusted by users. The commonly cited figure of roughly 50 users per row is an industry estimate, not a documented rule.
Can GA4 data thresholds be turned off?
No. It is a privacy mechanism, not a setting. You can only influence it indirectly: reporting identity, Google Signals, the dimensions in your query, and moving to BigQuery Export.
Why don’t daily figures sum to the monthly total?
Daily rows hold fewer users and get thresholded more often, while the monthly aggregate clears the threshold. Expected behaviour, not an error.
Should I disable Google Signals?
It depends on the model. Disabling removes most thresholds but also removes cross-device reporting, demographics, interests and Signals-based audiences. For e-commerce with a long cross-device path, usually no. For single-device lead generation, often yes.
What does switching to Device-based identity do?
Reports stop using Google Signals data, so a large share of thresholds never fires. You pay with cross-device stitching: one person on phone and laptop counts as two. It affects display only and can be reversed.
Do thresholds apply to the Analytics Data API?
Yes. This is a frequent cause of mismatches between the GA4 interface and external dashboards or connectors. Same fix: remove fragmenting dimensions or move to BigQuery.
Is BigQuery Export data thresholded?
No. The export delivers raw events before reporting thresholds are applied, and it is not bound by GA4 retention. Data lifetime there follows your dataset configuration.
What retention options exist?
Standard GA4 offers 2 and 14 months. GA4 360 offers longer periods. Many properties still run on the 2-month default.
What exactly is lost when retention expires?
User- and event-scoped data that explorations are built on: funnels, paths, cohorts, segments, any parameter-level query. Standard aggregated reports remain available.
Can data deleted by retention be recovered?
No. Deletion is irreversible and raising the setting applies going forward only. That is exactly why the switch from 2 to 14 months should happen today rather than when you need a year-over-year comparison.
How do I tell a threshold from a tracking problem quickly?
Remove Date and any sensitive dimensions from the query. If the data appears, it was a threshold and tagging is irrelevant. If nothing changes, then audit collection.
Do thresholds affect conversion import into Google Ads?
No. Thresholding is a GA4 reporting display mechanism. Conversion import and Smart Bidding are unaffected. The risk is indirect: if you make manual decisions from thresholded reports, you feed the algorithm bad instructions yourself.
In short
Two mechanisms quietly change your numbers. Thresholds hide low-user rows whenever a query touches demographics, interests or Google Signals — and especially when it is split by day. Retention deletes user-level data permanently, often after just two months by default.
Two actions remove most of the pain: set retention to 14 months now, and before touching a budget, ask whether the empty row is a threshold by dropping Date and demographics from the query. Teams that hit the ceiling regularly should add BigQuery Export next.
Related reading: where half your carts die between the click and the payment on measuring and fixing the post-click stretch, plus the rest of the PPC Rebels blog.
