Skip to content
GetProfit
Log in

← All terms

Event deduplication

Event deduplication is how an ad platform merges two copies of one event, one sent from the browser and one from the server, so that it counts the event once.

How it works

A store that uses both tracking paths sends each purchase to Meta twice: through the pixel in the browser and through the Conversions API from its server. Meta calls this a redundant setup and requires a deduplication method, so it can tell separate events from copies of one event.

Meta recommends matching two keys. The pixel’s eventID must equal the server’s event_id, and the pixel’s event name must equal event_name. Copies merge only if they arrive within 48 hours of the first event with that ID. If they do not differ in any meaningful way, Meta generally keeps the one it received first.

A fallback method sends the same event name plus fbp, external_id or both in each copy. It generally works only when the browser event arrives first. Meta Conversions API for online stores covers the full setup for a store.

Example

Example store, not client data.

The tableware shop has 300 orders in a month. The pixel reports 270 of them, because some browsers block it. The server reports all 300.

Without deduplication, Meta counts 270 + 300 = 570 purchases. With a shared event ID, the 270 pairs merge and the 30 server-only events stay: 300 purchases, one per order.

Not to be confused with

  • Transaction ID — the order number sent with a purchase to Google Ads or GA4. It helps them avoid counting one purchase twice. Meta merges browser and server copies by event_id instead.

Right and wrong readings

  • Wrong: “Meta now reports more purchases than we have orders, so the server catches sales the pixel missed.” Right: a server can recover events the pixel lost, but it cannot create orders. A count above the number of orders means some purchases are counted twice. Copies that do not merge are one such cause.

Sources