Meta pixel and Conversions API deduplication: why Meta counts two purchases

Start with the parts. The tracking pixel is code in the visitor's browser that sends actions to an ad platform. The Conversions API (CAPI) connects your marketing data to Meta's systems¹. When you use both, the same purchase can reach Meta twice: once from the browser, once from your server. Meta recommends this "redundant setup" and says it then needs a deduplication method². If you never send the same event from both sides, you do not need one². Server-side tracking is there partly to catch what the browser misses.

Event deduplication is Meta's way of counting that purchase once. Meta's recommended method matches on event_id and event_name². If both fields match across the pixel event and the server event, Meta treats them as one. Events are only deduplicated if they arrive no later than 48 hours after the first event with that event_id². Meta also documents a second method that compares event_name with the fbp and/or external_id parameters². Its limits are narrower: it generally works only when the browser event arrives before the server event². We would not plan around it.

Two parts of that rule matter in practice:

• event_id must be the same value on both sides. It must be generated once per event, and passed to both.
• event_name must match on both sides. In the pixel, that is the event in the track call.

Read the rule backwards. Anything that breaks the match gives you two events.

• No event_id on one side. The pixel sends one, the server does not, or the reverse.
• Different IDs. The browser and the server each make up their own value. They look similar, but they do not match.
• Different names. One side says Purchase, the other says something else.
• Two setups at once. A shop plugin and a manual integration both send server events, each with its own ID.
• Late server events. A server event that arrives outside the matching window may not merge.

Merchants report these problems in vendor and platform forums. One thread in a server-side tagging vendor's community describes duplicate server events³. A Shopify community thread describes duplicate Pixel and CAPI events⁴. Both are single reports from users. They show the problem is real. They do not say how often it happens.

Check against the shop first. It is the least ambiguous source.

1. Pick a clean period. One without a sale, a tracking change or a platform outage.
2. Count orders in the shop. Use paid, non-cancelled orders.
3. Count purchases Meta reports for the same period. Include all sources in the count.
4. Compare. Meta can report fewer than the shop, because not every order is attributed to ads. If Meta reports more purchases than the shop has orders, you have a double-counting suspect.
5. Open the Purchase event in Events Manager. Look at which sources deliver it, browser, server or both. Check that the same event_id arrives from each.
6. Test one order. Place a test order and trace the event_id from the page to the server payload.

Also look at Event Match Quality (EMQ). It is a different thing: Meta's per-event score of how well customer details sent with server events match Meta accounts. Good EMQ does not mean good deduplication. Check both.

Example (illustrative): The shop recorded 100 paid orders in a week. Meta reports 160 purchases. Attribution and modelling can blur the comparison, but more reported purchases than real orders is a red flag. Duplicates are the first thing to rule out.

Two things, and both cost money.

Reporting. If one order becomes two purchases, reported purchases rise and so does ROAS. The revenue on the dashboard is higher than the revenue in the bank. Every comparison you make from that dashboard is skewed, including comparisons between campaigns and channels.

Bidding. Meta's bidding learns from the conversions it sees. If the signal contains the same purchase twice, it learns from a distorted picture. We would not expect that to be good for decisions. Fix the signal first, then change budgets.

Duplicates are not the only reason Meta and the shop disagree, but they are the one to rule out first.

TikTok uses a similar idea. TikTok's help page says you must share an event_id through both its pixel and its Events API for deduplication to happen⁵. It also sets its own time windows for matching, which differ depending on whether events come from one side or both⁵. Do not copy Meta's window across to TikTok. Read TikTok's current rules before you plan the setup.

The checks are the same in spirit: one ID per event, the same on both sides, and a comparison with shop orders. For the wider picture of server-side set-ups, see conversion APIs for ecommerce. For the browser side, see Meta Pixel and standard events.

For ZFD: Our view is that deduplication gets checked before any Meta result is read, because if the signal is wrong, the report is wrong. Our work in this area sits under analytics and tracking.