Recover 40–80% of your Duplicate conversions ad revenue.

The diagnosis, yes — and you should do it before hiring anyone. Place one test order, open your browser's network tab, filter for the platform's endpoint and count how many times the purchase event goes out. Then check whether each one carries an event_id and whether those IDs match. If you find two hits with the same ID, deduplication is working and your problem is elsewhere. If you find two hits with different IDs or no ID at all, you've found it. Fixing it is harder than finding it, because usually one of the sources is a native integration you can't fully control.

If your platform count and your order count are within a few percent of each other, you don't have a duplication problem — you have an attribution difference, which is a different job. Also skip this if you're running a single hardcoded pixel with no server-side feed and no native channel integration: there's only one source, so there's nothing to deduplicate. Duplication is a problem of having too many well-meaning integrations, not too few.

Not directly — the orders and the revenue are real and unaffected. What's damaged is the decision-making. Inflated ROAS makes weak campaigns look fundable, and automated bidding trained on doubled conversions will keep buying the traffic that produced them. The cost shows up in budget allocation over the following weeks, not in your revenue line today.

Timing and consistency. Deduplication needs the same event name, the same ID, and both hits inside the platform's matching window. Intermittent failure usually means the server event is fired from a delayed process — a retried webhook, a queued job, a nightly sync — so some pairs land inside the window and some don't. That looks random from the reports and is completely deterministic once you look at the timestamps.

Tempting, and occasionally right, but usually not. The browser hit carries fbp, fbc and click IDs that the server can't generate on its own, and it arrives instantly. The better architecture is both, properly paired: browser for identity signals, server for authority over whether the conversion happened. Going server-only to dodge a dedup problem trades one kind of inaccuracy for another.

Say it plainly: the number was counting some orders twice, and now it counts each one once. Nothing about the business changed. I'll give you the before-and-after reconciliation against your own order records so the conversation is about evidence rather than about whose fault the drop is. In my experience it's a much easier conversation to have with the sheet in hand.

Both, and lead gen is often worse. A form that fires on button click and again on the confirmation page, plus a CRM webhook sending the same lead server-side, will triple-count. The fix is the same shape: pick the record ID from your CRM as the deterministic event_id and let one source own the event.