In short
Deduplication prevents the same conversion being counted twice when it arrives from two paths, typically the browser pixel and the server. Both copies carry the same event ID and event name, and the platform keeps one, preferring the richer payload. Running two paths is deliberate: the pixel is real-time and captures browser context, while the server captures what the browser loses to ad blockers and tracking prevention. Together they maximize coverage, and deduplication is what makes running them together safe rather than double-counting. The common failure is mismatched event IDs between pixel and server, which inflates reported conversions and corrupts the optimization signal the platform learns from. A correct setup assigns a shared event ID at source and verifies deduplication in a live debugger before trusting the numbers. Datahash configures shared event IDs by default and confirms dedup in the debugger, so coverage goes up without the count going wrong.
Why send both pixel and server events?
The pixel is real-time and captures browser context; the server captures what the browser loses. Together they maximize coverage. Dedup makes together safe.
What breaks deduplication?
Mismatched event IDs between pixel and server, which inflates conversions and corrupts optimization. Datahash configures shared event IDs by default and verifies dedup in the live debugger.
What happens when deduplication is misconfigured?
A team turns on CAPI beside an existing pixel without a shared event ID. Conversions appear to jump, but the lift is phantom double-counting, and bidding degrades because the platform is learning from inflated numbers. Matching the event IDs collapses the duplicates back to the truth.
Reference: Meta for Developers, handling duplicate pixel and server events