Meta CAPI deduplication: event_id, _fbp and _fbc explained

Most teams move to the Meta Conversions API (CAPI) gradually. The Pixel stays on the page while server-side events start flowing, and the two run side by side until the numbers line up. That is the right way to do it, with one condition: Meta has to be able to tell when a browser event and a server event describe the same purchase. Get that wrong and every conversion is counted twice, Ads Manager reports a sudden jump in performance, and the campaign optimises on numbers that are not real.

Three identifiers do most of the work: event_id, _fbp and _fbc.

event_id: the deduplication key

Meta deduplicates a browser event and a server event when they share the same event name and the same event_id and arrive within Meta’s deduplication window. In the Pixel the ID is passed as eventID; in CAPI it is the event_id field. If the two values differ by a single character, Meta treats them as two conversions.

The common failure is generating the ID twice: the page makes one random value for the Pixel and the server makes another for CAPI. The fix is to create the ID once, when the event happens, and send that same value down both paths. Datafly Signal generates a deterministic event_id for every event at collection, so during migration the Pixel and the Conversions API carry the same ID and Meta keeps one.

_fbp: the browser identifier

_fbp is Meta’s first-party browser cookie, in the format fb.1.{timestamp}.{random}. The Pixel normally sets it with JavaScript on the first visit. It is not personal data on its own, but it is one of the strongest signals Meta has for linking events from the same browser.

Because the Pixel sets it in JavaScript, Safari deletes it after 7 days without a return visit, and a visitor who comes back on day 8 looks like a stranger. Datafly Signal generates an _fbp value in the same format on the server and sets it with a Set-Cookie header from your own subdomain, so it lasts up to 400 days. To Meta it is indistinguishable from a Pixel-set value.

_fbc: the click identifier

When someone arrives from a Meta ad, the landing URL carries fbclid. Meta expects that click to come back on conversions as _fbc, formatted fb.1.{timestamp}.{fbclid}. It is the signal that ties a purchase to the ad that drove it.

The click ID only appears on the landing page, so it has to be captured at that moment. Datafly.js reads fbclid on landing, the gateway formats _fbc and stores it in the same long-lived server-set cookie as _fbp, and every later conversion carries it, even weeks after the click.

What a well-formed migration looks like

1. Generate one event ID per event and send it to both the Pixel and CAPI. 2. Keep `_fbp` and `_fbc` stable by setting them from your server, so the browser and server paths share the same values. 3. Send hashed customer data (email, phone, name) with CAPI events. It is what lifts Event Match Quality; see what moves EMQ from 5 to 9. 4. Compare in Events Manager. The deduplication view shows how many events arrived from each source and how many were merged. A healthy setup shows overlap, not two parallel streams. 5. Remove the Pixel event by event once the server path matches, rather than all at once.

Mistakes we see most often

• Different event names. Purchase from the Pixel and purchase from the server are different events. Meta’s standard event names are case-sensitive.
• IDs generated after a redirect. If the thank-you page reloads, a new random ID is created and the server never sees it. Create the ID before the redirect.
• `_fbc` rebuilt from a stale click. Only build _fbc from an fbclid that is actually present on the landing URL, with the time it was captured.
• Missing IP address and user agent. Server events need the visitor’s IP and user agent, not your server’s. Datafly Signal forwards the visitor’s values on every event.

Why it matters beyond deduplication

Clean deduplication is what makes the migration measurable: you can see exactly what the server path adds over the Pixel alone, usually the conversions that ad blockers and Safari were hiding. Once the Pixel is gone, the same identifiers keep CAPI events matched to the right people for as long as the cookies last.

See how Meta Conversions API server-side tracking works in Datafly Signal, or request a demo.