Meta Ads event deduplication: why your conversions are inflated and how to fix it

What is event deduplication in Meta Ads?

When you use both the browser pixel and the Conversions API (CAPI), both can fire the same "Purchase" event for the same sale. Without deduplication, Meta counts two conversions for a single order.

Deduplication is the mechanism that lets Meta recognize that two events arriving through different channels belong to the same transaction, and count it only once.

For it to work, you need to send the same event_id in both events — the browser pixel one and the CAPI one. If the IDs match, Meta deduplicates automatically and counts only one. If they don't, it counts both.

Why are duplicate conversions so common?

Because most e-commerce stores set up CAPI through third-party integrations — Tiendanube's native one, a Shopify plugin, or a tracking tool — while the browser pixel was installed years ago via Google Tag Manager or Meta's code directly.

If the CAPI integration doesn't generate the same event_id as the browser pixel, every purchase produces two events with different IDs. Meta treats them as two separate conversions.

The visible result: your dashboard ROAS looks sky-high. Reported conversions exceed your real sales. And when your agency shows you the numbers, everything looks excellent — until you check your bank account and it doesn't add up.

How do I know if I have duplicate events in Meta?

The diagnosis is straightforward. Go to Meta's Events Manager and find the "Purchase" event. There should be a column showing the percentage of deduplicated events.

• If the deduplication percentage is 0% and you have CAPI turned on, you're probably not sending event_ids — your events aren't being deduplicated, they're being added together.
• If the dashboard shows far more conversions than your real orders, there's duplication.
• If the CAPI conversion rate is similar to the pixel's but with no deduplication, you're double counting.

You can also use Meta's official deduplication documentation to check exactly how event_id is implemented in your case.

How do you set up deduplication correctly?

The technical process has three steps:

• Step 1: Generate a unique event_id per transaction at the moment of purchase — typically a UUID or the order ID.
• Step 2: Send that same event_id in both the browser pixel (via the eventID object in the fbq method) and the CAPI payload.
• Step 3: Check in Events Manager that the deduplication percentage goes up — Meta shows you how many events it deduplicated.

The real problem isn't technical — it's data. For deduplication to work well, you also need to send the full match parameters: the buyer's email, phone, name, city and postal code. That's the data that lets Meta identify the user in both signals and confirm it's the same person.

If you have deduplication turned on but your match parameters are empty or incomplete, your Event Match Quality (EMQ) stays low — and Meta can't build good lookalike audiences or optimize well toward buyers.

Why does deduplication matter beyond the dashboard numbers?

Duplicate events don't just inflate the ROAS you see — they directly affect the quality of what Meta learns about your buyers.

When Meta receives two "Purchase" events for the same order with different customer data (or one with an email and one without), it tries to reconcile them, but if the event_ids are different, it treats them as two different buyers. That pollutes the audience model and degrades the quality of your lookalike audiences.

The practical effect: your prospecting campaigns target noisy profiles, cost per acquisition creeps up, and nobody understands why. The answer is in the quality of the event you send Meta — not in the budget or the creative.

What about server-side tracking and deduplication?

Server-side tracking doesn't remove the need to deduplicate — it makes it more critical. When you send events from your server, you have more control over what data goes into the payload, which is an advantage. But if you also have the browser pixel running, you still need to deduplicate.

The difference with server-side is that you can make sure the event_id is generated on the server and passed to the browser pixel via the fbq object before it fires — something much harder to do reliably with client-side-only tracking.

The Escalafy server-side pixel handles deduplication automatically: it generates a unique event_id per order, sends it on both channels, and makes sure the match parameters — email, phone, name, city, postal code — are present on every event. The result isn't just fewer duplicates: it's richer events Meta can use to better identify each buyer.