Running both the Meta Pixel and Conversions API is the recommended setup, but sending the same conversion from two channels creates an obvious risk: double counting. Meta has a built-in deduplication mechanism for exactly this, and getting it wrong is one of the most common tracking mistakes in accounts that recently added server-side tracking. Understanding how it actually works prevents inflated conversion numbers that make campaigns look better - or worse - than reality.
How Meta's deduplication logic works
Meta deduplicates on two paired fields: event_name and event_id. When the same event_name and event_id combination arrives from both the browser pixel and CAPI within a short window (Meta's documentation cites processing within a matter of minutes, though the dedup window itself is generous, extending to 48 hours), Meta keeps one and discards the duplicate for reporting and optimization purposes.
This means the event_id must be generated once per actual conversion event and passed identically to both the pixel call and the server-side CAPI call. If your website generates one event_id for the pixel fire and your backend generates a different one for the CAPI fire, Meta sees two distinct events and counts both - inflating your Purchase count and skewing ROAS calculations upward in a way that looks great until you reconcile against actual revenue.
Where the event_id should be generated
The event_id needs to originate from a single source of truth that both the client and server can access. For e-commerce, this is almost always the order ID or a UUID generated at the moment of checkout submission, passed to the browser pixel call via JavaScript and to the server-side webhook payload simultaneously.
A common failure pattern: the storefront fires the pixel Purchase event using the browser-generated order confirmation, while a separate backend job fires CAPI hours later using a freshly generated UUID with no relationship to the original. These will never deduplicate. The fix is architectural - the order ID (or a UUID created at the earliest possible point in the transaction) must flow through both paths.
- Generate the event_id at the earliest shared point (checkout submit, form submit, order creation)
- Pass the same event_id to both the client-side pixel event and the server-side CAPI payload
- Use the platform's native order/transaction ID when available rather than inventing a new UUID
- Never let two independent systems generate their own IDs for the same logical event
Testing deduplication before scaling
Meta's Events Manager Test Events tool shows a 'deduplicated events' indicator directly in the event log, flagging when a browser and server event were successfully matched. Before scaling spend on a new CAPI integration, send a handful of real test transactions and confirm each one shows as deduplicated rather than appearing twice in the raw event feed.
It's also worth checking the Diagnostics tab in Events Manager periodically, since Meta surfaces a specific warning when it detects a high volume of events with matching names but no event_id, or with event_id collisions that look unintentional. These warnings are easy to miss but point directly at revenue-distorting bugs.
Beyond Purchase: deduplicating the whole funnel
Deduplication isn't only a Purchase-event problem. Lead, InitiateCheckout, AddToCart, and CompleteRegistration events all benefit from the same treatment whenever both pixel and CAPI fire them. For lead gen funnels specifically, a lead form submission often triggers both a client-side pixel event and a CRM webhook to CAPI - if these use different identifiers, cost-per-lead reporting becomes unreliable exactly when accurate CPL matters most for scaling decisions.
A practical habit: whenever a new event type is added to either the pixel or CAPI side, explicitly check whether the counterpart already fires that event elsewhere in the stack, and if so, wire the shared ID through before turning it on in production.
What good deduplication looks like in practice
In a correctly deduplicated setup, Events Manager's event counts should roughly match your platform's own order or lead counts, adjusted only for legitimate gaps like ad blockers preventing the pixel fire (which CAPI then covers) or delayed webhook processing. If your Meta-reported conversion volume is meaningfully higher than your CRM or order management system's actual count, deduplication is the first thing to audit.
Power Ads configures and validates event deduplication as a standard part of every CAPI build for onboarded accounts, so reported conversions match real revenue rather than an inflated double count.
Key takeaways
- Deduplication matches on the event_name + event_id pair sent from both pixel and CAPI
- The event_id must originate from one shared source, generated at the earliest common point in the transaction
- Test with Meta's Test Events tool to confirm events show as deduplicated, not duplicated
- Apply the same discipline to Lead, AddToCart, and InitiateCheckout events, not just Purchase
- Inflated Meta-reported conversions versus real order/lead counts is the clearest sign of a dedup failure
FAQ
What happens if I don't send an event_id at all?
Meta will attempt fallback deduplication using event_name plus a matching time window and similar parameters, but this is far less reliable than explicit event_id matching and often fails, leading to double-counted conversions.
Can deduplication cause me to lose real conversions?
Only if two genuinely different events accidentally share the same event_id, which would cause Meta to incorrectly treat them as one. This is rare when IDs are generated from unique order or transaction identifiers.
Does the pixel or CAPI event take priority when deduplicated?
Meta generally prioritizes the browser pixel event for matching signal when both arrive close together, but this is an internal processing detail - the reported conversion count either way should be one, not two.
