Meta Pixel and CAPI: Event Deduplication Diagnostic

Duplicates between the Meta Pixel and the Conversions API come from one place: the same action reaching Meta twice without a key that ties the copies together. Read what Meta already reports before you build anything, then use the ledger below to classify every record you hold. One rule shapes the whole diagnostic: Meta keeps only the first copy of an event_name and event_id pair, so a retry is safe only if it reuses the original event_id.

For the setup behind this check, read Should events come from the browser or the server?, and for the definition, What is event deduplication in Meta Ads?.

Where does Events Manager show deduplication?

Meta puts the evidence on each event’s detail page (View server event details):

1. Open Events Manager, select your dataset (the pixel’s name and ID), find Purchase and click View details.
2. Read the Event overview tab. “Events received” is the pixel and Conversions API total added together, not deduplicated, and Meta says server events should match or exceed pixel events.
3. Open the Event deduplication tab. Note the share of pixel and server events received with each deduplication key, and the overlap: the share of keyed events Meta received from both sources.
4. Open Test events (Events Manager > Data sources > your pixel > Test events), place a test order, and confirm one Purchase is received and its twin shown as deduplicated.
5. Compare a full week of Events Manager purchases with Ads Manager purchases for the same dates before you call the gap a fault.

Step 5 matters because the two screens count differently: the Events Manager total is reported before duplicates are discarded, while Ads Manager shows attributed events after deduplication (event count differences). A gap between them is expected; a gap between Ads Manager and your orders is the one to chase.

If the Diagnostics tab also flags redundant purchases or a value mismatch, What do Meta Events Manager diagnostics warnings mean? explains each message and its fix.

What does Meta actually deduplicate?

Meta’s deduplication guide and its server event parameters set the rules:

• The key is two fields. The pixel’s eventID must match the server’s event_id, and the pixel’s event name must match event_name. In the pixel, eventID is the fourth argument of the fbq('track') call.
• The window is 48 hours. When the same pair arrives within 48 hours, Meta keeps the first and discards the rest. If a browser and a server copy arrive within 5 minutes of each other, Meta favours the browser copy.
• Use the order number. Meta suggests the order number or transaction ID as event_id for purchases. Its own example: two orders sent from both sources without matching IDs read as four unique purchases instead of two.
• The fallback is weaker. Matching on fbp or external_id instead of event_id only works when the browser event arrives first, and never deduplicates a browser-only or server-only setup.
• Late events fail loudly. A server event_time can be up to 7 days old. If any event in a request is older, Meta rejects the whole request and processes none of it.

Are retried server events deduplicated?

Yes, when the retry keeps the original key. Meta’s developer guide says that if it receives the same event_id and event_name more than once it keeps only the first copy, which makes batch retries safe, and the Business Help Center’s deduplication article lists “redundant server events (identical event_name and event_id)” among the cases deduplication covers. The guide’s line that two identical server events are both kept applies only to matching on fbp or external_id, which never deduplicates a server-only setup. So keep the original event_id on every retry, and never mint a new one for a resend.

How do I classify each record?

Use the ledger below as your occurrence record. Every row is a logical occurrence keyed on event_name plus event_id; the classification is our operating rule, not a Meta field.

Duplicate rate = (event records classified as duplicates after the first valid record per logical occurrence) ÷ (eligible event records received in the diagnostic window). This is our working definition, not a Meta metric. Source and window: your immutable raw collector log plus commerce order transitions. Limitation: define eligibility and the logical key before counting; a duplicate rate says nothing about payload accuracy.

What should a duplicate rate not be used for?

Use the ledger only for the decision it supports: whether one logical occurrence reaches Meta more than once. Do not calculate the rate until event eligibility and the event_name plus event_id key are frozen, or you will count the definition change as a fault. A high rate tells you where to look, not which campaign result it distorted.

One signal Meta does publish helps here. In Events Manager, a high “additional conversions reported” percentage can mean the Conversions API is outperforming the pixel, or that deduplication is poor because deduplication keys are missing from some events (how to interpret it). Read it alongside the deduplication tab, never alone.

Can software help?

Bach.ai connects to your Meta ad account, audits it, and ranks the revenue leaks it finds by estimated dollar impact, each with a proposed fix. It applies a fix on Meta only after you approve it. It does not replace the Events Manager check above: that one stays yours to run.

For the account-wide checks around tracking, see the Meta ads audit checklist.

FAQ

Does Meta deduplicate two server events with the same event_id?

Yes, within 48 hours, if both carry the same event_name and event_id: Meta keeps the first copy and drops the rest, so batch retries are safe. A resend with a new event_id counts again. Matching on fbp or external_id alone does not deduplicate two server events.

Why does Events Manager show more purchases than Ads Manager?

They count different things. The Events Manager total includes most events received, attributed or not, before duplicates are discarded. Ads Manager shows only events attributed to someone who saw your ad, after deduplication. A higher Events Manager number is normal; compare Ads Manager with your store orders instead.

What should I use as the event_id for a purchase?

Meta suggests the order number or transaction ID, sent as event_id from the server and as eventID from the pixel. Two orders with their own numbers then stay two purchases. Without matching IDs, Meta’s own example shows the same two orders reading as four unique purchases.

Do Shopify and other platforms handle deduplication for me?

Meta says many partner integrations, Shopify and WooCommerce among them, add the deduplication parameters automatically. That covers events the integration sends. A second pixel pasted into theme code or a tag manager sits outside it, so its events carry no shared ID; see why a Meta pixel stops firing on Shopify.

Can a deduplication ledger prove why campaign performance changed?

No. It shows whether one logical occurrence reached Meta more than once, which isolates one competing explanation for a reporting change. It cannot show that duplicates caused a performance shift; for that you need the same window compared before and after the fix, ideally against store orders.

Sources: Meta, Handling Duplicate Pixel and Conversions API Events; Meta, Server Event Parameters; Meta Business Help Center, About deduplication, View server event details, Event count differences, Additional conversions reported (all checked 1 Oct 2026).