The short answer
The browser pixel is the merchant’s phone telling Meta a lead happened, and iOS, ad blockers, Safari and a slow page stop a chunk of those from ever arriving. The Conversions API is the same event sent from your server, which cannot be blocked and carries the hashed contact details Meta needs to match it to a click. Both copies carry the same event ID, so Events Manager sees two and keeps one. If the Deduplicated column is not filling up, every lead is counting twice and the cost per lead is fiction.
Every tracking guide says to run the pixel and the Conversions API together, and almost none of them says why, so it gets treated as belt and braces. It is not. The two are sending the same event over two routes with different failure modes, and the reason the setup is worth doing properly is what happens when only one of them arrives.
Two copies of one event
| Browser pixel | Conversions API | |
|---|---|---|
| Sent by | The merchant’s phone | Your server |
| Stopped by | iOS settings, ad blockers, Safari, a page that never finishes loading | Nothing |
| Carries | The event and its ID | The event, its ID, and the hashed contact details |
| Arrives | Most of the time | Every time |
The browser copy has been the unreliable one since the iOS privacy changes, and on funding traffic that is eighty to ninety percent phones it is unreliable in exactly the population you care about. Running it alone means an unknown share of your qualified leads are invisible to the optimisation: Meta is learning from a sample that was filtered by which merchants happen to run an ad blocker, which has nothing to do with which merchants fund.
Deduplication, and why it is the thing to check
Both copies are sent with the same event ID. Events Manager matches them, sees one event rather than two, and keeps the better-attributed copy. On GoHighLevel and the main WordPress plugins that ID is put on both copies for you; a custom build passes it itself, which is what the event ID in the fbq call is for.
This is the failure worth being afraid of, because it does not look like a failure. Two copies counted separately means the account reports twice the leads it produced, so the cost per lead halves overnight and the campaign looks like the best thing you have ever run. Meanwhile the optimisation is running on duplicates and the phone is not ringing any more than it was. A $24 cost per lead that is really $48 is worse than knowing it is $48.
What this means for the build
- Fire both copies from the same moment: the load of the qualified page, after the one-time passcode has come back. Two copies of an event that fires in the wrong place are still two wrong events.
- Put the hashed contact details on the server copy. That is the half of the job the browser copy cannot do, and without it Meta cannot attribute the event to an ad click.
- Never send the disqualified path down either route. The rule about what gets sent back applies to the server copy exactly as it does to the pixel, and a server event is easier to fire by accident.
- Run the test in Events Manager with the test event code so it does not touch live data, and confirm one deduplicated Lead rather than two.
None of this is difficult, and on a hosted page builder most of it is a switch. It is on the list because it is invisible: a pixel-only setup and a correctly deduplicated one look identical from the outside, and the difference shows up months later as a campaign that never quite learned who to find.