Your Meta purchases are probably counted twice. Here is the 10-minute check.

If you turned on the Conversions APIiConversions API Meta's server-to-server channel for sending events like leads and purchases from your own server or CRM, instead of relying on the browser pixel. Usually run alongside the pixel, which is where double counting comes from. because Meta’s account rep said to, and you did not change anything else, there is a good chance your Purchase count in Ads ManageriAds Manager Meta's interface for building campaigns and reading their results. Its numbers reflect Meta's attribution rules, not your bank account. is inflated. Sometimes by a little. On one account I took over, by almost exactly 2x, which is the tell.

The reason is simple. The browser pixeliMeta pixel A small piece of code on your website that reports visits and actions (page views, leads, purchases) back to Meta from the visitor's browser. Blocked by ad blockers and some browser privacy settings. fires a Purchase. The server sends a Purchase. Meta only knows they are the same purchase if you tell it.

How Meta decides two events are one

Meta deduplicates on two fields: event_name and event_id. If a browser event and a server event arrive with the same name and the same ID within a short window, one is kept and the other is discarded. Nothing else does this job.

Matching emails, phone numbers, the fbp cookieiCookie A small file a website stores in your browser to recognize you on later visits. Ad tracking depends on them, and browsers and privacy laws increasingly limit them., the order value: none of those trigger deduplicationiDeduplication Matching a browser pixel event and a server event that describe the same action, using a shared event ID, so the platform counts it once instead of twice. on their own (Watsspace, Meta CAPI deduplication). The official reference is Meta’s developer documentation on deduplicating pixel and server events, which sits behind a developer login.

So the whole thing hinges on one question: does your site generate one ID per purchase and send that same ID both ways?

Common ways it goes wrong:

• The pixel sends eventID (camel case, in the browser SDK) and the server sends event_id (snake case, in the API). Those are the same field. Sending one and not the other means no match.
• The browser generates a random ID on the fly, the server uses the order number. Both are valid IDs. They will never be equal.
• The server event fires from a webhook minutes or hours after the browser event, outside the window Meta will match in.
• The server event is missing action_source: "website", which is required for web deduplication to apply.

The 10-minute check

1. Open Events ManageriEvents Manager Meta's dashboard for seeing which events the pixel and Conversions API are sending, how many arrived, and whether they were deduplicated., pick your pixel, open the Purchase event.
2. Look at the breakdown by connection method. You should see events arriving from both Browser and Server.
3. Open the event details and look for the deduplication section. A healthy setup shows server events being matched to browser events by event_id. An unhealthy one shows both arriving and no deduplication, or a deduplication rate far below your overlap.
4. Now do the reconciliationiReconciliation Comparing what the ad platforms say they delivered against what actually happened in your CRM or payment system, and working out where the difference comes from. that settles it: pull last month’s real purchase count from Shopify, Stripe or the CRMiCRM Customer relationship management software, such as HubSpot or Salesforce, where leads, contacts and deals are recorded. Usually the only system that knows whether a lead was real., and compare it to the Purchase count in Ads Manager for the same period with attributioniAttribution The rules for deciding which ad, click or channel gets credit for a sale or lead. Every tool uses different rules, so the same sale can be credited to Google in one report and Meta in another. set to the widest window. If Ads Manager is reporting more purchases than you actually had, you are double counting.

What to fix

Generate the ID once, at the moment of purchase, and hand it to both sides. On Shopify that is usually the order ID. On a custom checkout, generate a UUID when the order is created and store it with the order so the server event can use it later.

If you run the server side through a Google Tag ManageriGoogle Tag Manager Google's free tool for managing all the tracking snippets (tags) on a website in one place, so you can add or change tracking without editing the site's code. server container, the container can forward the browser event to Meta as the server event, which guarantees the ID matches because it is literally the same event. That is the cleanest pattern I know and it is the one I set up by default.

Then re-run step 4 the following month. The dedup panel in Events Manager tells you the mechanism is working. The reconciliation tells you the number is right. You want both.

Why this matters more than it looks

Double-counted purchases do not just flatter the dashboard. Meta’s bidding optimizes toward the events it receives. If every purchase looks like two, the algorithm is learning from a distorted signal, and your cost per purchase in Ads Manager is half of what it really is.

Every budget decision built on that number is wrong in the same direction. Fixing the ID is ten minutes of work that changes what “good” looks like across the whole account.