Is Google Analytics Reliable?

Is Google Analytics Reliable?

Somebody in a meeting says the traffic number looks wrong. Somebody else opens the ad platform, finds a different number, and the afternoon is gone.

The useful question is not whether Google Analytics is accurate. It is which numbers Google stands behind, which ones it describes as estimates, and which ones it declines to put a figure on at all.

Google's own documentation answers all three, and the answers are more interesting than the arguing.

The short version is that GA4 is a sound instrument for direction and a poor one for absolute counts.

That is not a criticism anyone has to infer. Google says it on its own help pages, in writing, in several places.

What follows is drawn only from Google's published documentation, with the gaps named where they exist.

Is Google Analytics reliable? The short answer

Yes, for what it is built to do: comparing periods, ranking channels, spotting a trend breaking, and telling you which pages earn attention.

Within one property, measured the same way over time, GA4 is consistent enough to make decisions on.

No, for reconciliation. If your goal is to make GA4 agree to the unit with an ad platform, a server log, or a CRM, you are attempting something Google has never claimed the product does.

Four documented mechanisms separate the number in the interface from the number of things that actually happened: sampling, thresholding, cardinality limits, and behavioural modelling. None is a bug. Each is a deliberate trade, and each is documented.

Not sure which of your numbers you can actually trust? Get a free SEO audit at seo-stuff.com/free-audit and work from the ones that hold up.

What Google actually says about GA4 data

The four mechanisms behave differently, affect different surfaces, and have very different amounts published about them. Taking them one at a time is the only way to know which of your own reports is affected.

Sampling: documented trigger, undocumented error

Sampling happens when a query needs more events than your property's quota allows.

Google puts the standard-property quota for event-level queries at 10 million events, against up to 1 billion for Analytics 360. Above the line, Analytics works from a subset and scales the answer up.

Google describes the output as "directionally accurate results that are representative of all your data" and notes that a larger sample gives a more accurate result.

What it does not publish anywhere is a margin of error. There is no stated confidence interval for a sampled GA4 report, and no figure for how far a sampled number can drift from the true one.

That is worth sitting with. Sampling is the mechanism people worry about most, and it is the one Google quantifies least.

A single country filter on a large dataset is enough to trigger it in both standard reports and Explore.

Thresholding: no published trigger at all

Thresholding withholds rows so that a report cannot be used to identify an individual. It fires on demographic and signals-backed data, and on narrow date ranges where user counts are low.

Google is blunt about your control over it: "Data thresholds are system defined. You can't adjust them." The page refers to minimum aggregation thresholds without ever saying what those minimums are. There is no number to look up.

This one is easy to misread as missing data. A row that vanishes when you narrow the date range has not been lost; it has been suppressed, and widening the range usually brings it back.

Cardinality: the row that eats your long tail

When a dimension carries more unique values than a table can hold, Analytics keeps the common values and sweeps the rest into a single row labelled (other).

Google offers 500 unique values as the point at which to treat a dimension as high-cardinality, but is careful about its status: "The 500 values per dimension is not a limit, but a guidance." Actual row limits are not published as numbers, and vary by property type, report, and query complexity.

Explorations and Data API responses are the usual casualties. Standard reports built on one dimension are rarely affected.

Behavioural modelling: estimates, labelled as such

Where users decline analytics cookies, GA4 can fill the gap with machine learning rather than leaving it empty. Google states plainly that Analytics applies machine learning to estimate the behaviour of those users.

The eligibility bar is published: roughly 1,000 events a day carrying analytics_storage='denied' for at least seven days, alongside a similar volume of consented traffic.

Meeting it does not guarantee modelling is applied, because the model also weighs ratios Google does not publish.

Nor is there any accuracy figure. Google says modelling is included only where there is "high confidence of model quality" and leaves the phrase undefined.

Your analytics should settle arguments, not start them. Claim your free audit at seo-stuff.com/free-audit.

How to check whether your own reports are affected

Most of this is visible from the interface in about ten minutes.

• Open the report or exploration in question and look for the sampling indicator near the title. Google surfaces the sample size there when a query has been sampled.
• Scan the table for a row named (other). If it is present and large, your long tail has been collapsed and any ranking below the top rows is unsafe to read.
• Check for a thresholding notice, then widen the date range and reload. Rows that reappear were suppressed, not absent.
• Look at the property's reporting identity setting. Blended identity brings modelled data into the numbers; device-based does not.
• Compare the same metric in a standard report and in an exploration for the same dates. A gap between them usually means one of the two was sampled or thresholded.
• Note your data retention setting, then read the next section before assuming it explains a missing year.

Retention is the one that catches people out most often, because its scope is narrower than the name suggests. Google limits it explicitly: "The data retention setting only affects explorations and funnel reports." Standard aggregated reports keep working past the retention window.

A two-month setting does not erase your year-over-year trend line in standard reporting, though it does gut your explorations.

What GA4 is reliable for

Direction, composition, and relative change. If organic sessions are up a third quarter on quarter, that is real, whatever the absolute figure is.

If one landing page converts at four times the rate of another, the ratio survives every mechanism above, because both numbers were distorted the same way.

Event counts for ordinary interactions are among the sounder figures in the product.

Modelling is applied to user, session, and new-user counts rather than to raw event counts such as page views, so a page_view total is closer to a straight tally than a session total is.

Purchase counts hold up better than most people expect. Google's own comparison guidance says web purchase counts should match closely, which makes revenue a reasonable place to reconcile and sessions a bad one.

Sessions are the metric to be most careful with, and Google is clear why: GA4 properties use what it calls "a statistical estimate of the number of sessions".

The headline number on most dashboards is, by Google's own description, an estimate.

Where the documentation goes quiet

Several of the gaps matter more than the published numbers do, and they cluster in one place: the size of the error.

No error bound for sampling. "Directionally accurate" is the strongest claim Google makes about a sampled report. No percentage, no interval, nothing to put in a footnote.

No numeric thresholding trigger. The mechanism is documented, its effects are documented, and the number that fires it is not.

No GA4 discrepancy magnitude against anything outside GA. This is the striking one. Google does publish a quantified expectation for Universal Analytics against GA4: page-view discrepancies up to 10%, and user and session discrepancies up to 20%, described as "not a cause for concern". It publishes no equivalent figure for GA4 against an ad platform, a server log, or a CRM. The only tolerance Google ever quantified was between two of its own products, one of which is gone.

Ad blockers and browser tracking prevention are not addressed. Safari's and Firefox's tracking protection, and extension-level blocking, go unmentioned across Google's data-quality pages, despite being a leading cause of real-world undercounting. Google documents the loss it creates itself through consent refusal and says nothing about the loss created for it by the browser.

Attribution keeps moving after the fact. Google allows attributed key events to update for up to seven days after the event is recorded, and says more than 95% are attributed within fourteen days. A conversion figure read on day one is provisional by design.

Modelled numbers do not reach your warehouse. Behavioural modelling is not applied to BigQuery export, audiences, retention reports, or predictive metrics. Google also notes that Analytics does not export Google-signals data to BigQuery, and that per-user event counts can differ between the two. Your warehouse and your dashboard are expected to disagree.

Reconciling two numbers that were never meant to match? Start with a free audit at seo-stuff.com/free-audit.

GA4 versus the alternatives

No single source is the truth. Each one is reliable for a different question, and picking per question beats picking a favourite.

• Server-side logs count requests, so they catch what client-side tags miss, including users who blocked the tag. They cannot tell you intent, scroll depth, or which channel sent someone, and they count bots enthusiastically.
• BigQuery export gives you event-level rows with no sampling and no row limits, which makes it the right tool for long-tail and cohort work. It also gives you none of the modelling, so it will read lower than your reports rather than more accurately.
• Ad platform reporting uses its own attribution window and counts a conversion the advertiser's way. Treating its number as the correct one and GA4's as the error is a category mistake; they are answering different questions.
• A CRM or payment processor is the only honest source for revenue, because it is the system where the money actually moved. Reconcile money there and traffic in GA4.
• Privacy-first analytics tools avoid consent banners and the modelling that follows, which makes their counts simpler to explain. They are also thinner on funnel, audience, and attribution work.

The practical setup for most teams is GA4 for behaviour and direction, the payment system for revenue, and BigQuery export for anything where the long tail is the point.

Final Thoughts

Google Analytics is reliable in the way a well-calibrated instrument is reliable: consistent, honest about its own limits, and wrong if you read it as a census.

Google documents the sampling trigger, the thresholding behaviour, the cardinality guidance, and the modelling eligibility bar. It declines to publish an error bound for any of them, and it has never published a tolerance for GA4 against an outside source.

So stop trying to make the numbers match. Fix the reporting identity, learn to spot the (other) row, widen the date range when a row disappears, read revenue out of the system that took the payment, and judge GA4 on trend and ratio, where it is genuinely strong.

If a chunk of your traffic is going uncounted before any of this applies, the cause is usually collection rather than reporting. Our guide to whether Safari blocks Google Analytics covers that side of the problem.

Want a clear read on your organic performance? Get a free SEO audit at seo-stuff.com/free-audit and see what your data can actually support.