GA4 Explorations and Reports: Why the Same Question Returns Different Numbers

A client screenshots 4,318 users in the Acquisition report. You rebuild the same question in Explorations and get 3,977. Nobody edited a tag, nobody changed a filter, and the property is the same property. The obvious conclusion is that tracking broke somewhere between Tuesday and Thursday.

It usually did not. Reports and Explorations are separate surfaces with separate rules, and Google documents seven ordinary reasons they disagree. Knowing which one you are looking at turns a two-hour investigation into a two-minute answer, and it stops you from "fixing" a tag that was never broken.

Four surfaces, four answers

Start with the shape of the problem. GA4 gives you four ways to ask a question, and they are not four views of one number.

Reports and Explorations share a data source but differ in limits. A property holds up to 150 custom reports. Each user can hold up to 200 individual explorations, and a property can hold up to 500 shared ones. The Data API reaches the same data under its own quotas. BigQuery export is a different product entirely, capped at one million events per day on a standard property and effectively uncapped on 360.

The differences run deeper than row limits. A dimension with more than 500 unique values in a single day is high cardinality, and in Reports, Explorations and the API the rows past the limit collapse into an (other) row. BigQuery does not condense anything. Sampling can appear in the first three and never in BigQuery. Data-driven attribution appears in the first three and not in BigQuery. Key event modelling appears in the first three and not in BigQuery. Behavioural modelling is included in reports, including realtime, but inside Explorations it only applies to path, funnel, segment overlap and free-form tables.

So BigQuery is the record and the interface is the argument. If two surfaces disagree, the question is which rule is doing the cutting, not which one is lying.

Reason one: the field does not exist in Explore

Open a report inside Explorations and any dimension or metric that Explorations does not support is dropped. If the report's visualisation depended on that field, the visualisation does not appear at all.

This is the most common source of a blank canvas, and it is routinely misread as missing data. Before you go looking for a collection problem, confirm the field you are breaking down by is available in the Explore module. If it is not, the report was right and the exploration cannot be.

Reason two: two filters, two matching rules

The filter in Explorations lets you choose the match type, such as contains, exactly matches or begins with, and the expression you type is case sensitive. The Search field in a report is a contains match and it is not case sensitive.

That single difference moves numbers. A search for the word google in a report also returns Google and GOOGLE. A contains filter for google in an exploration does not. On a property with a messy source or campaign dimension, that is a real row difference, and it is a correct one. Import your sources carefully and the two surfaces converge. Import them carelessly and the gap will look like data loss.

Reason three: your comparison became a segment

Comparisons in reports can use fields that Explorations does not support. When you open such a report in Explorations, the comparison is converted into a segment, and any unsupported field inside it is dropped from that segment. The result is a segment that is not quite the comparison you built, so the rows it includes and excludes change.

The fix is to rebuild the comparison as a segment using fields the module supports, then rename it so the next person knows it was rebuilt. A converted comparison and a hand-built segment are not interchangeable and should never be compared side by side in a client deck.

Reason four: retention decides how far back Explore looks

Date ranges in Explorations are limited by your property's data retention settings. Create a report with a range that reaches past user and event level retention, open it in Explorations, and the older portion simply will not be there.

A standard property retains user and event level data for either two months or fourteen months, chosen under Admin, Data collection and modification, Data Retention. The default is the shorter option, and it is the one most properties are still on. A year-on-year exploration on a two-month property returns a fraction of what the report shows, because the report was reading aggregate tables that outlive the event data.

Reason five: thresholds and sampling, two different yellow icons

Two separate mechanisms can thin an exploration, and the interface signals both with the same colour change, so read the tooltip rather than the icon.

Data thresholds are system defined and cannot be adjusted. They apply when a report or exploration includes demographic data, or an audience defined using demographic data, and rows containing search query information can be withheld when total users are too low. When a threshold bites, the data quality indicator at the top says that Analytics has applied thresholding and will only display the data when it meets minimum aggregation. The lever you have is a wider date range, which raises the user count and often reveals the withheld rows.

Sampling is a different animal. It kicks in when the events returned by an exploration exceed the limit for your property type, and Google documents the boundary at more than ten million events in a particular exploration query. Analytics then answers from a representative sample. Analytics 360 properties have access to unsampled explorations, standard properties do not. For an ecommerce property with a busy checkout, ten million events is easier to reach than it sounds.

One more consequence worth stating to a client: Analytics does not export Google signals data to BigQuery, so per-user event counts can legitimately differ between the interface and the warehouse even with no thresholding in play.

Reason six: behavioural modelling runs on two data sets

If behavioural modelling for consent mode is on, expect small differences between a standard report and an exploration. Reports are modelled from aggregated tables. Explorations are modelled from raw event and user level data. Those two structures are different, so the modelled output differs slightly, and the probability of a visible gap rises with the number of users who declined analytics cookies.

That makes the gap itself informative. A large difference between the report and the exploration on a consent-heavy site is a rough read on how much of your traffic sits behind a refusal. It is not a precise measurement, but it is more useful than treating the discrepancy as an error.

Reason seven: the last 48 hours are still settling

Data arrives from several systems and is processed at different times. Queries covering the past 48 hours can return slightly different results from one surface to the next. This one resolves itself, and it is the reason a numbers argument on a Monday morning is a waste of everyone's afternoon.

The techniques bring arithmetic of their own

Even with the same data, each exploration technique applies its own rules, and those rules are where most unexplained numbers actually come from.

Funnels are the worst offender. In an open funnel users can enter at any step. In a closed funnel they must enter at step one. Users are counted only in steps they complete in the specified sequence, and a missed step drops them out of everything after it. Only the first sequence is reported, so a user can enter a funnel once. There is a documented oddity on top of that: a user who starts mid-funnel, moves back to step one and then proceeds is counted in step one for a closed funnel but not for an open one. Steps can be set as directly or indirectly followed, with an optional time window, and steps cannot be defined on metrics at all.

Funnel breakdowns add another layer. When you apply a breakdown dimension, a user is attributed only to the first value that applied to them. A visitor who enters on mobile and converts on desktop appears in every step, but only under mobile. Trended funnels do the same with dates, attributing each user to the first date they were active in that step. The Show elapsed time toggle averages the microseconds between steps and counts only the first occurrence of a repeated sequence.

The Top 5 Next Actions card deserves its own warning. A (no next action) entry does not always mean drop-off. With page or screen dimensions it can mean the dimension value did not change between steps, so the page title was identical before and after.

Cohorts ignore User-ID entirely. Cohort membership is built from device data only, which is why a cohort table can show more users than the same period in a report on a property with cross-device activity. Cohort explorations cap at 60 cohorts, show the top 15 values of a breakdown dimension, and lose rows to thresholding when demographic dimensions are involved.

Path explorations cap at five nodes per step by default, expand to 20 with More, and group everything past that into an Others node. They take a starting point or an ending point, never both, and grey nodes mark the end of a path.

The structural limits matter too. An exploration holds up to 20 dimensions and 20 metrics, up to 10 segments, up to 10 filters per tab, and up to 10 tabs. Sharing requires at least an Analyst role, viewers can open a shared exploration but not edit it unless they duplicate it, and only the creator can delete one.

A check order before you file a bug

Run these in sequence. In practice the answer arrives within the first three.

1. Confirm both surfaces use the same date range, then check retention. On a two-month property, a long exploration is the explanation by itself.

2. Confirm the dimension or metric exists in Explorations. A dropped field is not missing data.

3. Rebuild the filter by hand. Match type and case sensitivity differ between the two surfaces.

4. Rebuild any converted comparison as a native segment.

5. Read the data quality tooltip. Decide whether you have thresholding or sampling, because the remedies differ.

6. Widen the date range before you widen the investigation. Most threshold gates open on their own.

7. Remove demographics and Google signals from the breakdown and re-run. If the gap closes, you found it.

8. Leave the last 48 hours alone. Compare a settled period instead.

Only after all eight should you open DebugView. DebugView answers a different question, about whether events arrive at all, and reaching for it first is how a reporting configuration difference becomes a two-day tag hunt.

The habit that prevents the argument is simpler than any of this. Write down the surface, the date range, the retention setting and the filter logic next to every number that leaves your team. A number without that context is not a measurement, it is a screenshot, and screenshots cannot be defended in a meeting.