Why Your Analytics Tools Never Show the Same Number

Three tools, three answers. GA4 reports 9,800 sessions, the product- analytics tool logs 7,100 tracked users, and Stripe shows 214 paid conversions against GA4's 258. Someone in the growth meeting asks which number is correct, and the honest answer — all of them, for different questions — never satisfies. So teams burn hours trying to force the tools to agree, or worse, quietly pick whichever number tells the story they wanted. Both responses misunderstand the problem. Analytics tools are not supposed to match, and the discrepancy itself carries information if you know how to read it.

The tools disagree because they measure different things, from different points in your stack, under different rules for bots, consent, sessions, and attribution. A difference of 10 to 20 percent between comparable platforms is, as practitioners put it, completely normal — two systems that "measure different things and report data in ways that were never designed to match perfectly" (Windsor.ai). This post explains the structural reasons the numbers diverge, how to tell a normal gap from a real bug, which tool to trust for which question, and the reconciliation workflow that turns three arguing dashboards into one defensible decision.

Why the numbers structurally diverge

The first cause is that each tool counts a different event at a different moment. GA4 and Google Ads are the canonical example: Google Ads counts conversions on the click date, while GA4 counts on the conversion date, so the same conversions land in different reporting periods and the totals never line up day to day. Add attribution models — last-click here, data-driven there — and scope differences, where one tool reports a campaign at session scope and another at user scope, and you have several independent reasons for two "conversion" numbers to differ before anyone has made a mistake. The requested dimensions and metrics are simply not the same thing, even when they share a label.

The second cause is that the tools apply different corrections to the raw stream. Each filters bots by its own rules, so an invalid-traffic surge that one tool strips out can inflate another — the mechanics of which are covered in bot and invalid traffic inflating SaaS metrics. GA4 also applies sampling on large queries and, critically, models conversions under consent gaps: in high-rejection regions consent-mode modeling can leave a tool undercounting by 20 to 40 percent relative to a system that fires server-side or first-party. That single factor explains many of the largest web-versus-product-analytics gaps, and it is the same undercount examined in GA4 traffic undercounting and the consent-decline data gap.

Normal gap versus real bug

The useful skill is not eliminating discrepancies but calibrating which ones to ignore. A steady 10 to 20 percent gap between two web tools is baseline noise from differing bot filters, session definitions, and consent handling — it needs no action beyond being documented. A consistent 20 to 40 percent undercount in one tool points to a specific structural cause, usually consent modeling or a server-side-versus-client difference, and it is stable rather than alarming once you know its source. These are the gaps you learn to expect and read past.

A real bug looks different: it is large, sudden, or one-sided. A gap that jumps from the expected 15 percent to 60 percent, or a metric that doubles in one tool while staying flat in the others, is almost never a change in user behavior — a genuine behavior change shows up proportionally everywhere. It is an implementation fault: a tag firing twice, a tag removed in a deploy, a consent-banner change, or a UTM collision where, as one troubleshooting guide notes, the same UTM code reused across campaigns "can lead to inflated session counts" (Stape). The diagnostic rule is simple: proportional change across all tools is probably real; a gap that opens in one tool alone is probably broken tracking. Formalizing these expected baselines is exactly what a standing data-quality audit checklist is for.

Assign authority per question, not per tool

The instinct to name one tool the "source of truth" is where reconciliation goes wrong, because no tool is authoritative for every question. Authority is per metric, not per platform. Your billing system is truth for revenue and paid conversions, because it records the actual money-changing-hands event and has no reason to model or sample it. Your product-analytics tool is truth for in-app behavior and activation, because it fires on real actions inside the product where web analytics cannot see. Web analytics is truth for acquisition and traffic sources, accepting up front that it undercounts under consent gaps.

Framed this way, the 214-versus-258 conversion gap stops being a contradiction to resolve and becomes two correct answers to two different questions: Stripe counts completed purchases, GA4 counts a web-attributed conversion event that includes some it modeled and some that never became revenue. You reconcile them by mapping the definitions, not by forcing the totals to match. This is the tool-to-tool version of a problem that also shows up inside a single team when two people define "active user" differently — the discipline of one agreed definition per metric is covered in metric definition drift and the single source of truth.

The reconciliation workflow

Before declaring that two tools disagree, make them answer the identical question. Most apparent discrepancies are definition mismatches, so align four things first: the date range, the exact metric definition, the scope (session versus user versus event), and the attribution window. In GA4 specifically, the recommended move is to use the Explore section to query exactly the same combination of metrics and dimensions as your connector or other tool, at which point, as Windsor's documentation notes, the numbers should converge much closer than the canned reports suggested. Much of what looks like a data problem dissolves at this step.

Whatever gap survives that alignment is your baseline, and the discipline is to record it. Document, per metric pair, the expected residual difference when instrumentation is known-good — GA4 sessions run roughly X percent above product-analytics users, Stripe conversions run roughly Y percent below GA4 conversions — and treat those figures as the reference line. Now discrepancy monitoring becomes tractable: you are no longer asking "why don't these match" every week, you are watching for the baseline gap to move, which is the actual signal. This is the same reconciliation logic applied to the revenue side of the funnel in the conversion-to-revenue measurement gap.

What to tell the growth meeting

When the room asks which number is right, the answer that ends the debate is a one-page reconciliation map: for each headline metric, which tool is authoritative, what the expected gap to the others is, and when the number was last validated. That artifact converts a recurring argument into a settled reference. It also protects the team from the quieter failure — picking whichever tool's number flatters the current narrative — because the authoritative source for each metric is decided in advance, before anyone knows which answer they'd prefer.

The mindset shift is to stop treating agreement as the goal. Three tools will never show the same number, and a version of your dashboard where they did would mean they had all been coerced into measuring the same narrow thing, losing the distinct value each provides. The mature posture is to know what each tool is for, what gap to expect between them, and which one governs which decision — so a discrepancy becomes a fact you have already accounted for rather than a fire drill. Agreement is not trustworthy data; reconciled, well-understood disagreement is.