GA4 gives you two ways to look at the same data. The standard reports (Reports snapshot, Acquisition, Engagement, Monetization) are pre-aggregated, fast, unsampled, and answer the questions Google predicted you would ask. The Explore tab is a freeform workbench: any dimension against any metric, funnels, path analysis and segment overlap — at the cost of sampling on large date ranges and a sharper need to understand what you are asking.
A working rule: monitor in Reports, investigate in Explore. If a standard report answers the question, use it — the numbers are stable and match what stakeholders see. Reach for Explore when you need a breakdown the standard reports refuse to give you, and when you do, the two traps below are what make its numbers diverge from the reports you left behind.
Scopes: why the same metric differs between reports
You build an Explorations report in GA4, add "Conversions" as a metric, and get a number. Then a colleague sends you the same report built a different way and the conversion count is 30% higher. Neither of you changed the date range. So what happened?
Nine times out of ten, one of you is looking at event-scoped data and the other is looking at session-scoped or user-scoped data. Scope is the single most common source of unexplained number discrepancies in GA4, and it is almost never explained clearly in Google's own documentation.
This guide cuts through it. You will understand what each scope actually means, see where the confusion comes from in practice, and know exactly which scope to reach for in an e-commerce or lead gen context.
What "scope" means in GA4
Every dimension and metric in GA4 lives at a particular level of the data hierarchy. GA4 has three main levels: the event (a single action), the session (a group of events within one continuous visit), and the user (all sessions from one person over time). Items — the individual products in an e-commerce transaction — form a fourth, nested level that sits inside events.
When you mix dimensions and metrics from different scopes in the same report, GA4 has to decide how to aggregate. It does not throw an error. It just quietly picks a method that can produce results you did not expect.
The core rule: A metric is only meaningful when the dimension describing it lives at the same scope or a higher scope. Mixing lower-scope metrics with higher-scope dimensions inflates counts; mixing higher-scope metrics with lower-scope dimensions collapses them.
… plus a second session two days later
A user contains sessions; a session contains events; a purchase event contains items. A metric only makes sense with a dimension from the same level or one above it — mixing levels is how two “identical” reports end up 30% apart.
The three scopes compared
Here is a side-by-side view of what each scope covers, the kinds of events that live there, which metrics they affect, and when you should actually reach for them.
| Scope | Definition | Typical events / dimensions | Metrics it governs | When to use it |
|---|---|---|---|---|
| Event | A single hit sent to GA4. Each trigger of gtag('event', ...) or a GTM tag is one event. |
page_view, click, scroll, form_submit, custom events. Parameters attached to that specific hit. |
Event count, conversions (counted per event occurrence), event value. | Counting how often something happened. Funnel analysis. Measuring raw volume of a specific action. |
| Session | All events fired during one continuous visit. A new session starts after 30 min of inactivity or at midnight. | Session source / medium / campaign, landing page, session default channel group, session_start. |
Sessions, engaged sessions, session conversion rate, session duration, sessions per user. | Traffic analysis. Channel performance. Evaluating whether a visit resulted in a conversion — regardless of how many conversion events fired in that visit. |
| User | All events and sessions attributed to one person (device) over the selected date range. | User first/last touch dimensions, user lifetime metrics, user ID, audience membership. | Total users, new users, returning users, user conversion rate, lifetime value. | Understanding your audience. Retention and loyalty analysis. Reporting the proportion of people who ever converted, not just how often. |
| Item | An individual product record nested inside a purchase or add-to-cart event. | item_name, item_id, item_category, item_brand, item_variant. |
Items purchased, item revenue, items added to cart, item list clicks. | Product-level performance. Which SKUs are driving revenue. Category and brand analysis in e-commerce. |
Why the numbers diverge
Consider a single user who visits your site and completes a purchase form three times in one session — perhaps they had a payment error and retried. At event scope, that counts as three conversion events. At session scope, it is one converting session. At user scope, it is one converting user.
"Conversion rate" in GA4 is not one number — it is three different calculations depending on whether the denominator is events, sessions, or users. All three can be correct; only one will be appropriate for the question you are actually asking."
This is not a bug. All three numbers are accurate descriptions of what happened — they are just answering different questions. The problem arises when a report label says "conversions" without making the scope obvious, and readers assume they are comparing the same thing.
Common mistakes and how to avoid them
Mixing session dimensions with event metrics in Explorations
The most frequent mistake: you add Session default channel group (a session-scoped dimension) to a free-form exploration, then add Conversions as a metric. GA4 will count a conversion for every conversion event that occurred in sessions attributed to each channel — which means a single session containing two purchase events contributes two conversions to the channel total. This inflates channel-level conversion counts compared to what you would see in the standard Traffic Acquisition report.
The fix: when analysing channel performance, either use the Traffic Acquisition report (which is session-scoped by default) or be deliberate about using session conversion rate rather than raw event conversions. Read more about how event parameters feed into these dimensions.
Using user-scoped conversion rate to optimise paid campaigns
User conversion rate answers: "of all the people who visited, what fraction ever converted?" That is a useful retention metric. It is a poor metric for evaluating a Google Ads campaign, where you want to know whether the traffic from this campaign converted during the session it drove. Session conversion rate — or even event-level key events tied to your GA4 conversion configuration — is the right choice here. Using user-scoped rate for campaign optimisation underweights campaigns that drive quick, single-session purchases and overweights brand campaigns where users return later.
Pulling item revenue without matching item dimensions
Item revenue is an item-scoped metric. If you combine it with a session-scoped dimension like Session campaign, GA4 has to fan out: every item in every purchase event in every session attributed to that campaign gets counted. For orders containing multiple products, each product's revenue is attributed to the campaign separately, which can make a campaign's "revenue" appear much higher than the actual order total. Use item dimensions (item_name, item_category) when reporting item revenue, and use event-level purchase revenue when you want campaign-level attribution. Your dataLayer implementation needs to populate both correctly for this to work.
Practical scope selection: e-commerce
For an online store, here is a straightforward decision tree:
- Which products sell best? Item scope. Use
item_nameoritem_idwith items purchased and item revenue. - Which channel drives the most revenue? Session scope. Use the Traffic Acquisition report or session-scoped dimensions with
purchaseevent revenue. - What share of visitors ever buy anything? User scope. User conversion rate with the purchase key event.
- How many times did the checkout complete? Event scope. Raw conversion count on the
purchaseevent. - Did this campaign pay for itself? Session scope, cross-referenced with your attribution model. Session conversion rate and event value tell you revenue per converting session.
Practical scope selection: lead generation
Lead gen sites do not have item scope to worry about, but the session vs. user distinction still matters significantly.
- How many enquiry forms were submitted? Event scope. Count of the
generate_leadorform_submitkey event. - Which landing pages convert visitors into leads? Session scope. Landing page dimension with session conversion rate. This shows whether a given page turns a visit into a lead submission — not whether the same person submitted multiple forms.
- Are returning visitors more likely to convert? User scope. Segment by new vs. returning users and compare user conversion rate. This is where sampling limits can bite you if your property has heavy traffic.
- Do leads from paid search look different from organic? Session scope with source/medium dimensions. Watch for the scope mismatch issue described above — use session conversion rate, not event conversion count, when comparing channels.
A note on how GA4 surfaces scope in the UI
The standard reports (Acquisition, Engagement, Monetisation) are pre-built with consistent scoping — Google has made the scope decisions for you and they are generally sensible. The risk is highest in Explorations, where you can drag any dimension next to any metric with no warnings. If a number looks wrong in an Exploration, the first thing to check is whether your dimensions and metrics are at the same scope.
In BigQuery exports, every row is a single event, so you are always starting at event scope and aggregating upward deliberately — which is actually cleaner for avoiding these mistakes, even if it requires more SQL. If your GA4 numbers diverge from a BigQuery query, scope is again the first suspect.
Understanding scope also clarifies some of the discrepancies between Search Console and GA4 — Search Console reports at the session level (one click = one visit) while GA4 event metrics can count multiple hits per session, widening the gap.
Summary
Scope is not a technicality — it determines what question your data is actually answering. Before you build any custom report, ask yourself: am I trying to count actions, visits, or people? Pick the scope that matches, use dimensions from that same scope, and the numbers will make sense. When they still do not, check whether a colleague built the same report from a different scope. That is almost certainly the explanation.
Sampling and thresholds: when your data is not your data
Standard reports
Unsampled ✓
pre-aggregated tables
Explore
Standard reports never sample. Explore reads raw events with a ~10M-event quota per query (Analytics 360 raises it) — shrink the date range or move to BigQuery when you cross it.
You are looking at an Explorations report when a small yellow warning icon appears at the top of the screen. You hover over it. It says something about "data thresholds applied" or "results are based on a sample of your data." You make a mental note and move on.
You should not move on. Those warnings mean GA4 is showing you something other than your actual data — and the two warnings mean fundamentally different things. One is a statistical estimation problem. The other is a privacy mechanism that removes rows entirely. Treating them the same way will lead you to the wrong fix.
This guide explains what each one is, when it triggers, what the yellow icons are actually telling you, and how to get clean numbers when you need them.
Sampling and thresholding are not the same thing
The confusion is understandable because both produce warning icons and both make your data incomplete. But they are caused by different things, they affect your data differently, and they require different responses.
GA4 does not process all your events. It takes a statistical subset and extrapolates the result. The numbers you see are estimates. All rows are present, but none of the counts are exact. Appears in Explorations when query complexity or date range pushes the data volume too high.
GA4 removes specific rows from results to prevent identification of individual users. The numbers you see for included rows are accurate, but some rows are missing entirely. Triggered by low user counts or when Google Signals is enabled. A privacy control, not a performance one.
The practical implication: if you are sampled, all your numbers are slightly off but you can see every segment. If you are thresholded, your numbers for visible segments are correct but some segments have been silently dropped — usually the smallest, most specific ones.
Sampling in Explorations: the 10 million session threshold
Standard GA4 reports (Acquisition, Engagement, Monetisation) run against pre-aggregated data and do not sample. Sampling only affects Explorations — the ad-hoc query interface where you build free-form, funnel, path, and cohort analyses.
Google's published threshold for unsampled Explorations in the free tier is 10 million sessions within the selected date range. Once your query would touch more than 10 million sessions, GA4 switches to a sampled subset and extrapolates results. The sampling percentage is shown in the warning — you might see "Based on 17% of sessions" on a very large property with a wide date range.
Two factors make sampling more likely beyond raw session volume. A wide date range naturally encompasses more sessions. Adding multiple dimensions forces GA4 to evaluate more combinations, increasing query cost. Both push you toward the sampling threshold faster than volume alone.
Thresholding: the privacy layer you cannot turn off
Thresholding is GA4's mechanism for protecting individual user privacy in reports. When the number of users behind a particular row drops below a threshold Google considers identifiable, that row is removed. The remaining aggregate totals in the report may not add up to what you would expect because the removed rows' data is not redistributed — it simply disappears.
The most commonly documented trigger is fewer than 10 active users in a row. Google does not publish the exact algorithm, and the threshold can vary by report type and property configuration. What is consistent is that enabling Google Signals — the cross-device and demographic data feature — significantly increases the likelihood of thresholding, because Signals requires more rows to be suppressed to prevent re-identification of signed-in Google users.
If you have Google Signals enabled and you are seeing large amounts of "(other)" traffic or rows disappearing in Explorations, thresholding is the likely cause. The workaround is to disable Google Signals in Admin > Data Settings > Data Collection if demographic and cross-device data are not worth the trade-off for your use case.
What the yellow warning icons actually mean
Yellow lightning bolt (Explorations): Sampling is active. The figure shown is an extrapolation. Check the percentage in the tooltip — a 90%+ sample is usually acceptable; below 50% and the numbers deserve real scepticism, especially for small segments.
Yellow shield / "Data thresholds applied" (Explorations & standard reports): One or more rows have been removed for privacy reasons. The totals at the top of the report may not match the sum of visible rows. This is most common when Google Signals is on or when you are filtering to a narrow segment with low user counts.
Yellow triangle in standard reports: A generic data quality warning. Can indicate delayed data processing, a temporary data collection issue, or an active change to property configuration. Click through to the data quality icon panel for the specific reason.
The important distinction: a lightning bolt means the numbers are approximate but the rows are real. A shield means the rows shown are accurate but some rows are missing. Both require a response, but different ones.
Date range strategies to reduce sampling
If you are being sampled, the quickest fix is to reduce the date range. A query over 90 days on a high-traffic property may sample heavily; the same query run monthly and combined manually often produces unsampled results for each period. This is tedious but effective.
The other lever is dimension count. Each additional dimension multiplies the number of possible combinations GA4 has to evaluate. If you are running a six-dimension Exploration and hitting sampling, try removing dimensions that are not essential to the specific question and running separate reports for secondary breakdowns.
"You cannot always avoid sampling in the GA4 UI — but you can almost always avoid it in BigQuery. For any analysis where accuracy matters more than convenience, the export is not a workaround, it is the right tool."
BigQuery export: the definitive fix for both problems
The BigQuery export is the only guaranteed path to unsampled, unthresholded data. When you export GA4 to BigQuery, you receive every event row — no estimation, no privacy suppression, no row removal. You are working directly with the raw event stream.
This matters because both sampling and thresholding are artifacts of the GA4 reporting layer, not the underlying data collection. The events were recorded. They exist. The reporting interface is just choosing not to show them all. BigQuery bypasses that layer entirely.
The BigQuery export is available on all GA4 properties at no cost from Google (though BigQuery itself charges for storage and query compute at modest rates for typical analytics workloads). Enabling it requires a Google Cloud project. Once linked, GA4 exports a daily flat file of events with full parameter detail — the same data that feeds event parameters and scope-based aggregations in the UI, but without the reporting layer's constraints.
If your team does not use SQL, the Looker Studio connector for BigQuery is an alternative that can query the export directly and circumvent sampling in dashboards — though it requires more configuration than the native GA4 Looker Studio connector.
Quick reference: triggers, types, and workarounds
| Trigger condition | Type | Where it appears | Workaround |
|---|---|---|---|
| Explorations over large date ranges (typically >30 days on high-traffic properties) | Sampling | Explorations only — free-form, funnel, path, cohort | Shorten the date range and combine periods manually; or export to BigQuery for unsampled queries. |
| Custom Explorations with many dimensions (4+), especially combined with large date ranges | Sampling | Explorations | Reduce dimension count; split into separate targeted reports; use BigQuery to run the full multi-dimension query without limits. |
| Reports or Explorations with rows containing fewer than ~10 users, especially with Google Signals enabled | Thresholding | Explorations; standard reports when filtered to small segments | Disable Google Signals if demographic/cross-device data is not required. Broaden the segment or date range to raise per-row user counts above the threshold. Use BigQuery export for the full data. |
| Date ranges crossing the 2 million events/day processing threshold (GA4 free tier) | Sampling | Explorations; may affect some standard report breakdowns | GA4 360 removes this limit. Alternatively, export to BigQuery (free tier export is unaffected by the UI processing limit) and query there. Alternatively, split date ranges to stay within daily limits. |
The issue with "(other)" rows
A related but distinct problem: GA4 standard reports collapse low-traffic rows into an "(other)" bucket at the bottom of tables. This is separate from thresholding — it is a display limit (GA4 shows a maximum of 500 rows in most standard report tables) rather than a privacy mechanism. The "(other)" row can account for a significant share of sessions on large properties with many landing pages, campaigns, or event names.
The fix for "(other)" is different from the fix for thresholding: use Explorations (which supports up to 50,000 rows in a single view) or export to BigQuery. Do not assume "(other)" means privacy suppression — it usually means the UI table ran out of rows, and all the data is still there waiting to be queried properly.
Understanding these data quality signals also helps explain some of the discrepancies you will see between Search Console and GA4 — when GA4 Explorations are sampled, the session counts shown will diverge from Search Console's click data, which is not sampled in the same way.
Summary
Two yellow icons, two different problems. Sampling is a performance trade-off — GA4 estimated instead of calculated because the query was too large. Thresholding is a privacy mechanism — GA4 removed rows to protect users from re-identification. Both make your data incomplete, but they do so differently and require different responses. For anything where the precise number matters — a business decision, a client report, an anomaly investigation — BigQuery export is the one workaround that eliminates both.