Event ID and deduplication
Definition: Deduplication is Meta dropping a doubled event when the same purchase arrives from the Pixel and the Conversions API. Meta treats the two as one when they carry the same event name and the same identifier: eventID in the Pixel and event_id in the Conversions API. The later event of the pair is discarded.
Without a shared identifier the same purchase counts twice, because Meta cannot know it is one event.
Also called: event_id, event deduplication, duplicate Pixel and CAPI events
The demo has sample data; the login comes to your e-mail.
Why it matters for a shop
If a shop runs the Pixel and the Conversions API, every purchase can arrive by two routes. Without a shared identifier Meta’s report shows more purchases than the shop has orders and the cost per purchase looks better than it is. A shared identifier is the cheapest way to avoid that.
How Basketly handles it
- Basketly stores an event by source, external id and status. The same order in the same status is one conversion forever.
- Every send to Meta carries an event id; the same name + id pair is not sent to the same dataset a second time in the same mode.
- Whether the Pixel on the page uses the same id depends on its setup in the shop; the panel does not set that on the Pixel’s behalf.
Sources
- Meta for Developers: Handling duplicate Pixel and Conversions API events: https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events (read 2026-10-29)
- Meta for Developers: Conversions API best practices: https://developers.facebook.com/docs/marketing-api/conversions-api/best-practices (read 2026-10-29)
What Event ID and deduplication does not do
- Deduplication will not join events with different names or events more than 48 hours apart.
- It does not make Meta’s purchase count equal the shop’s: Meta credits purchases to ads by its attribution windows.
Usually from the order number. What matters is that the Pixel (eventID) and the server (event_id) get exactly the same value for the same purchase.
Then there is nothing to deduplicate against, but each send still carries an event id so that a resend does not double the purchase.
There are several causes, among them a missing shared id and different attribution windows. Compare the numbers in the purchase balance before changing the setup.
See also
- Conversions API (CAPI)Sending events, such as purchases, to Meta from the shop’s server instead of the buyer’s browser.Read
- Meta PixelA JavaScript snippet on a shop page that sends browser events to Meta.Read
- fbp and fbcTwo browser identifiers that help Meta tie a purchase to an ad click.Read
- Meta Conversions APIPaid shop orders sent to Meta from the server, through a queue that does not drop purchases, with a result for every delivery.Read
- Pixel and Conversions API Deduplication: event_id, event_name and the 48-Hour WindowHow Meta merges the same event from the Pixel and the Conversions API: event_id, event_name, the 48-hour window, the fbp method, common mistakes and how to check.Read
- Meta counts your purchases twice: where the duplicates come from and how to find them in 15 minutesDuplicate purchases in Meta: four sources (plugin, Pixel, GTM, page refresh), how to count them in Events Manager and fix them in three steps.Read
Get started in under 5 minutes
Connect your shop and Meta and see how many purchases really arrive.
- Free up to 100 orders a month
- No developer needed
- Purchase balance and self-check