Tool Discrepancies
Date: 2026-08-16
Two tools on the same site will never agree, and chasing zero is wasted effort. The job is knowing which differences are expected, quantifying the residual, and noticing when it moves.
What it is
A tool discrepancy is two systems reporting different figures for what appears to be the same thing. It is the normal condition, not a fault.
What’s expected, by metric
| Metric | Divergence | Why |
|---|---|---|
| Orders / revenue | Analytics below the order system | Consent, blocking, delivery loss, bots |
| Sessions | Large, between any two tools | Different timeouts and boundary rules — Sessionisation |
| Users | Very large | Different identity models entirely — User Counting |
| Conversions, ad platform vs yours | Platform substantially above | Different models, windows, view-through, modelling — Walled Garden Reporting |
Deliberately no numbers here. Any range I could give would be someone else’s business, and the only figure worth having is your own — measured, then tracked. The direction of each divergence is predictable; the size is not.
Users is the one to never reconcile. It’s an inference, computed differently by every tool, and the gap carries no information.
The causes, in the order to check them
This is a diagnostic sequence, cheapest first:
1. Timezone and date boundary. A large share of apparent discrepancies. Compare at monthly grain — if the gap shrinks, this was it — Timezones and Date Boundaries
2. Definition. Is “conversion” the same event, with the same filters, on the same denominator? Two tools with the same metric name are usually measuring different things — Metric Design
3. Filtering. Bots, internal traffic and test orders removed in one system and not the other — Bot and Internal Traffic
4. Attribution. For anything channel-attributed, model and window differences dominate everything else — Attribution Models, Attribution Windows
5. Collection loss. Consent denial, blocking, events lost at unload. This is the genuine residual, and it’s what remains after the four above — Ad Blockers and Tracking Loss, Event Batching and Delivery
6. Sampling. One figure estimated, the other complete — Data Sampling
Most investigations that stall did so by starting at 4 or 5.
The rule that saves time
Reconcile to the order system, not between analytics tools.
The order system is the only source of truth — it’s what the business is paid on and what finance uses. Two analytics tools disagreeing with each other tells you nothing useful; either or both disagreeing with orders tells you your measurement gap.
So the standing metric worth having is one number: analytics orders ÷ actual orders, tracked over time.
month analytics actual ratio
Jun 870 1,000 0.87
Jul 864 995 0.87
Aug 742 1,010 0.73 ← investigate
A stable ratio is a correction factor you can apply and explain. A moving ratio is an incident. That distinction is the entire practical value of this note.
Explaining it to stakeholders
The question arrives as “why don’t these match”, with an implication that someone got it wrong. A ready answer:
“They measure different things. The ad platform counts anyone who saw or clicked their ad within their window and then bought — including conversions they’ve estimated. Our analytics counts orders where tracking survived consent and ad blockers. The order system counts orders. The first two will never equal the third, and the ratio between them has been stable at 0.87 since June — which is what we watch.”
The value of the stable-ratio framing is that it converts an unanswerable question into a monitored one.
What not to do
- Don’t chase zero. It isn’t achievable and pursuing it consumes weeks
- Don’t average two tools. Two wrong numbers don’t make a right one
- Don’t switch tools to fix a discrepancy. The new one will disagree with the old one differently, and you’ll have lost your history — Metric Drift
- Don’t report platform-reported conversions and analytics conversions in one table without labelling what each measures