Meta Pixel + CAPI deduplication explained

Send Meta the same purchase twice without protection and your reported ROAS inflates instantly. Yet sending events through both the browser Pixel and the Conversions API is exactly what Meta recommends. The reconciliation mechanism is the event_id.

How deduplication works

When Meta receives an event, it looks for other events with the same event_name and event_id received within the de-duplication window (48 hours). If a match arrives, the later copy is discarded. Crucially this happens per event pair — a missing event_id means every event is treated as unique.

The requirements

• —Both the Pixel event and the CAPI event carry identical event_id values.
• —event_name matches exactly (Purchase, not purchase_complete).
• —IDs are stable per transaction — regenerating them on retry creates duplicates.
• —fbp and fbc identifiers pass through to CAPI so Meta can join browser identity where available.

Verifying your implementation

In Events Manager, the Overview tab shows the browser/server coverage ratio per event, and sample events expose received event_ids. For a definitive test, place one test order and compare:

Pixel payload   : event_id = "T-8841", event_name = "Purchase"
CAPI payload    : event_id = "T-8841", event_name = "Purchase"
Events Manager  : 1 purchase · source = browser+server (deduplicated)

✓ correct

Pixel payload   : event_id absent
CAPI payload    : event_id = "evt_9f2..."
Events Manager  : 2 purchases

✕ double-counted

Common failure modes

• —Server container generates its own event ID instead of reusing the transaction ID.
• —Client-side event fires on 'begin checkout' while server fires on 'order created' under the same name.
• —Sandbox/test events leaking into production datasets during setup.