Event Deduplication

Deduplication is how Meta recognizes that a purchase reported by the browser pixel and the same purchase reported by your server are one event, not two, so it counts it once.

Once you are sending events from both the pixel and the Conversions API, you have a new problem hiding inside the fix: the same person buying once can now be described to Meta twice, once by their browser and once by your server. If Meta treated those as two separate purchases, your reporting would balloon and your cost per result would look far better than it really is. Deduplication is what stops that. You attach the same event name and the same unique event ID to both reports, and when Meta sees two events arrive carrying the matching name and ID, it understands they are two descriptions of a single moment and keeps only one.

The reason this sits at the center of a healthy dataset is that the whole point of sending from both sides is coverage, and coverage is worthless if it comes with double counting. Done right, deduplication lets the browser and the server back each other up: when the browser event gets blocked, the server event still lands, and when both arrive, Meta quietly collapses them into one. You get the completeness of two sources without paying for it in inflated numbers.

It breaks silently, which is the dangerous part. If the browser and the server put a different event ID on the same purchase, or one of them omits the ID entirely, Meta cannot match them and counts both, and nothing on screen shouts that it is happening. You just see a purchase number that runs suspiciously ahead of your real sales. The check is boring and necessary: confirm the same event name and event ID travel with the event on both roads.

Two roads into the dataset only help if Meta can tell when they are carrying the same sale.