Why You Send the Same Event Twice
Modern conversion tracking is deliberately redundant. The browser pixel fires when the customer hits the thank-you page, which is fast and easy but fragile: ad blockers, browser privacy features, and lost sessions cause the pixel to miss a meaningful share of real sales. The server-side Conversions API fires the same event from your backend, which is durable and hard to block but can miss browser-only context.
Running both is the correct setup, because the two channels cover each other's blind spots. The pixel catches what the server does not see; the server catches what the browser drops. The price of that redundancy is that most conversions now get reported twice, and something has to reconcile the pair back into one.
The Deduplication Key
The platform reconciles the two reports using a matching key. On Meta, that key is a shared event ID plus the event name. When the pixel and the server both send a purchase with the same event_id and the same event_name, Meta treats them as one event and drops the duplicate. Meta also uses the browser identifier (fbp) as a secondary signal, but the event ID is the one you control and the one that actually does the work.
The whole trick is that both channels must attach the same ID to the same sale. Generate one event ID at the moment of purchase, pass it to the pixel event and to the server event, and the two line up. Generate a different ID on each side, or forget to send it on one side, and the pair never matches.
The pixel and the server both report the same purchase; a shared event ID is what lets Meta collapse the pair into a single counted conversion.
What Happens When Deduplication Fails
When the IDs do not match, the platform cannot tell the two reports apart, so it counts both. One sale becomes two conversions. This is not a rare edge case. If you run pixel and CAPI without a shared event ID, a large fraction of your conversions double, and the damage cascades:
Your reported conversion count inflates, sometimes by double digits. Your cost per acquisition looks artificially low, because you are dividing real spend by inflated conversions. Your ROAS looks better than it is. And because the algorithm learns from the events it counts, it starts training toward a volume of conversions that never actually happened, pushing budget on the strength of phantom sales.
The cruel part is that everything looks like it is working. The dashboard is green, the numbers are up, and nothing throws an error. Double-counting does not break your tracking. It quietly makes it lie in the flattering direction, which is the hardest kind of lie to catch.
How to Get It Right
The fix is disciplined, not complicated. Generate a single event ID at the moment of conversion. Send that exact ID on both the pixel event and the server event, alongside a matching event name. Confirm in the platform's event tools that your events show as deduplicated rather than as separate counts. And treat it as something to verify, not assume, because a deploy that changes how one side generates its ID silently breaks the match without any visible failure.
A tracking layer that owns both the pixel and the server event can guarantee the shared ID by construction, because the same system stamps both reports. When the two events come from two disconnected setups wired together by hand, the shared ID becomes a thing you have to maintain, and maintenance is where it slips.
ClickerVolt fires the browser and server events from one layer with a shared event ID by default, so the pixel and the Conversions API deduplicate cleanly without you managing the key. See how the shared event ID keeps one sale counted once. Whatever setup you run, send one ID on both sides and verify the dedup in your platform's event tools before you trust a single number on the dashboard.
FAQ
What is event deduplication in simple terms?
It is the way an ad platform recognizes that the browser pixel and the server-side Conversions API reported the same conversion, so it counts that sale once instead of twice. A shared event ID on both reports is what makes the match work.
Why does Meta count a conversion twice?
Because you send the same purchase from two places, the pixel and the Conversions API, for redundancy. If both reports do not carry the same event ID, Meta cannot tell they are the same sale, so it counts each one separately and your conversions inflate.
What is the deduplication key on Meta?
The primary key is a shared event ID plus the event name. When the pixel and the server both send an event with the same event_id and event_name, Meta keeps one. Meta also uses the browser identifier fbp as a secondary signal.
How do I know if my events are being deduplicated?
Check your platform's event management tools, which flag whether incoming events are being received as deduplicated or counted separately. Do not assume it works after setup; verify it, and re-check after any deploy that touches how event IDs are generated.
Does deduplication reduce my real conversions?
No. Correct deduplication removes only the duplicate report of a sale you already counted once. It does not remove real conversions. What it removes is the inflation caused by counting the same purchase twice.
