The Sale That Gets Counted Twice
Running the pixel and the Conversions API together is the correct setup. The pixel fires from the browser, which is fast but fragile: ad blockers and privacy features drop a chunk of it. The server event fires from your backend, which is durable but blind to some browser context. Together they cover each other. That is the whole point of running both.
The catch is that both channels now report most of your purchases. One real sale generates a pixel report and a server report. Something has to recognize those two reports as the same event and keep one. That something is a shared event ID, sent on both sides. Skip it, mismatch it, or forget it on one channel, and Meta has no way to know the two reports are the same sale, so it counts both.
Without a shared event ID, the pixel report and the server report of one purchase look like two conversions to Meta, and it counts both.
This is not a rare misconfiguration. It is the default outcome of the most common way people bolt CAPI onto an existing pixel: two separate systems, each generating its own events, never told they are describing the same sales.
The Math of a Phantom Conversion
Say you made 100 real purchases this week. Your pixel catches most of them; your server event catches most of them; a large share overlap. Without deduplication, every overlapping sale counts twice. It does not take a high overlap to do real damage.
Run the arithmetic. Spend stays at, say, $2,800. Real conversions are 100, so your true CPA is $28. But Meta reports 140, so the dashboard shows a CPA of $20. You did not get 40% more efficient. You got 40 phantom conversions, and they dragged your reported CPA down by nine dollars a sale that exists only in the count.
The danger is not the vanity number. It is what you do next. You see a $20 CPA, decide the campaign has room, and scale it, pouring budget into performance that was partly imaginary. The double-count does not just misreport the past. It talks you into decisions about the future.
Why It Poisons the Algorithm, Not Just the Report
If double-counting only messed up your reporting, you could mentally discount it. It does worse than that, because Meta's algorithm learns from the conversions it counts. Feed it phantom conversions and it does not know they are phantom. It treats the inflated volume as real signal and works to produce more of it.
Double-counting does not stay in the report; the algorithm treats the inflated volume as real and steers spend toward conversions that do not exist.
So you get the worst of both. Your reporting lies to you, and your ad platform learns from the same lie. The refund problem at least corrupts the signal with real people who really bought. Double-counting corrupts it with people who do not exist at all.
Are You Double-Counting Right Now? A Quick Diagnostic
Most buyers have never checked, because nothing tells them to. Walk the tree honestly.
Four honest questions, and most buyers fall out at the second one: they have never confirmed a shared event ID goes out on both channels.
If you fell out anywhere above the bottom, you are probably reporting conversions you never earned. The good news is that this is the rare tracking problem with a clean, verifiable fix, and confirming it costs you nothing but a test purchase and a look at Events Manager.
Why This Bites Harder in 2026
Two things made double-counting more common right when it got more expensive. First, everyone finally turned CAPI on. The pixel-plus-server setup went from advanced to standard over the last two years, which means far more accounts now have two channels reporting the same sales, and far more chances to skip the shared ID. Second, margins compressed. When you are working on thin CPA differences, a reporting error that shifts your apparent CPA by a quarter is not a rounding issue. It is the difference between scaling a winner and scaling a mirage.
So What Do You Do About It
Before you trust another CPA number, confirm your conversions are counted once. Generate one event ID per sale, send it on the pixel and on the server event, keep the event name identical on both, and verify in Events Manager that they deduplicate. It is an afternoon of work and it protects every budget decision you make afterward.
ClickerVolt fires the pixel and the Conversions API from one layer with a shared event ID by default, so a sale is counted once without you maintaining the key across two systems. See how single-layer tracking keeps the count honest. But even if you never touch it, do the one check this week: pull a real purchase and confirm Meta counted it once, not twice. The most flattering number on your dashboard is the one most worth distrusting.
