Meta Conversions API: why the pixel alone is not enough and what a correct setup looks like

The situation

Your store platform says 212 orders from Meta this month. Ads Manager says 131. The gap is not just "attribution" in the abstract — a share of those orders never reached Meta at all. The browser pixel was blocked, consent was refused, or the user was on an iPhone with limited tracking. The delivery system optimised with a large chunk of the data missing and paid more for every order it did see.

Pixel vs Conversions API

The Meta pixel is a script in the browser. When someone views a product or completes an order, the script sends the event to Meta straight from the user's browser. Simple, but at the mercy of the browser.

Conversions API (CAPI) sends the same event from your server (or an intermediate server) to Meta. It does not depend on the browser, ad blockers or iOS settings. It has access to data only you know — the customer's email, phone, customer ID — and can send it hashed, so Meta can match the event to a real account.

It is not "one or the other". The setup Meta recommends is redundant: pixel and CAPI send the same events, and Meta deduplicates them.

Why the browser alone loses events

• Consent — in the EU, without marketing consent the pixel does not load. Careful: CAPI is not a shortcut around consent. The server event is also sent only with the user's consent; the advantage is that when consent exists, the event is no longer lost for technical reasons.
• Ad blockers and protective browsers — they block the script or shorten cookie lifetimes.
• iOS — since App Tracking Transparency, the Facebook and Instagram apps receive far fewer signals about what the user does after the click.
• Pages that do not fully load — the user closes the tab before the script fires the event. On the server, the order exists regardless.

Event Match Quality

In Events Manager, every event has an Event Match Quality (EMQ) score from 1 to 10. It measures how much identifying data you send and how well it matches Meta accounts. What raises the score:

• email and phone (SHA-256 hashed, in normalised format);
• the browser cookies _fbp and _fbc (the ad click ID);
• client IP address and user agent;
• an external_id — your own customer ID, consistent between browser and server;
• name, city, postcode, country, where you legitimately hold them.

A low score on Purchase is the most expensive: those are exactly the conversions the system needs to see in order to find more buyers.

Deduplication with event_id

When the same event arrives from both the browser and the server, Meta counts it once only if both carry the same event_name and the same event_id. If the IDs differ or are missing, you count every order twice: ROAS in Ads Manager doubles on paper, and optimisation learns from false data.

In practice: generate the ID once (for example the order number or a unique identifier created on page load), put it in the pixel event and send it with the same event name from the server. In Events Manager, per event, you can see how many were deduplicated.

What a correct setup looks like

1. Pixel in the browser via GTM (or natively on your platform), only after marketing consent, with the standard events: ViewContent, AddToCart, InitiateCheckout, Purchase, Lead.
2. CAPI from the server — through the platform integration (Shopify, WooCommerce and others have official connectors), through server-side GTM with the Meta template, or directly from your code.
3. Same events, same IDs on both channels.
4. Matching data sent from the server: email, phone, external_id, fbp, fbc, IP, user agent.
5. Consent respected on both paths — the consent signal reaches the server too, not only the browser.
6. Verification — see below.

How to verify in Events Manager

1. Test Events — put the test code in the server request and walk the real flow on the site. You should see every event arrive once from the browser and once from the server, in near real time.
2. The per-event overview — the browser and server columns and the number of deduplicated events. A Purchase with server events but zero deduplicated means the IDs do not match.
3. Event Match Quality — open the event details and see which parameters are missing; Meta tells you what you could add.
4. Diagnostics — warnings about invalid parameters, wrong hashing or delayed events.
5. Compare with the source of truth — orders in your platform versus Purchases in Events Manager over the same period. They will not be equal (attribution, refused consent), but the gap must be explainable and stable.