Facebook Pixel and Conversions API: how event deduplication works

If you run both the Meta Pixel in the browser and the Conversions API (CAPI) on your server, every purchase is reported twice. That is deliberate: the pixel sees what the browser shows, the server sees what actually happened. But unless Meta can tell the two reports are the same sale, you pay for the mistake in inflated conversion counts and wrong ROAS. The fix is deduplication, and it comes down to two fields.

Why you send each event twice

Browsers lose events. Ad blockers, Safari and Firefox tracking prevention, and customers who close the tab before the thank-you page loads all mean the pixel misses some conversions. The server side does not have those problems, because your backend knows the order was paid. So the sensible setup is both: the pixel for speed and rich browser signals, CAPI as the reliable record. Meta then needs to merge the pairs.

How Meta decides two events are one

Meta treats a browser event and a server event as the same when they share:

1. the same event name (for example Purchase), and
2. the same event ID.

When it receives a matching pair, it keeps one and discards the other. Meta's documentation describes a 48-hour window for this matching, so the server copy can arrive a little late and still be merged.

The event ID is the part people get wrong. It must be a value that both sides already know, not two values that happen to look alike.

Where the event ID comes from

Pick one identifier per action and use it in both places:

• For a purchase, the order number is a natural choice.
• For events with no natural key (page views, add to cart), generate a random ID in the browser at the moment the event happens, and pass it to your server along with the request.

In the browser, the ID goes in the pixel call as the fourth argument:

fbq('track', 'Purchase', { value: 49.0, currency: 'USD' }, { eventID: 'order_10482' });

On the server, the same value goes in the event_id field of the event you send to the Conversions API, along with the same event_name.

PixelFox does this for you: the tag mints one ID per event, fires the browser pixels with it, and the backend sends that same value to Meta and TikTok, so the pair collapses without any per-store code.

The mistakes that break deduplication

• Two different IDs. The browser generates one random ID and the server generates another. Nothing matches, and every conversion counts twice.
• Different event names. Purchase on one side and purchase on the other are not the same event. Match the standard names exactly.
• Reusing an ID for different events. If an add-to-cart and a purchase share one ID, you can lose one of them. Make the ID specific to the action.
• Sending the server copy hours later. The match window is finite. If a queue delays the server event past it, you get duplicates.
• Expecting dedup for server-only events. If an event only ever fires from the server, such as a refund-adjusted purchase or an offline order, there is no browser copy to merge, and that is correct.

How to check it is working

Open your pixel in Meta Events Manager and look at the event details for Purchase. Meta shows which events arrived from the browser and from the server, and whether they were deduplicated. If browser and server counts are both high and nearly identical, with nothing deduplicated, your IDs are not matching. Fix the ID first, then compare your purchase totals against your real order count; the two should now agree.

The short version

Send the event from both sides, give both the same event_name and the same event_id, and make sure the server copy arrives promptly. Then Meta counts each sale once and you keep the reach of the browser and the reliability of the server.