Facebook Conversions API duplicate events: how to dedupe with event_id (and how to audit it)

Everyone is thrilled the week they add server-side events. Conversions are up. ROAS is up. Then finance compares it to the bank account.

That's usually double counting, and it's remarkably easy to cause.

Here's how Meta thinks about it. When the same purchase arrives from the browser and from the server, Meta treats them as one event if the event name and the event_id match, and keeps one. If the event_id is missing or different, it counts the sale twice. There's no cleverness. It's an ID comparison.

So the fix is simple in words: generate one ID per event, and send the same ID from the browser and from the server. In practice, where does it go wrong? Four patterns.

Two sources, two IDs. The pixel and the CRM both report the same sale, each with its own ID. Meta sees two different sales.

The retry. A tool retries a failed send and creates a second copy, sometimes with a fresh ID.

The second integration. Two tools both push "Purchase", and nobody remembers installing the second one. This one is common after an agency change.

The renamed event. The pixel sends "Purchase" and the server sends "purchase". Different names, so no dedupe.

For Google Ads, the equivalent habit is sending an order ID (transaction ID) with each conversion, so repeats get ignored.

How do you audit it? A method that takes ten minutes: pick one week. Count the orders in your CRM or shop. Count the conversions the ad platform reports for the same week. Ad platform conversions far above real orders means duplicates. Far below means dropped events. Roughly equal means you're close, though check revenue too, because you can have the right count and the wrong values.

And here's a made-up example to keep it honest. Your CRM shows 50 orders. Meta reports 96. That's nearly 2x, which almost always means every sale is arriving twice with different IDs. The fix isn't in Meta. It's making the browser and the server agree on one ID.

A subtlety: you can have duplicates that don't show up as a bigger count. If the same sale arrives twice with different values, or one copy arrives as a Purchase and the other as a Lead, the totals look plausible and the revenue is wrong. So audit revenue as well as count: the total value the platform reports for the week, against your real revenue.

Also look at the event names in Events Manager. If you see two near-identical names, like Purchase and purchase, that's usually your duplicate source. And check when the duplicates started. If the count jumped on a specific date, look at what you deployed that day: a new plugin, a new integration, a changed workflow. The date almost always points at the cause, because duplicates are introduced by changes, not by drift.

If you send sales through a webhook instead of a pixel, the order ID plays the same role as the event ID. The same order ID arriving twice counts once, which makes retries safe. Set it once, from your own system's order number, and reuse it every time that sale is sent.

The prevention that works: decide who owns the event ID. The simplest rule is that the website generates it at the moment of the action, and every other system reuses it. When two systems each invent their own, you get duplicates. If the CRM event happens later, it needs the original ID, which means storing it on the contact at the time of the action. That one storage step is what makes dedupe possible days later. Skip it, and you'll be reconciling by hand forever.

Has anyone found a clean way to audit this on a regular basis, or is it a manual spreadsheet for everyone?