Why your ads report the wrong number of conversions

Your ad account says fourteen conversions. Your own records show six sales. Neither number is a lie, and the gap is not usually a bug — it is four different measurement decisions stacking up. Knowing which ones apply to you is the difference between optimising against reality and optimising against an artefact.

Is the platform counting the right event?

The first thing to check is the least interesting and the most often wrong: what event is actually being counted. A pixel firing on every page load, or on an add-to-cart the platform has been told is a purchase, will report enthusiastic numbers that have nothing to do with money.

Open the event itself rather than the campaign report and confirm which action it corresponds to and where it fires. This resolves a surprising share of large discrepancies, and it is a five-minute check that people skip because it feels too basic to be the answer.

How do attribution windows inflate conversions?

Ad platforms credit a conversion to an ad if the person interacted within a window — typically several days after a click, and often a shorter one after merely seeing the ad without clicking.

That second part causes most of the arguments. Someone who saw your ad, did not click, and bought two days later after searching your name is counted by the platform as a conversion. You would probably call that brand awareness or a search visit. Both positions are defensible; the important thing is knowing which one you are reading.

It also means the same sale can appear in two platforms at once. Each is reporting what it saw, and neither can see the other. Adding the platforms together always overstates, sometimes badly.

Why do last week's numbers keep changing?

This one quietly ruins week-by-week comparisons. Platforms attribute a conversion back to the date of the ad interaction, not the date the money arrived. A sale on Friday from a Monday click appears in Monday's row.

So a week that looks poor on Wednesday can improve for days afterwards as later sales get backdated into it. If you judge campaigns before the window has closed, you will systematically underrate the most recent days and make decisions on numbers still in motion.

Give any comparison at least as long as the attribution window before treating it as final. Nothing has gone wrong when yesterday's figure changes overnight — that is the design.

Why does browser tracking lose events?

Pixels are JavaScript running in a browser, and a share of browsers will not run them. Content blockers, privacy settings, tracking prevention that expires identifiers, and people who decline consent all remove events before they are sent.

This produces under-reporting in the other direction, and it is not evenly spread — it varies by device, browser and audience. So the gap between the platform and your books is a mixture of over-counting from attribution and under-counting from blocked events, which is why the two numbers rarely differ by a tidy, explainable margin.

Sending conversions from your server as well closes part of this, because a server-side event does not depend on the visitor's browser cooperating. It needs an event identifier shared with the browser event so the platform can recognise the two as one and not count both.

How does consent change the numbers?

If your site asks for consent before loading tracking, then every visitor who declines is invisible to the pixel. Where acceptance is low, the platform is reporting on a minority of your traffic and reporting it accurately — it simply never saw the rest.

This surprises people who expect a small correction and find the effect large. It is worth measuring your own acceptance rate rather than assuming, because it sets a ceiling on what browser-side tracking can ever tell you.

The answer is not to stop asking. It is to know the rate, so you interpret the numbers in that light — and to remember that server-side reporting has its own obligations rather than being a way around a refusal.

Which number should you actually run on?

Use your own records — orders, invoices, money received — as the truth for how the business is doing. That number is unambiguous and it is the one that pays wages.

Use the platform's numbers for relative comparisons inside that platform: which ad, which audience, which creative. The absolute value may be inflated or deflated, but the bias applies roughly evenly across campaigns measured the same way, so the ranking is still informative even when the totals are not.

What you should not do is add platforms together, or judge a channel on its own self-reported figure alone. The useful cross-check is simpler than any attribution model: when you increased spend, did total orders rise?

What should you check, in order?

Confirm the event you are optimising for is the one you mean, and that it fires once. Check the attribution windows in the account and write them down. Compare like with like on dates, allowing for the backdating above.

Send conversions server-side alongside the browser event, with a shared event identifier so they deduplicate. Then check the platform's own diagnostics for whether it is matching them, rather than assuming setup means working.

Finally, keep one number outside all of it: total orders per week from your own system. Every optimisation should eventually show up there, and anything that improves the platform's figure without moving that one deserves suspicion.

What to do next

Expect the platform and your books to disagree, because attribution windows inflate and blocked events deflate, and the two do not cancel neatly. Trust your own order records for how the business is doing, and the platform only for comparing ads against each other within the same account. Add server-side conversions with a shared event identifier to recover what browsers drop, and treat total weekly orders as the number that has to move.

Common questions