There is a particular kind of tracking problem that feels like good news until you look closer. Meta Ads Manager reports 120 purchases this month. Your store reports 70. Your ad account looks profitable, your cost per purchase looks excellent, and every budget decision you make from those numbers pushes money toward campaigns that are not actually performing that well. The ads are not lying exactly — they are counting many sales twice.
This happens when a business runs both the browser pixel and the Conversions API (CAPI) without deduplication, or when a pixel fires twice on the same page. Meta receives two reports of the same purchase and, unless it is told clearly that they are one event, counts both. The result is inflated revenue, an inflated return on ad spend, and optimisation toward the wrong audiences, because the algorithm is learning from events that never happened twice.
The direct answer: how to stop Meta counting sales twice
Meta stops double-counting when every purchase is sent once from the browser and once from the server with the same event name and the same event ID, so Meta matches the pair and counts it as a single event. Set up deduplication by giving both sources an identical event ID for each purchase, checking Meta’s Test Events tool to confirm events arrive as deduplicated pairs, and removing any duplicate pixel or double-firing tag. Once deduplication is working, reported purchases should match your store’s orders closely, and your ROAS becomes a number you can budget against.
Why double-counting happens in the first place
Most businesses do not set out to double-count. They add CAPI on top of an existing pixel because someone — rightly — told them browser tracking alone is unreliable. Ad blockers, Apple’s privacy prompts and browser restrictions mean the pixel misses real purchases, so server-side tracking recovers them. That advice is correct. The problem is only in how the two sources are joined together.
Meta’s design expects both sources. The browser pixel reports a purchase when the customer lands on the thank-you page. The server reports the same purchase when the order is confirmed in the store system. Meta is supposed to match them using the event ID: a unique code attached to that one purchase, identical on both reports. If the event IDs differ, or if one source sends no event ID at all, Meta has no reliable way to know the two reports describe the same sale, so it counts two.
A second, simpler cause is duplication in the setup itself: the pixel installed twice — once through a plugin and once through Google Tag Manager, for example — or a purchase tag that fires on both the checkout page and the thank-you page. In that case even the browser alone is reporting the sale twice before CAPI is involved at all.
Step 1: Find out whether you are double-counting
Before changing anything, compare three numbers for the same period, ideally the last 30 days: purchases reported in Meta Ads Manager, orders in your store or CRM, and purchase events in Meta Events Manager. Small differences are normal — attribution windows and timing cause some noise. A Meta number 30 to 100 percent higher than real orders, sustained over weeks, is the signature of double-counting, not noise.
Next, open Events Manager and look at the purchase event itself. Meta shows how many events arrived from the browser and how many from the server, and it flags deduplication problems directly. If the event shows a high share of duplicates, or if the server share is close to zero despite CAPI supposedly being live, the setup needs work. This check takes ten minutes and prevents weeks of decisions based on inflated numbers.
Step 2: Give every purchase one shared event ID
Deduplication rests on a single rule: the same purchase, the same event name, the same event ID, from both sources. The event ID is usually the order number, or a unique transaction ID generated at checkout. Whatever you use, it must be identical in the browser event and the server event for that purchase, and unique across purchases — reusing one ID for many orders creates the opposite problem, where real separate sales get collapsed into one.
In practice this means checking, not assuming, that your integration passes the event ID on both sides. Many plugins and tag setups send the purchase value and currency correctly but leave the event ID blank on one side. If you use Google Tag Manager for the browser pixel and a server-side container or plugin for CAPI, both must be configured to read the same transaction ID from the same checkout data. If either side cannot produce it, deduplication cannot work, and that integration needs fixing before anything else.
Step 3: Remove the duplicate firings
While you are in the setup, hunt for the plain duplicates. Check whether the pixel is installed in more than one place: a WordPress plugin, a theme setting, and a Tag Manager container can easily stack up, and each one fires. Check whether the purchase event fires on more than one page, or on a page refresh — a customer refreshing the thank-you page should not create a second purchase. Use the browser’s tag assistant or Meta’s Pixel Helper to watch a test purchase and count how many purchase events actually fire. The correct answer is one browser event per real purchase.
Step 4: Verify with Test Events, then watch for two weeks
Meta’s Test Events tool is the proof, not the configuration screen. Run a real test purchase and watch the events arrive live. A correct setup shows the browser event and the server event arriving as a matched, deduplicated pair — one counted purchase, two sources. If they arrive as two separate counted events, the event IDs do not match, and you now know exactly where to look.
After the fix, do not declare victory on day one. Compare Meta purchases with store orders weekly for at least two weeks, and expect them to move much closer together. A small remaining gap is normal; a persistent large gap means another duplicate source is still firing somewhere, and the hunt continues. Tracking fixes are verified by numbers matching over time, not by a green tick in a setup screen.
Table — Symptom / Likely cause / Fix:
Meta purchases far higher than store orders / Browser + server events without matching event IDs / Same event name + same event ID on both sources
Purchase count jumps after CAPI is added / CAPI added on top of pixel with no deduplication / Configure event ID on both sides, verify in Test Events
Numbers double on some days only / Pixel firing twice, or thank-you page refresh creating a second event / Remove duplicate pixel installs; fire purchase once per order
Meta shows server events near zero / CAPI not actually sending, or sending without event parameters / Check server integration and parameter mapping
Numbers match, then drift apart again / A plugin update or new tag reintroduced a duplicate / Re-check event counts after every plugin or tag change
The checklist before you trust your ROAS again
First, one pixel install only, firing one purchase event per order. Second, CAPI sending the same purchase with the same event name and the same event ID. Third, Test Events showing deduplicated pairs, not two counted events. Fourth, Meta purchases and store orders compared weekly, staying close for at least two weeks. Fifth, a rule that any plugin, theme or tag change triggers a fresh Test Events check. Tracking is not a one-time setup; it is a system that needs re-checking every time the site changes, because every change is a chance for a duplicate to creep back in.
Frequently asked questions
Is some difference between Meta and my store normal? Yes. Attribution windows, refunds, and the timing of when an event is counted all create small gaps. What is not normal is Meta reporting consistently far more purchases than the store fulfilled, week after week.
Will deduplication make my results look worse? It will make them look honest. Reported ROAS usually falls when double-counting is fixed, because the inflated sales disappear. That is not performance getting worse; it is the measurement getting true, and budgets set on true numbers outperform budgets set on inflated ones.
Do I still need CAPI if I fix deduplication? Yes. Without CAPI, browser restrictions and ad blockers mean real purchases go unreported, and Meta optimises on incomplete data. The goal is both sources, correctly matched — not one source alone.
What about other events, like leads or add-to-cart? The same rule applies to every event sent from both sources: same event name, same event ID, or Meta will double-count those too. Fix purchases first, because they drive budgets, then apply the same check to leads and other key events.
How often should I re-check deduplication? After every website, plugin or tag change, and at least once a month as routine. A quarterly check is too slow — a duplicate introduced in January can distort three months of budgets before anyone notices.
The bottom line
A ROAS built on double-counted sales is not a performance metric; it is a trap. It rewards the wrong campaigns, hides the campaigns that actually work, and teaches Meta’s algorithm to chase events that never happened. Fix the event IDs, remove the duplicate firings, prove it in Test Events, and watch the numbers match your store for two weeks. Only then is your ROAS a number worth scaling on.
If your ad account and your bank account disagree, book a free consultation and we will audit your pixel and CAPI setup and show you exactly where the double-counting is coming from.
Related reading: Meta pixel and CAPI tracking setup guide, our services, and the tracking truth guide.