Meta Conversions API: what it is, pixel plus server events, and deduplication

Pixel and Conversions API: two roads to the same place

The Meta pixel is a piece of code on your website that runs in the visitor's browser and reports what they do: viewing a product, adding to cart, buying. The Conversions API does the same job from your side. Meta's developer documentation describes it as a connection between an advertiser's marketing data, from a server, website platform, mobile app or CRM, and Meta's systems.

Meta says server events may be used in measurement, reporting and optimisation in a similar way to other connection channels. The practical difference is where the event comes from: the browser can miss events, for example because of connection problems, while your server knows for certain that an order was paid.

Why Meta recommends both together

Meta's best-practice page is direct: use the Conversions API in addition to the Meta pixel, and share the same events using both tools. The reason given is that this helps capture events the pixel might miss. A redundant setup like this only works if Meta can recognise that a browser purchase and a server purchase are the same purchase, which is what deduplication is for.

Deduplication: the rule that prevents double counting

Meta decides whether two events are identical from their ID and name. The pixel's eventID must equal the Conversions API's event_id, and the pixel's event name must equal the API's event_name. Key details from Meta's documentation:

• Events are only deduplicated if they arrive within 48 hours of the first event received with that event_id.
• When the browser and server events do not differ meaningfully, Meta generally keeps the one received first.
• An alternative method compares event_name with fbp and/or external_id, but it mainly works when the browser event arrives before the server event. Meta recommends the event_id method.

A simple purchase example

1. The customer pays. Your site generates one unique ID for this order event, for example the order number.
2. The confirmation page fires the pixel's Purchase event with that ID as eventID, plus value and currency.
3. Your server, once the payment is confirmed, sends a Purchase event to the Conversions API with the same ID as event_id.
4. Meta receives both, sees the same name and ID, and counts one purchase. If the browser event was blocked, the server event still arrives.

Customer information: what to hash and what not to

To match a server event to a person on Facebook or Instagram, you can send customer information parameters. Meta recommends good-quality fields such as email, IP address, first and last name and phone number to improve Event Match Quality, scored from 0 to 10. Meta's rules on hashing are precise:

Setup mistakes that skew your numbers

• Different IDs on each side: the pixel sends one value as eventID and the server another as event_id. Meta then sees two purchases.
• Different event names: Purchase on the pixel, purchase_completed on the server. Deduplication requires the same name.
• Server events sent too late: events are only deduplicated within 48 hours of the first one with that event_id, so a nightly batch that runs late can create duplicates.
• Hashing what must stay in clear: IP address, user agent, fbc and fbp must never be hashed.
• Not normalising before hashing: an email with a capital letter or a trailing space produces a different hash.
• Server events only, no pixel: Meta recommends both, sending the same events through each.

Consent and privacy come first

Server-side does not mean consent-free. Whatever you send to Meta from the browser or from your server must respect what the visitor agreed to and the privacy rules that apply to your business. Send only the fields you need, hash what Meta asks you to hash, and keep the setup documented. For Google tags, the equivalent question is covered in our guide on Consent Mode v2.

How we set it up at Takat

On our Meta Ads work we install the Meta pixel together with the Conversions API, with server-side purchase events, so that campaigns are measured on real paid orders. The pixel, the dataset and the ad account stay in the client's name, and campaigns are created paused, going live only with the client's OK. See Meta Ads and Tracking.