Meta Conversions API and deduplication, without the jargon

Meta recommends sending your conversions twice: once from the visitor’s browser through the pixel, and once from a server through the Conversions API (CAPI). Done well, this gives Meta a more complete picture of who bought. Done badly, it counts every sale twice and teaches Meta’s bidding system that your ads work better than they do.

This guide explains how a Meta CAPI setup connects to the pixel, what deduplication is, and how to check yours.

Pixel and CAPI, side by side

The Meta pixel is a script on your store. When a visitor buys, it sends a Purchase event from their browser to Meta, along with the browser cookies Meta uses to recognize them. It is quick to set up, but it misses events when scripts are blocked, when the browser limits cookies, or when the visitor leaves before the thank-you page finishes loading.

The Conversions API sends events from a server instead. That might be Shopify’s own servers (through the Facebook & Instagram app), a server-side Tag Manager container you run, or another app or platform. Server events are not affected by ad blockers in the same way, and they can carry customer details from the order that the browser never had.

Running both is called a redundant setup. Meta receives two copies of each purchase and keeps one.

How deduplication works

For Meta to know that a browser Purchase and a server Purchase are the same sale, both copies must carry two matching values:

• the same event name, such as Purchase
• the same event ID, sent as eventID with the pixel and event_id with CAPI

When both arrive with matching values within Meta’s deduplication window (48 hours at the time of writing), Meta keeps one and discards the other. The usual choice for the event ID on a purchase is the order ID, because both the browser and the server know it.

For example, if order #1042 triggers a pixel event with eventID: "1042" and a CAPI event with event_id: "1042", Meta counts one purchase. If the pixel sends "1042" and the server sends "gid://shopify/Order/5551234", Meta sees two different purchases.

Deduplication only works when both sides agree on the ID format. “Order 1042”, “#1042” and “1042” are three different IDs to Meta.

Meta also offers a fallback method using external_id or the browser ID (fbp), but the event ID approach is the one to rely on.

Where double counting comes from

These are the patterns we look for first when Meta reports more purchases than the store took.

Two sources sending the same event. The Facebook & Instagram app is sending pixel and CAPI events, and a GTM container or a custom pixel added by a past agency is also sending Purchase. The app’s events deduplicate with each other. The extra ones do not.

Mismatched IDs. The browser uses the order number and the server uses the internal order ID, or one side adds a prefix. Every purchase arrives twice.

No ID on one side. The pixel event has no eventID at all, often because it was added by hand years ago. Meta has nothing to match.

Thank-you page reloads. A visitor revisits the order status page from their confirmation email, and an old theme script fires Purchase again. Using a stable order-based ID helps, because the repeat then deduplicates.

Two pixels. Some stores run two pixel IDs, one from an old ad account or agency. Each pixel counts its own purchases, and reports that combine them show double.

Event match quality and what feeds it

Deduplication stops overcounting. Event match quality (EMQ) is about the other problem: how well Meta can connect each event to a real person on its platforms. Events Manager scores it for each server event type on a scale out of 10.

Higher scores come from sending more of the customer details Meta can match on, when you have consent to share them:

Shopify’s Meta integration fills in many of these from the order. Custom server setups often forget fbc and fbp, which hurts matching even when email is present. A low score does not mean events are lost. It means Meta is less sure who they belong to, so it optimizes with less confidence.

Only send customer details when the visitor’s consent allows it. A server path does not change the consent rules. Our guide to server-side tagging covers how consent carries through to the server.

How to check yours in Events Manager

You need admin access to the pixel (Meta calls it a dataset) in Events Manager.

1. Look at the Purchase event’s sources

Open the dataset, find Purchase in the overview and open its details. It should show events received from both the browser and the server. The detail view also reports whether events are being deduplicated and how many server events have a matching browser event. If you only see one source, you are not running a redundant setup. If you see both but deduplication shows nothing, the IDs are not matching.

2. Run a test purchase with Test Events

In the Test Events tab, open your store through the test link and buy something you can refund. You should see one browser Purchase and one server Purchase with the same event ID, and Meta should mark them as deduplicated. Two browser purchases point to a second pixel or a duplicate tag.

3. Compare with your store

Take a recent week and compare Meta’s purchase count for the pixel (not just one campaign) with your store’s order count for the same days and time zone. Meta can report fewer, because some buyers never touched an ad. If it reports noticeably more, you likely have duplicates.

4. Read the Diagnostics tab

Events Manager lists problems it has noticed, such as missing parameters, low match quality or events with mismatched IDs. Treat it as a to-do list, highest impact first.

What to do next

Run the test purchase in step 2 this week and note how many Purchase events arrive and whether they share an ID. If you see more than two, or two that are not deduplicated, send your store URL through our free tracking check and we will tell you where the extra events come from. To have CAPI set up with matching IDs, consent-aware customer data and a full test plan, see our Tracking Implementation service.