Why Meta counts your purchases twice
Your store recorded 30 orders and Meta reports 47 conversions. Nothing was invented: the same sale arrived twice by two different routes and nothing told Meta they were the same. This page shows how to confirm it and what actually joins them.
Meta counts a purchase twice when the same sale reaches it by two routes, the browser pixel and the Conversions API, with nothing marking them as one event. Deduplication relies on an event identifier shared by both reports. If the two differ, even only in capitalisation, Meta sees two separate purchases.
How do you confirm you are counting twice?
Compare a single day. Take your store's order count for one day in one time zone, and Meta's conversion count for the same day. If Meta's number is close to double, you are counting twice. If it is higher but not close to double, part of your traffic is being joined correctly and part is not, which is the more common state.
Events Manager tells you the rest. A dataset receiving both routes shows its integration as Multiple, and it raises a diagnostic for events it could not merge. No diagnostic and a doubled count together mean the two reports never looked like the same event to begin with.
Why send it twice at all?
Because each route catches what the other loses, and that is worth more than the tidiness of one. The browser report carries what only a browser knows and disappears when a blocker refuses it. The server report always leaves and carries what only the order knows. Sending both and joining them is strictly better than choosing.
This is also why the answer to double counting is never to send less. It is to make the two reports of one sale carry the same name.
What breaks the join?
The shared identifier, almost always. It has to be the same string on both sides and it is case sensitive, so one route sending an uppercase form joins nothing. It also has to be derived from the sale rather than from the moment: an identifier built from a timestamp gives two different values to two reports of one order, and merges two genuinely separate events that happened in the same second.
For a purchase the order number is the natural choice, because it is the one value both halves can see and neither has to guess.
Does switching the pixel off fix it?
It ends the double count and costs you the thing you were trying to improve. The browser half is part of what Meta grades: on our own store the quality score read 8.0 out of 10 with the server half alone and 9.3 once both halves reported. Turning one off buys a correct total at the price of a worse one.
What actually joins the two reports
- Give both reports of one sale the same event identifier, derived from the order rather than from the time it happened.
- Keep it a string and keep its capitalisation identical on both sides. A lowercase and an uppercase form of the same value are two events.
- Check the result on Meta's side rather than on yours. The integration should read Multiple and there should be no unmerged-event diagnostic.
- Verify on a handful of real orders before trusting it on a month. Three orders that produce three conversions and not six is the whole test.
Sources
- Meta documents deduplication between pixel and server events as resting on a shared event ID, and states that it is case sensitive.Meta for Developers
- On our own test store, three test orders reported from both the browser and the server produced three Purchase events and not six, with the integration shown as Multiple and no unmerged-event diagnostic, checked on 21 August 2026.wesaw, own test store
The terms on this page
What wesaw does about it
Last reviewed: