If you send the same event from the Meta Pixel and from the Conversions API, Meta counts it once only when both copies carry the same event name and the same event ID. Without a shared event_id, each copy looks like a separate lead. That inflates your numbers and teaches Meta’s ad system the wrong thing.
Ads only improve when the results you feed them are true. That is why our ads management service sets up tracking before budget, and checks the browser and server routes agree.
What are the Pixel and the Conversions API?
The Meta Pixel is a script in the visitor’s browser. The Conversions API (CAPI) sends the same kind of event from your server. Together they tell Meta which visitors turned into leads or sales, so your ads learn from real results.
Why use both? Browsers and privacy settings can block the Pixel. A server route catches events the browser misses. Meta’s own guidance calls this a redundant setup, and says that setup needs a deduplication method.
How does Meta tell the two copies apart?
Meta’s deduplication guide says its recommended method is to match two values:
- the Pixel’s event name with the server’s
event_name, and - the Pixel’s event ID with the server’s
event_id.
If both match, Meta keeps one and discards the other. Meta says it generally prefers the event it received first, provided the two do not meaningfully differ. Events are only deduplicated if they arrive within 48 hours of the first one.
How do you set it up?
- Create one ID per action. When a visitor sends your form, generate a unique ID such as a random string. Do it once, in the page, at the moment of the action.
- Send it with the browser event. Meta documents the Pixel side as the fourth argument:
fbq('track', 'Lead', {}, {eventID: 'EVENT_ID'}). - Pass the same ID to your server. Include it in the form data, and send it as
event_idin the Conversions API call, with the sameevent_name. - Keep names identical. “Lead” and “lead” are not the same name to a matching rule. Pick one spelling and use it in both places.
Meta also lets you match on fbp and external_id instead, but says this generally works only when the browser event comes first and the server event second. The event ID route is the one to use.
What goes wrong?
Meta lists the failure modes itself:
- No event_id. Events sent without one cannot be deduplicated, so you pay for the lead twice in your reports.
- A wrong ID. Meta warns that inaccurate IDs can cause a real conversion to be wrongly removed.
- Two events, one ID. If you reuse an ID across different actions with the same name, one of them may vanish.
- Slow server events. A server event that arrives after the 48 hour window will not be matched.
How do you check the numbers?
Open Events Manager and compare the browser and server counts for the same event. Meta’s Dataset Quality API reports how much of each stream arrived with a deduplication key, so you can see whether most events are matching. Then compare Meta’s lead count with your own form submissions or CRM for the same week. They will not match exactly, but they should be close and move together. If Meta reports far more leads than you received, suspect duplication.
Does the server route skip consent?
No. A server event is still personal data about a visitor, so the same consent rules apply. On our own site the Pixel does not load until a visitor chooses Accept all. If you serve visitors in the UK or EU, send server events only for visitors who agreed. Our guide to Consent Mode shows how the signal is passed.
Questions people ask
Which should we install first? The Pixel, then the Conversions API once the Pixel events are clean. Adding the second route to messy data only copies the mess.
Do we need both? Not always. Meta says that if you do not send the same event twice, you do not need deduplication for it.
Can you help set it up? Yes. It is part of our tracking and website ecosystem work, and you can send us the brief and we will reply with how we would set it up.
