Get your Duplicate conversions tracking to 95%+ accuracy guaranteed in writing.
The platform reports a ROAS your books can't back up, and the purchase count sitting in Events Manager is suspiciously close to double your order count. Duplicate conversions aren't just a reporting embarrassment — they're what your bidding algorithms are learning from. I find every source firing each event and rebuild the whole thing around one deterministic ID per order.
Free30 minutesNo obligation
By Ariful IslamDuplicate conversions · what breaks
How one order turns into two conversions
- 01
Pixel and CAPI send the same order with no shared ID
Deduplication requires an identical event_name and an identical event_id on both hits. Miss the ID on either side, or send "Purchase" from one and "purchase" from the other, and Meta reads one sale as two separate buyers.
- 02
The server event arrives after the dedup window has closed
Meta matches a browser and server pair within roughly 48 hours. A nightly CRM batch, a retried webhook or an offline upload lands too late, so a correctly-tagged event still gets counted as brand new.
- 03
Three separate things are firing the same purchase
A native platform channel pixel, a custom checkout pixel and a GTM container all send Purchase. No single one of them is misconfigured. Together they turn every order into a small crowd.
- 04
The confirmation page counts again on every refresh
Order-status pages can be revisited, bookmarked and reloaded — and on some platforms customers get emailed a link straight back to them. Without transaction_id or event_id handling, each visit is a fresh conversion.
Duplicate conversions · the fix
What changes when one order equals one conversion
One event per order, on every platform, every time
The same deterministic ID travels with the order through browser and server, so a refresh, a retry or a redundant tag can't manufacture a second sale.
The Events Manager overlap warning goes quiet
Meta's own diagnostics stop flagging redundant events, which is the fastest independent confirmation that deduplication is genuinely working.
Reported ROAS lines up with what your books say
Not because the platform got generous, but because it stopped counting revenue twice. Expect the headline number to go down and become usable.
Bidding is trained on the real number
Smart Bidding and Advantage+ optimize toward the conversions you report. Feeding them two purchases per order teaches them to buy traffic that performs half as well as it appears to.
Duplicate conversions · normal or broken
Two hits isn't duplication. Two counts is.
A browser event and a server event for the same order is the architecture working, not a bug. Duplication is what happens when the platform can't tell those two apart — or when three separate systems are firing.
Normal, not a fault
The same purchase appears twice in the network tab
Browser and server both sending is deliberate: the browser carries fbp, fbc and click IDs, the server carries authority over whether the order really happened. If both hits share event_name and event_id, one gets collapsed.
Events Manager displays a deduplication notice
That panel is telling you it saw a matched pair and kept one. Seeing it alongside a healthy dedup rate is confirmation the setup is correct, not a warning that something needs fixing.
A Google Ads action set to "Every" counts more than once
For lead or add-to-cart actions, counting every conversion per click is often the right setting on purpose. Check the counting rule before you decide the tag is misbehaving.
Platform totals run a few percent above your order count
Modeled conversions, cross-device matching and window differences all nudge platform numbers up. Duplication doesn't look like a margin — it looks like a multiple.
Actually broken
The platform sits at roughly 2x your order count, steadily
A clean multiple that holds week after week is a duplicated source. Attribution differences are messy and move with your channel mix; they never produce a tidy doubling.
One transaction_id appears twice in GA4
Same order, two events, different session IDs — the confirmation page is being counted again on refresh or back-navigation. Every customer who reloads is inflating your revenue.
Dedup rate is low while both browser and server are sending
The pair isn't matching. Either the server event has no event_id, it's generating a random one, or it's fired from a delayed job arriving outside Meta's roughly 48-hour matching window.
Reported revenue exceeds what your books say for the period
Value is being double-counted along with the event. This is the version that matters most, because Smart Bidding and Advantage+ are optimizing toward a revenue figure that doesn't exist.
Duplicate conversions · diagnose
One test order tells you almost everything — Duplicate conversions
You can confirm or rule out duplication in about fifteen minutes with your browser's network tab and one purchase.
- 01
Place one test order and count the hits
Open the network tab before checkout, then filter on the platform's endpoint — facebook.com/tr, google-analytics.com/g/collect, googleads.g.doubleclick.net. Count how many purchase hits leave for each platform.
- 02
Read the event_id on every hit
Expand each request and compare event_id for Meta and transaction_id for GA4. If they're missing, or different on each hit, deduplication is impossible no matter what the platform documentation promises.
- 03
Refresh the confirmation page twice
Watch whether the purchase event fires again on each reload. If it does, there's no idempotency guard, and every customer who refreshes or hits back is adding a phantom conversion.
- 04
Inventory every source that can fire the event
Web GTM container, a hardcoded snippet in the theme, the platform's native channel app, a server container, and any partner or app integration. Write the list down; almost nobody has only one.
- 05
Compare a closed week to your order count
Platform purchase count divided by backend order count. A ratio near 2.0 names your problem. A ratio near 1.1 means you have an attribution question, which is different work.
- 06
Check the counting rule on each Ads action
In Google Ads, open the conversion action and read whether it counts every conversion or one per click. A purchase action left on "Every" counts a repeat visit as a second sale.
Duplicate conversions · prove
One paid order, one conversion, on every platform
The target isn't fewer conversions. It's exactly one per order, everywhere, with the before-and-after ratio written down so nobody has to argue about why the number moved.
Source of truth
Your order table — one paid order equals one conversion, on every platform
- Record the exact order count and revenue total from your backend for a closed seven-day window.
- Put each platform's event count for that window beside it; the target ratio is one to one, not lower.
- Confirm in Events Manager that browser and server Purchase pairs are collapsing at a healthy dedup rate.
- Spot-check ten order IDs end to end: one row per order per platform, one value, one currency.
- Reload the confirmation page five times and confirm no sixth event is created anywhere.
- Sign-off is 95%+ one-to-one match against your order export, with the before-and-after ratio documented.
Duplicate conversions · free audit
What we check in the free audit
- Place one test order and count the hits
- Read the event_id on every hit
- Refresh the confirmation page twice
- Inventory every source that can fire the event
- Compare a closed week to your order count
- Check the counting rule on each Ads action
Checked against
Your order table — one paid order equals one conversion, on every platform
Free30 minutesNo obligation
Duplicate conversions · when not to buy
When you don't have a duplication problem
This one gets misdiagnosed more than anything else I work on, usually in the direction of paying for a rebuild you don't need.
- Your platform count and your order count are within a few percent. That's an attribution difference, and it's a different job entirely.
- The two hits you found carry the same event_name and the same event_id. That's the correct design — check the dedup rate before spending anything.
- You run one hardcoded pixel with no server feed and no native channel integration. There's only one source; the cause is elsewhere.
- Your Google Ads lead action is set to count "Every" conversion on purpose. If that's wrong for you, changing it takes ten seconds.
Duplicate conversions · what we deliver
What a deduplication rebuild covers — Duplicate conversions
A source inventory: everything firing every money event
Native platform integrations, app-installed pixels, custom pixels, hardcoded snippets and container tags — listed with what each one sends and whether it should exist.
A deterministic event_id derived from your order ID
Never a timestamp, never a random string. The ID is reproducible from the order itself, so browser and server independently arrive at the same value.
One owner per platform per event, everything else removed
Each platform gets exactly one authoritative source for each event. Redundant tags are switched off deliberately and documented so nobody re-adds them next quarter.
GA4 transaction_id hygiene and refresh handling
Purchase events carry a stable transaction_id, and repeat views of the confirmation page are suppressed rather than relying on GA4 to clean up after you.
Google Ads counting rules and import paths corrected
"Every" versus "one" set correctly per action, and any action being counted by both the native tag and a GA4 import reduced to a single path.
Before-and-after overlap and dedup verification
Meta's overlap report, the raw event counts and your order table compared across the same window so the fix is demonstrated, not asserted.
Written guarantee
95%+ tracking accuracy
Measured against Your order table — one paid order equals one conversion, on every platform. Miss it and we keep working at no cost.
FAQ
Duplicate conversions questions, answered
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.
More on Duplicate conversions
- GuideDuplicate Purchase Events Are Wrecking Your Ad Data — Find and Fix Them
- GuideMeta Pixel Firing Twice: Find the Duplicate and Kill It
- Google Ads duplicate conversionsWhy is Google Ads counting duplicate conversions?
- Enhanced ConversionsEnhanced Conversions enrich the conversions that already fire. First we make sur…
- Meta CAPIA one-click CAPI integration sends thin events. That's why your Event Match Qual…
Free · 30 min
Let's find out how many times one order gets counted
WhatsAppFree30 minutesNo obligation
