The Meta pixel reports conversions from the browser. That is exactly where signal loss is worst: ad blockers stop the script, Safari's ITP shortens the cookies it relies on, and iOS strips the cross-app context. The Conversions API (CAPI) is Meta's answer. It lets your server send the same events directly, so a conversion no longer depends on a tag firing in the browser. Here is how it works and how a server-side layer delivers it from your first-party data.
What the Conversions API is
CAPI is a server-to-server endpoint. Instead of the browser posting an event to Meta, your server sends it: the event name, when it happened, and the customer information you can attach to it. Meta introduced it because the browser stopped being a reliable messenger. A purchase captured on your own server cannot be blocked and does not depend on a cookie that ITP just capped.
The pixel and the server work together
CAPI is not a replacement for the Meta pixel. The recommended setup is both, deduplicated. The browser pixel and the server event carry the same event_id, and Meta uses it to recognize that the two are one conversion, not two. You keep the browser signals only the browser has, and you add a server copy that survives when the browser event is lost. Nothing is double-counted.
The identifiers that raise match quality
When your server sends an event, Meta matches it to a user with the customer parameters you include. The more, and the stronger, the higher your Event Match Quality:
| Signal | Role |
|---|---|
| Email (hashed) | Strongest single match key |
| Phone (hashed) | Strong, especially on mobile audiences |
| fbc / fbp | Click and browser ids that tie the event to the ad |
| external_id | Your own stable customer id |
| Name, city, zip (hashed) | Supporting signals that raise confidence |
Personal identifiers are hashed (SHA-256) before they leave, so Meta matches without receiving raw personal data.
Why server-side delivery keeps the conversion
A server-side layer sends CAPI from the event itself. A purchase captured from the order carries the customer's real email and phone, not whatever the browser happened to hold, and it arrives whether or not the shopper runs an ad blocker or closed the tab. If an event comes in thin, it can be enriched from the known first-party profile before dispatch, so an anonymous action becomes a strong match automatically.
What you need
- A Meta pixel and a Conversions API dataset (they share an id).
- A CAPI access token.
- A shared
event_idon both the browser and server event, for deduplication. - Consent resolved before send, and identifiers hashed on the way out.
Consent comes first
CAPI does not mean sending everything. Consent is resolved per visitor and per region at the edge before any event is built: opt-in where required, opt-out honored where it applies. Only then is the event hashed and sent. SetRoasFlow runs this model, delivering CAPI from your unified first-party data so the conversions Meta can no longer see in the browser still reach it.