What Is event_id? (Meta Pixel + CAPI Deduplication)

In practice

When a store runs both the Meta Pixel in the browser and the Conversions API (CAPI) on the server for the same event — most commonly Purchase — both events need to carry the exact same event_id value. The two events can differ in timing, payload detail, and even which parameters are present, but as long as event_id matches, Meta’s deduplication logic treats them as one event when deciding what to count in Ads Manager and Events Manager. This is why event_id is central to any Pixel+CAPI setup: it lets a merchant send richer server-side data without double-counting conversions the Pixel already reported.

Common confusion

event_id is not the same as event_name (e.g., “Purchase”) or the order ID itself, though it is frequently built from one. It also isn’t something that happens automatically — both the browser and server events must generate or receive the identical string, which typically means an order ID (or a value derived from it) is pushed into the dataLayer at the moment of purchase and read by both the Pixel tag and the server-side event payload. If the two systems generate event_id independently — for example, the Pixel uses a random session token while CAPI uses the order ID — deduplication fails silently and conversions get overcounted.

How to check

In Meta Events Manager, open the Overview tab for the relevant pixel or dataset and use the Test Events tool, which flags events where a browser and server source have matched on event_id. The Diagnostics tab surfaces warnings when server and browser events for the same action arrive without a shared event_id, which is the fastest way to catch a broken dedup setup before it skews ad reporting.

Related entries

event_id is one of the parameters that feeds Event Match Quality, and it’s a core piece of any server container setup running Conversions API. For implementation help, see Meta Conversions API services.