If Meta says you got more purchases than your store recorded orders, the most common cause is that the same sale is being counted twice - once by the browser pixel and once by the Conversions API - because the two are not being matched to each other.
That is worth knowing before you act on the number, because every decision downstream of it is scaled by the error. A cost per purchase of $4 and a cost per purchase of $13 call for opposite decisions, and the difference between them can be a settings problem rather than a performance one.
The thirty-second check
Open Ads Manager, add the columns for Purchases, Checkouts initiated and Adds to cart, and look at the order of the three numbers.
In a working funnel, purchases are the smallest of the three. Someone adds to cart, some of those start checkout, some of those buy. The numbers descend.
If purchases are LARGER than checkouts initiated, something is wrong with the counting, not with the store. Nobody completes a purchase they never started.
We audited an ecommerce account this week that reported 118 purchases against 37 checkouts initiated over the same thirty days. Three purchases for every checkout is not a conversion rate. It is a measurement artifact.
Where the duplicate comes from
Most stores now send purchase events twice on purpose. The browser pixel fires from the customer's device, and the Conversions API sends the same event from the server. This is a good setup - the server catches sales the browser misses when an ad blocker or a privacy setting stops the pixel loading.
It only works if both events carry the same event_id. That shared id is how Meta recognises two reports of one sale and discards the duplicate. Without it, both are counted, and every order becomes two.
This is the most common failure in a server-side setup, and it is almost always introduced at install: the server integration gets added months after the pixel, by a different person or a plugin, and nothing tells you the ids don't match. The events arrive. The dashboard fills in. Nothing errors.
The second cause: a backfill you didn't know about
Open Events Manager, click your Purchase event, and look at Event overview. It shows browser events and server events as separate totals.
In the account above, the browser recorded 105 purchase events over four weeks and the server recorded 301 - and 104 of those server events arrived in a single six-hour window on one afternoon.
A store doing single-digit sales a day does not sell 104 items between 11am and 5pm. That is a bulk send: an app or integration replaying historical orders through the API when it was installed or reconfigured. Those old orders land as though they happened that afternoon, inside your reporting window, attributed to campaigns that were running at the time.
The tell is always the shape. Real sales are lumpy but continuous. A backfill is a spike with nothing before or after it.
What is not the problem
Two things get blamed for this and usually shouldn't be.
A server count higher than the browser count is not automatically wrong. Catching what the browser misses is the entire purpose of the Conversions API. A server total 10-30% above the browser is the setup working. A server total three times the browser is worth investigating.
Modeled conversions are not fabrication. Where Meta can't observe a conversion directly it estimates, and marks those numbers with a footnote. That is disclosed, it applies across the industry, and it is not what turns 37 checkouts into 118 purchases.
What it costs to leave alone
The reported cost per purchase in that account was $4.16. If the real order count is closer to the browser figure, the true cost is nearer $13.
Both numbers can support a decision, and they support different ones. At $4 you increase the budget. At $13 you look at the product margin first. An inflated conversion count doesn't just flatter a report - it also trains Meta's optimisation, which spends against the events it is told about.
How to fix it
Confirm the duplication first, in this order:
- Events Manager → your Purchase event → Event deduplication. It reports directly whether browser and server events are being matched. This answers the question without involving anyone else.
- Compare against the store. Pull the real order count from your ecommerce platform for the same dates. That is ground truth, and it settles what the platforms cannot.
- Check what changed. If there's a spike, look at what was installed or republished that day - a new app, a container publish, a plugin update.
The fix itself is usually a single change: make sure both the pixel and the server send the same event_id for the same order. Every major platform supports it, and most plugins expose it as a setting rather than code.
The honest limits
A check like this tells you the numbers disagree. It does not tell you which one is right - only your store's order count does that.
And an inverted funnel has other possible causes: attribution windows that credit purchases differently from earlier steps, or a purchase event that fires again when someone reloads the confirmation page. Duplication is the most common, not the only one.
The point isn't to distrust the platform. It's that a number you can't reconcile against your own records isn't a number you should be spending against. It is the same gap we found in our scan of 2,961 local business websites.