Conversions API Deduplication: How Double-Counted Events Inflate Your Meta Numbers

Most tracking bugs make your numbers go down. A Conversion API deduplication failure is the one that makes them go up.

When the Meta Pixel and the Conversions API both report the same purchase and Meta cannot tell they are the same purchase, it counts two.

Your ROAS climbs, your cost per purchase falls, delivery optimizes toward events that happened once, and nobody opens a ticket, because nobody investigates good news.

Today’s post covers how deduplication is supposed to work, the four ways it breaks in 2026, and how to find out whether it is happening to you right now.

How does Conversions API deduplication work?

Deduplication is Meta’s process for recognizing that a browser event from the Pixel and a server event from the Conversions API describe the same action, and counting them once.

It runs on two parameters that must match exactly on both sides: event_name and event_id, and both copies must arrive within a 48-hour window, as SignalBridge’s deduplication guide lays out.

In practice that means:

The Pixel fires Purchase with an eventID, typically the order number.
Your server sends Purchase through the Conversions API with the same value as event_id.
Meta sees both, matches them, and shows one Purchase with a Deduplicated badge in Events Manager.

It is a simple mechanism, which is why it fails simply.

The names must match character for character (Purchase and purchase are different events).
The IDs must be identical strings.
And the IDs must be unique per occurrence, so an order number works and a timestamp rounded to the second does not.

Meta recommends running both channels precisely because they catch different things: the Pixel sees browsing the server never records, and server side events survive the ad blockers and Safari limits that drop browser events. Two witnesses to one conversion. The whole arrangement depends on Meta knowing they are describing the same thing.

Why does deduplication fail?

Deduplication fails when the two copies of an event carry different identifiers, or when more than two copies exist. In 2026, four scenarios cover most of the cases we see on ecommerce accounts.

1. Only one side is sending event_id

The most common failure.

The server integration sends event_id because the app or connector was built to.
The Pixel does not, because it was installed years ago from a snippet that never included it.
Meta receives a server Purchase with an ID and a browser Purchase without one, has nothing to match on, and counts both.

The same thing happens in reverse when a theme-level Pixel includes eventID and a hastily configured server call doesn’t.

2. Two server-side sources

Meta’s one-click, Meta-enabled Conversions API shipped in April 2026, and it is easy to turn on without noticing that a Shopify app or tag manager integration is already sending server events.

Now the same purchase arrives from the browser, from server source A, and from server source B.
Even if the Pixel and one server copy deduplicate cleanly, the third copy stands alone.
Vizup’s checklist for the one-click setup puts verifying deduplication before enabling it, and that ordering matters.

3. Parallel runs during the Shopify migration

When Shopify retired Additional Scripts for non-Plus stores on August 26, the standard advice (ours included, in our post on the deadline) was to run the legacy scripts alongside the new Customer Events pixel for a couple of weeks to confirm nothing dropped.

That is sound advice for catching missing events and a reliable way to create duplicated ones. If the parallel run is still going in late September, or the old scripts were never removed, every purchase is firing twice from the browser.

4. Multiple apps and theme-level pixels

A Pixel installed through Shopify’s Meta channel plus a Pixel pasted into theme.liquid.
A funnel or upsell app that ships its own Purchase event.
A thank-you page that reloads inside an iframe and fires the event again.

Upstack Data’s rundown of Shopify duplication scenarios covers each of these, and none of them carry a matching event_id because they were never designed to know about each other.

What double-counted events do to your Meta numbers

Double-counted purchases inflate every downstream metric in the same direction, and the inflation compounds through optimization.

Reported purchases exceed real orders.
ROAS rises by the same proportion.
Cost per purchase falls.

Meta’s delivery system, which learns from the conversion events it receives, starts optimizing toward audiences and placements that generate duplicate-prone events rather than more sales.

The size of the effect depends on how many copies survive.

Pixel plus one unmatched server source means roughly two purchases per order wherever both fire, which is most traffic. Three sources runs higher.

And as AdAdvisor’s Conversions API guide notes, the failure “shows up as a rise: more conversions, stronger ROAS,” which is exactly why it persists. A dip gets caught in a week. A lift gets reported to the client as a win. We wrote about the general shape of this in platform-reported ROAS vs actual ROAS; deduplication is the mechanical version.

How to check whether your events are being deduplicated

You can confirm deduplication in fifteen minutes with three checks, and the first one needs no Meta access at all.

Compare Meta’s received Purchase count to your store’s orders. Pick a clean seven-day window. Pull paid orders from your store, tests and cancellations excluded. In Events Manager, open Purchase and note the total events received for the same window. If Meta’s count is meaningfully above your orders, something is being counted twice. Attribution settings cannot explain this one, because received events sit upstream of attribution.
Look at the source breakdown and the Deduplicated badge. Still in Events Manager, the Purchase event should show browser and server sources with a deduplicated count between them. Two separate rows with no badge is the failure. The Diagnostics tab also flags missing event_id on one side.
Place a test order and watch Test Events. One order should produce one browser Purchase and one server Purchase with identical event_id values, merged into one. If you see three events, or two with different IDs, you have found your cause. Wittelsbach’s diagnostic is worth reading if you want to measure a duplicate rate properly rather than eyeball it.

What to actually do

Use the order ID as event_id on both sides, always. It is unique, it is available at the moment of purchase in both the browser and your backend, and it makes the match deterministic.
Run exactly one browser Pixel and exactly one server source. Audit Events Manager for every source sending Purchase. Remove theme-level snippets, disable app-level tracking that duplicates the Meta channel, and pick one server integration. If you turned on the Meta-enabled Conversions API, turn off whatever it replaced.
End the Shopify parallel run. If you kept legacy scripts alive through the August migration, they have done their job. Delete them.
Match event names exactly. Purchase, not purchase, not PurchaseComplete. Same string on both channels.
Re-run the three checks monthly. Every app install and every platform update is a chance for a new source to appear.
Keep a count Meta didn’t produce. Every step above makes Meta’s Purchase number more accurate. None of it makes that number independent. A first-party, click-only attribution record on your own domain captures the click ID at landing, follows the session, and ties the order to the ad that sent it, from your order data rather than from an event Meta received.

It counts each order once because it starts from the order.

It won’t credit views or engagement and will undercount some upper-funnel influence, and it is the number that would have caught a dedup failure on day one, because it never matched Meta’s inflated count. Our post on why iOS ROAS still looks wrong after CAPI covers the other direction of the same problem.

Deduplication is the least glamorous part of a Conversions API setup and the one most likely to be quietly lying to you in the direction you want to hear.

Check received events against orders this week. If you want to see how your Meta Purchase count compares with a click-only, first-party record built from your own orders, book a live AdBeacon demo.

—-

FAQ

What is Conversions API deduplication?

Deduplication is how Meta recognizes that a browser event from the Pixel and a server event from the Conversions API describe the same action and counts them once. It matches on event_name and event_id, and both copies must arrive within 48 hours.

What happens if event_id is missing from the Pixel or the Conversions API?

Meta cannot match the two copies and counts both. Reported purchases exceed real orders, ROAS is inflated by the same proportion, and delivery optimizes toward duplicated events.

How do I know if Meta is double counting my purchases?

Compare the Purchase events Meta received in Events Manager against your store’s paid orders for the same window. If Meta’s count is higher, you have a duplication problem. Attribution settings cannot cause this, because received events sit upstream of attribution.

Does the Meta-enabled one-click Conversions API cause duplicate events?

It can, if you already have a server-side integration sending the same events through a Shopify app or tag manager. Run one server source only, and verify deduplication in Test Events before relying on it.

What should I use as the event_id for Purchase events?

The order ID. It is unique, available in both the browser and your backend at the moment of purchase, and makes the browser-to-server match deterministic.