Meta Pixel + Conversions API deduplication, explained

Running the Meta Pixel and the Conversions API together is Meta's recommended setup: the browser copy fills gaps the server can't see, and the server copy survives what blocks the browser. The cost is that each purchase can arrive twice, so Meta has to recognise the pair.

The rule

Meta discards the later event when both of these match, for the same Pixel ID, within 48 hours of the first event with that id:

• Pixel eventID equals Conversions API event_id.
• Pixel event name equals Conversions API event_name (for example Purchase and Purchase).

// Browser
fbq('track', 'Purchase', { value: 2580, currency: 'BDT' }, { eventID: 'purchase_10023' });

// Server (Conversions API)
{ "event_name": "Purchase", "event_id": "purchase_10023", ... }

The mistakes that cause double counting

• A random event id in the browser and a different one on the server. Derive it from the order id on both sides, for example purchase_{order_id}.
• The server sends to a different Pixel (dataset) id than the browser uses. Deduplication only happens within one Pixel ID.
• The server copy arrives more than 48 hours after the first copy, for example from a delayed batch job.
• Relying on fbp or external_id matching alone. Meta says that method generally only works when the browser event arrives first.

Deduplicate before Meta, too

Retries, webhook redeliveries and a second server path can send the same order several times. Collapsing those copies on your side, keyed by the order id, means Meta receives one delivery per order in the first place, and your own reports count every order once. Trakero keys every purchase as purchase:order:{order_id} and always sends the same event_id, so both layers agree.