Meta event deduplication, how pixel and CAPI avoid double counting

Meta event deduplication is how Meta recognises that a browser event sent by the Pixel and a server event sent by the Conversions API describe the same purchase, and counts that purchase once instead of twice. It is not a switch you turn on. It works only when both copies carry the same event_name and the same event_id, and arrive close enough together to be paired. When one half of that pair drifts, nothing fails loudly. Your reporting simply starts showing more purchases than your store recorded, and every metric built on that count inflates with it.

This article is about that failure mode, not about installation. If you are still wiring up the server connection, finish that first. If you are wondering why a server copy is needed at all, browser events became unreliable once app tracking permission changed how much the Pixel can observe, which is the subject of our piece on iOS 14 and Facebook ads.

How Meta event deduplication pairs two copies of one action

Two conditions, both mandatory. First, event_name has to be identical. Purchase from the browser and purchase written in a different case from the server are two separate events to the matching logic, and a custom name such as PurchaseServer will never pair with the standard one. Second, event_id has to be the same string in both copies. Not equivalent, not derived from the same order, the same string.

That second condition is where most implementations quietly fail, because the two systems usually hold different natural identifiers for the same order. Your theme may have access to the order name the customer sees on the receipt, while the server integration sends the internal numeric order id. Both are legitimate identifiers. Neither matches the other, so Meta receives two purchases and has no basis for treating them as one.

Meta also documents an alternative pairing route for certain events using the browser cookie identifier, and it defines a limited window inside which both copies must arrive to be matched. Those rules get revised, so read the current version in Meta's official Conversions API documentation rather than trusting a figure quoted in any article, this one included.

Choosing an event_id that will not break

A usable event_id has three properties: it exists on both sides, it is stable, and it is unique per event rather than per person. An order id normally satisfies all three. A timestamp generated independently in the browser and on the server satisfies none, because the two clocks will never agree to the millisecond. A session id is unique per visit rather than per purchase, so a customer who buys twice in one session gets collapsed into a single event.

There is a nuance worth internalising here. The id has to be unique per event, not per page load. If your confirmation page reloads and the browser event fires again carrying the same id, deduplication is working in your favour and the repeat is discarded. If that page generates a fresh random id on every load, you have manufactured a duplicate that no logic downstream can undo.

Reading the deduplication signal in Events Manager

Open Events Manager, select the dataset, and look at the row for your Purchase event. Meta shows which connection methods contributed to it: browser, server, or both. Both is the state you are aiming for. Server only, after you installed a browser pixel, usually means the browser copy is being blocked or is not firing. Browser only means the server integration is not reaching this dataset at all.

Redundancy surfaces in the event detail view and in the Diagnostics tab. Meta raises a diagnostic when it believes it received duplicate events it could not merge, and the event detail shows the parameters actually received, which is the only reliable way to confirm that event_id arrived rather than being dropped somewhere in your integration. Labels in this interface change over time, so confirm the current naming in Meta's own documentation before concluding that a field is missing.

Two habits make the panel readable. Use the Test Events tool with a real checkout and watch both copies land with your own eyes. Then compare a fixed window, one week, between your store admin and Events Manager with both set to the same time zone.

What a week of double counting actually costs

Numbers make the stakes concrete. Say your store admin shows 120 orders for the week and revenue of 240,000 TL, an average order value of 240,000 ÷ 120 = 2,000 TL. Say half of those orders, 60 of them, fire an unpaired browser event alongside the server event. Events Manager then records 120 + 60 = 180 purchases, which means 60 ÷ 180 = 33.3% of the recorded purchase events are duplicates.

Revenue follows the count. Those 60 duplicated events add another 60 × 2,000 = 120,000 TL, so the reported revenue becomes 240,000 + 120,000 = 360,000 TL. Against 60,000 TL of spend, the reported return is 360,000 ÷ 60,000 = 6 while the real return is 240,000 ÷ 60,000 = 4. The reported figure is 6 ÷ 4 = 1.5 times the true one. Cost per purchase bends the same way: 60,000 ÷ 180 = about 333 TL reported, against 60,000 ÷ 120 = 500 TL actually paid.

If your target return sits between those two numbers, they point in opposite directions: one says scale, the other says pull back. Rerun your own version on the deduplicated count with a ROAS calculator before you touch budgets. Reporting is not the only casualty either. Bidding systems and AI targeting layers optimise toward the events they receive, so a duplicated purchase stream teaches them that the wrong sessions and the wrong audiences convert.

Where dedup goes quiet after a theme or app change

Nothing turns red on either dashboard when this breaks, which is exactly why it survives for months. The recurring causes are all deployments:

• A theme update overwrote the snippet. The pixel call still fires, but the optional argument that carried the event id was not in the new template, so the browser copy now arrives with no id.
• A checkout migration moved the confirmation step. The variable that used to hold the order id does not resolve on the new page and silently resolves to an empty string.
• A second app began firing the same event. Three Purchase events now exist for one order. Meta can merge the matched pair and still leave you with an extra.
• The two sides landed in different datasets. Pairing only happens inside one dataset, so a browser pixel pointing at one id and a server integration pointing at another will never meet.
• Someone renamed the event. A rebuild that turned Purchase into a custom event breaks the name half of the match while every dashboard still looks like it is tracking.

Because all five are triggered by releases rather than by gradual drift, tie the check to the release. Any theme change, app installation or checkout change earns one test purchase and one confirmation that both copies still share an id.

A check you can finish in ten minutes

• Pick one recent real order and note its identifier in the store admin.
• Find that order's Purchase events in Events Manager and compare event_name and event_id character for character across the browser and the server copy.
• Count store orders against reported purchases for the same seven days in the same time zone, and write the gap down.
• Repeat that count after any release touching the theme, the checkout or an app.

One caveat before you start chasing a perfect match. Deduplication removes duplicate events; it does not make Meta and your analytics tool agree. Those two systems count with different attribution logic and different timestamps, which is a separate subject covered in multi touch attribution. Clear the duplicates first, then judge whatever gap remains. A gap you can explain is a working setup. A gap you cannot explain is your next investigation.