What the Conversions API actually fixes, and what it does not

Everyone tells me to install the Conversions API. What does it actually fix, and what will still be broken afterwards?

A Conversions API sends your purchase events to an ad platform from your server instead of from the shopper's browser. That is the whole mechanism, and almost everything written about it either oversells what follows from it or is vague enough to imply more. It is worth being precise, because the gap between what it fixes and what people expect it to fix is where the disappointment lives.

What it actually fixes

The browser is an unreliable narrator. An extension can block the request outright. Safari's tracking protection shortens or discards the cookies a platform uses to recognise someone. A checkout that renders on a payment provider's domain runs no code of yours at all. A shopper closing the tab on the confirmation screen kills the event before it fires.

Every one of those loses a sale that definitely happened. Your server knows about all of them, because your server is where the order exists. Sending the event from there recovers exactly that population, and it is why the recovered share varies so much between stores: it tracks how privacy-conscious your audience is and how your checkout is built, not how good your implementation is.

The second thing it fixes is match quality. A browser event carries what the browser has. A server event can carry what the order has: a hashed email, a hashed phone number, a name, a postal address. More identifiers means the platform recognises more of the buyers you send it.

Three things decide whether it works, and the order matters

**A shared event ID.** Once you send purchases from the browser and the server, the platform receives two events for one sale. It collapses them into one only if both carry the same event ID, and Meta only deduplicates inside its documented window after the first event with that ID arrives. If the two sides generate their IDs independently, or one omits it, you have not built redundancy. You have built double counting, and it looks like growth.

**Identifiers hashed the way the platform expects, exactly.** Meta matches plain SHA-256 of a normalised value. It is easy to hash with a keyed function instead, because a keyed hash is the correct choice almost everywhere else in a codebase that handles personal data. Meta will accept it. It will count it as received. It will match it to nobody, forever, and nothing in the response says so. This failure is silent by construction, which is why match quality has to be read rather than assumed.

**An idempotence latch on your side.** Order webhooks retry. A platform re-notifies on every state change. Without a record saying this order has already been sent to this platform, one sale ships several times, and on Google there is no event-ID safety net to catch it.

What it does not fix

It does not make the platform's claim verifiable. Better data in means a better-informed claim out, and the claim is still the platform's own account of its own contribution, measured on its own window, with no way for you to audit an individual sale inside it.

It does not change the attribution model. A 7-day click window is a 7-day click window whether the event arrived from a browser or a server.

It does not reconcile anything with your store. The store's order table and the platform's conversion count remain two different numbers on two different bases, and the Conversions API moves one of them closer to the other without making either checkable against the other.

And it does not stop you paying to re-acquire people who are already your customers. This one is worth stating plainly because it is assumed so often. Event data teaches the optimiser what a good outcome looks like. It never removes anyone from the auction. Excluding existing customers requires an audience wired as an exclusion, which is a separate mechanism and a decision that depends on the campaign's purpose.

How to check it without taking anyone's word

Platforms expose diagnostics for this and they are more useful than the vendor dashboard on top of them. Read the match quality per event, not the account average, because a healthy PageView average hides a poor Purchase score. Read the deduplication feedback, which tells you what fraction of events were actually collapsed and on which key: that is the platform confirming your event ID is doing its job, rather than you assuming it.

Then do the arithmetic that no diagnostic will do for you. Compare the number of purchase events the platform received in a window against the number of orders your store settled in the same window. They will not match, and the direction of the mismatch tells you which problem you have.

The warning nobody puts in the sales deck

When a Conversions API goes live, reported conversions go up. That is the intended effect and it is a good thing: sales that were always happening are now visible to the platform that influenced them.

It is also not more revenue, and the reports do not distinguish those two. If reported ROAS improves on the day of the switch, nothing about the business changed. What changed is how much of the same revenue the platform can see and claim. A merchant who reads that as growth will raise spend against a number that moved for a measurement reason, and the correction arrives later, in the bank account rather than in the dashboard.

The protection against this is the same one that answers most of the questions on this blog. Keep your store's settled orders as the anchor, treat every platform number as a claim about that list, and check the claims against it. A platform can legitimately resolve a buyer you never saw, but no platform can resolve an order that does not exist.