Event deduplication is how Meta recognizes that a browser event from the Meta Pixel and a server event from the Conversions API describe the same action, and counts it once. It works when both copies share the same event name and the same event ID. If they don’t match, one purchase can show up as two.
Most Shopify stores that care about tracking accuracy send events both ways: the Pixel from the shopper’s browser, and the Conversions API from a server. This redundant setup is what Meta recommends, because each side catches events the other can miss. But it only works if Meta can tell the copies apart from genuinely separate events.
This guide explains how Meta makes that decision, what a correct pair looks like and how to check that it’s working on your store.
How Meta decides two events are the same
Meta’s main method compares two values on every event it receives:
| Rule | What Meta checks |
|---|---|
| Event name | The Pixel’s event name must match the Conversions API’s event_name (for example, Purchase and Purchase) |
| Event ID | The Pixel’s eventID must match the Conversions API’s event_id |
| Time window | The copies must arrive within 48 hours of the first event Meta received with that event ID |
| Which copy is kept | Meta keeps the first copy it receives and discards the later ones |
If the name and ID match within 48 hours, Meta counts one event. If either one differs, or the second copy arrives later than 48 hours, Meta treats them as two separate events.
Meta also has a fallback method that compares the event name with the fbp (browser ID) and/or external_id values. It has limits: it generally only works when the browser event arrives first and the server event second, and it doesn’t deduplicate anything when you only use one source. The event ID method is the one to rely on.
Two points that often cause confusion:
One copy being discarded is not a problem. That’s what successful deduplication looks like. If the browser copy arrived first, Meta keeps it and drops the server copy.
Timing doesn’t have to be close. The copies don’t need to arrive within seconds of each other. They need to arrive within the 48-hour window.
What a matching pair looks like
Here is a Purchase sent both ways with the same event name and event ID.
Browser (Meta Pixel):
fbq('track', 'Purchase',
{ value: 129.00, currency: 'USD' },
{ eventID: '<Shopify order ID>' }
);
The event ID goes in the fourth argument of the fbq call, not inside the value and currency object.
Server (Conversions API):
{
"data": [
{
"event_name": "Purchase",
"event_time": 1792656000,
"event_id": "<Shopify order ID>",
"action_source": "website",
"event_source_url": "https://yourstore.com/checkouts/thank-you",
"user_data": {
"em": ["<SHA-256 of lowercased email>"],
"fbp": "<_fbp cookie value>"
},
"custom_data": {
"value": 129.00,
"currency": "USD"
}
}
]
}
The event name is Purchase on both sides, and both carry the same order ID, so Meta counts one purchase.
A pair that won’t deduplicate:
Browser: eventID: ‘a8f3k2’ (a random value generated in the browser)
Server: event_id: ‘x91qp7’ (a different random value generated on the server)
Each copy has an ID, but they don’t match, so Meta counts two purchases.
Choosing the event ID
The event ID has to be something both the browser and the server know about the same action.
For Purchase, use the Shopify order ID. The thank-you page knows it, and the server knows it from the order. It’s unique to each purchase, so two different orders never share an ID.
For storefront events (PageView, ViewContent, AddToCart, Search), there’s no order yet. Generate one ID in the browser when the event fires, and pass that same ID to your server so it sends it with the Conversions API copy.
For checkout events, Shopify’s checkout gives each event its own ID, which both sides can use.
Never generate an unrelated random ID on each side. Every ID has to describe one specific action, and it has to be the same on both copies.
Deduplication doesn’t improve match quality
Getting deduplication right doesn’t raise your Event Match Quality (EMQ) score. They answer different questions, and Meta reports them separately:
| Question | What Meta calls it | What fixes it |
|---|---|---|
| Is this one action counted once? | Deduplication | Matching event names and event IDs on both copies |
| Is the server sending the events the Pixel sends? | Event coverage | Sending events from both browser and server |
| Can Meta recognize the person behind the event? | Event Match Quality | Sending more customer identifiers, correctly formatted and with consent |
The event ID tells Meta which copies belong together. It says nothing about who the shopper is. A store can have perfect deduplication and a low EMQ score, or the other way round.
If your problem is a low score rather than double counting, see our guide on how to improve Meta Event Match Quality.
How to check deduplication on your store
Work through these checks in order.
1. Confirm the event arrives from both sources
In Events Manager, open your dataset (pixel) and look at the Overview. Under Connection Method, Meta shows the channel each event was sent through. For deduplication to matter, the event (usually Purchase) needs to arrive from both the browser and the server.
2. Open the Event Deduplication tab
Click Event Details for the event, then open the Event Deduplication tab. Meta shows two things here:
Rate of Events Deduplicated: the percentage of events from each source that were deduplicated. Higher is better, and Meta shows a warning when the rate is too low.
Rate of Deduplication Key Usage: the share of events from each source that carried each deduplication key (such as the event ID), and the Overlap, meaning the share of events with a given key received from both sources. Low overlap usually means the two sides are sending keys that don’t match, or keys that aren’t unique.
The Overview also shows event counts before deduplication, so a raw count that’s roughly double your orders is not a problem on its own.
3. Check that both sides send the same ID
If the deduplication rate is low, compare the event ID the Pixel sends with the one your server sends for the same action. You can see the browser copy with the Meta Pixel Helper browser extension or Meta’s Test Events tool. On the server side, check your Conversions API logs or your tracking app’s event log. The two values must be identical.
4. Compare purchases with your Shopify orders
For a few complete days, compare the Purchase count Meta received (in Events Manager, not Ads Manager) with the number of orders in Shopify for the same days.
Far more purchases than orders points to duplicates.
Far fewer points to missing events, which is a coverage problem rather than a deduplication one.
Ads Manager shows conversions attributed to your ads, using its own attribution settings. That number isn’t meant to match your order count, so don’t use it for this check.
5. Look for the Pixel firing twice
If purchases are inflated but deduplication looks fine, the browser may be sending the event twice. This usually happens when two sources send the same Pixel event:
Shopify’s own Facebook & Instagram channel and a tracking app
Two tracking apps
Hard-coded Pixel code left in the theme after installing an app
Two browser copies of the same purchase with different IDs will both be counted.
Check your theme files and apps for extra Pixel code. Our help center guide to cleaning up hard-coded pixel codes walks through where to look.
Common causes of duplicate events
| Cause | What happens | Fix |
|---|---|---|
| No event ID on one or both sides | Meta can’t pair the copies | Send the same event ID with every Pixel and Conversions API event |
| Different IDs on each side | Each copy looks like a separate event | Use an ID both sides know, such as the order ID for Purchase |
| Different event names | “Purchase” and a custom name such as “Order Completed” don’t match | Use the same standard event name on both sides |
| Second copy arrives after 48 hours | Meta treats it as a new event | Make sure server events are sent promptly and retries don’t run past 48 hours |
| More than one Pixel integration | The browser sends the same event twice | Keep one Pixel integration per pixel and remove leftover theme code |
| Relying only on the fbp/external_id fallback | Only works browser-first, and not with a single source | Add a shared event ID |
How Analyzify handles Meta deduplication on Shopify
Analyzify sends Meta events from both the browser (Meta Pixel) and the server (Conversions API), and sets the same event ID on both copies:
Purchase: the Shopify order ID is used as the event ID on the Pixel and the Conversions API copy.
Storefront events such as PageView, ViewContent, AddToCart and Search: one shared ID is created when the event fires and reused for the server-side copy.
Checkout events: Shopify’s own checkout event ID is used for both the Pixel and the server-side copy.
Repeated clicks: duplicate add-to-cart and remove-from-cart events fired within 3 seconds are suppressed in the browser.
Page reloads: the Purchase and AddPaymentInfo events fire once per session, so a shopper reloading the thank-you page doesn’t send a second purchase.
Double-tracking warnings: the Analyzify app warns you during setup if it detects double tracking. The setup also asks you to remove hard-coded tracking snippets left in your theme.
Server-side purchases are sent from Shopify order data. If the browser copy was blocked or the thank-you page never loaded, the server copy fills the gap. If both arrive, Meta keeps one.
To learn how the integration works, see Meta Conversion API integration via Analyzify and Analyzify server-side tracking. For a comparison with Shopify’s built-in channel, see Analyzify vs. native Shopify Meta integration.
Want to check what your store sends today? Run a free tracking audit, or install Analyzify to run the Meta Pixel and Conversions API together.
Achieve Data Confidence and Get the Help You Need When It Matters.
Frequently Asked Questions
No. Deduplication makes sure a browser and server copy of the same event is counted once. Event Match Quality measures how well the customer information on an event can be matched to a Meta account. Fixing one doesn't change the other.
Meta keeps the first copy it receives with a given event name and event ID, and discards the later ones. With a Pixel and Conversions API setup, that is often the browser copy.
48 hours. Meta deduplicates copies received within 48 hours of the first event with that event ID. A copy that arrives later is counted as a new event.
Partly. Meta can also compare the event name with fbp and/or external_id, but this generally only works when the browser event arrives before the server event, and not with a single source. A shared event ID is more reliable.
Check the raw event count in Events Manager first. If it's well above your order count after deduplication, look for missing or mismatched event IDs, different event names, or a Pixel firing twice. Ads Manager conversions are attributed results and aren't expected to match your order count.
No. Meta recommends using the Conversions API alongside the Pixel. Each one can catch events the other misses, and deduplication keeps the overlap from being counted twice.
