When Two Systems Disagree, and Which One Is Right

Analytics reports 400 conversions. The ad platform claims 520. Finance counted 340 orders. Payroll systems can also disagree because rules differ; this explanation covers the Chinese overtime calculation method.

The instinct is to find the bug. Usually there is no bug — all three are correct measurements of different things, and the useful work is establishing what each one counts.

Why they differ, in order of size

Different attribution rules. The platform counts a conversion if its ad was seen or clicked within its window. Analytics counts it against whichever source it credits under its own model. These are different questions and they produce different answers by design.

Each platform claims the same conversion. If someone saw a social ad and clicked a search ad, both platforms count it. This is why platform-reported conversions sum to more than reality, frequently by a wide margin, and it is not a fault — each platform is answering "was I involved?"

Different windows. Seven days post-click on one, thirty on another, view-through included or not.

Modelled versus observed. Platforms fill gaps with modelled conversions. Analytics generally does not, or does so differently. See what actually broke when third-party cookies went away.

Different definitions of the event. Order placed, payment authorised, payment settled, order shipped, order not refunded. Finance usually counts the last; tracking counts the first.

Timezone and reporting-period differences. A day is not the same day in two systems.

Currency, tax and shipping included or excluded from revenue.

Refunds and cancellations reflected in one system and never in the other.

Consent and blocking, which affects tracking and not the order table.

Which one to trust for what

There is no single right system. There is a right system per question.

"How many orders did we get, and what were they worth?" — the transactional system. Finance, the order database, the payment provider. This is ground truth: it is the record of money moving, and it does not depend on anyone's consent or on a tag firing.

"Where did traffic come from and how did it behave on site?" — analytics. It sees the journey; it does not see the money accurately.

"Is this campaign performing better than last week?" — the platform, for relative movement within itself. Its absolute numbers are inflated; its week-on-week comparison of itself is consistent.

"What did this channel cause?" — none of them. That needs an experiment. See incrementality.

The rule that resolves most arguments: use transactional data for absolute numbers, analytics for behaviour, platforms for relative movement within a platform, and experiments for causation.

Reconciling properly

The exercise worth doing once and then automating.

1. Pick one month and one channel.

2. Define the event precisely. Order placed? Payment settled? Net of refunds? Write it down.

3. Pull the number from each system on that definition, adjusted to the same timezone.

4. List the differences, quantified. Refunds: 22. Test orders: 4. Orders outside the attribution window: 31. Untracked due to consent: estimated 60.

5. Establish the ratio. Analytics sees roughly 78% of orders. Platform reports roughly 130% of orders.

6. Track those ratios monthly. Their movement is the alarm. A stable ratio is workable; a drifting one means something broke, and the month it started drifting usually identifies what.

The output is not agreement. It is a documented, stable relationship between systems that everyone understands. That is achievable; agreement is not.

The conversation with stakeholders

The question arrives as "why don't these match" and it is usually asked with some suspicion.

Answer with the hierarchy, not with a defence of a tool.

"They measure different things. Finance counted 340 orders — that is what happened, and it is the number for the board. The platform says 520 because it counts any conversion where its ad appeared in the previous month, and other platforms count several of the same ones. Analytics says 400 because it sees about four fifths of orders after consent and blocking, and it credits them to a single source.

For 'how did we do', use 340. For 'where did they come from', use analytics. For 'did the campaign cause it', neither — that needs a test."

Then agree which system is authoritative for which report, in writing. Most recurring disputes are two people using different systems for the same question without knowing it.

Publish the reconciliation ratio in the regular report. It pre-empts the question and it turns an apparent problem into a stated known.

What to do about actual bugs

Sometimes the gap is a fault. Distinguish it by whether the gap is stable.

A stable gap is structural. Different definitions, expected.

A sudden change is a bug. Something broke on the date it changed.

A gap that differs sharply by device, browser or payment method points at a tracking failure in that flow. See data quality.

A gap that grows steadily is usually consent or blocking rising, not a break.

The definitions problem underneath

Most of this is a symptom of metric definitions living in people's heads rather than in a document.

If "conversion" means four different things in four systems and nobody wrote that down, the systems will disagree forever and each argument will start from scratch. See documenting metric definitions.

The summary

They disagree because they measure different things, and the largest cause is that every platform claims any conversion it touched.

Transactional data for absolute numbers. Analytics for behaviour. Platforms for relative movement within themselves. Experiments for causation.

Reconcile once, then track the ratios monthly — the ratio moving is the signal, not the ratio existing.

And publish the ratio in the report, because a stated known is much easier to live with than a recurring surprise. A platform-specific discrepancy guide is available in Google guidance on Ads and Analytics discrepancies.