If you are running Facebook or Google ads and you are still using the browser pixel to track performance, you are losing anywhere between 30 and 80 percent of your data.
This means that 3 to 8 out of 10 conversions never reach Facebook or Google.
Which is why their algorithms can't find your ideal customers and help your campaigns scale.
So what is actually going on?
The answer is browser tracking is dying.
The install that worked fine five years ago is the install bleeding the most money today.
How does browser tracking actually work?
The pixel is browser-side. That means the code does not run on your server. It runs in your customer's browser, on their device, the moment they land on your site.
That single fact is what's killing it.
When the tracking code runs inside someone else's browser, the browser gets the final say on what happens to it. The browser can read it. The browser can block it. The browser can rewrite the URL before the request even goes out.
And browsers started choosing to block it.
Safari blocks aggressively through Intelligent Tracking Prevention. Firefox blocks it through Enhanced Tracking Protection. Brave blocks it by default.
Chrome is the most flexible of the four, because Google runs its own ad business on Chrome, but even Chrome is drifting the same direction over time.
On top of the browsers themselves, you have ad blockers. The major ad blockers know exactly how the Facebook pixel loads. They know exactly how the Google tag loads.
The script URLs, the request signatures, the cookie names. They block the request before the tracking even starts.
Ad blocker penetration sits around 25 to 30 percent of internet users globally, and it skews higher on the tech-aware, higher-income audiences ecom advertisers tend to attract.
Stack that on Safari, Firefox, and Brave, and you land at the 30 to 80 percent loss range depending on how Apple-heavy your audience is.
What this actually costs you
Here is what the gap looks like in practice.
You run an ad and Ads Manager reports 100 clicks. Only 50 of those clicks actually register a landing page view on your side. The other 50 never fired the pixel.
You make 20 sales on the backend. Five of them show up as purchases in the Facebook dashboard.
You cannot make a scaling decision off that data. You cannot tell whether the campaign worked or did not. You cannot tell whether the ad set is fatigued or whether it is just under-reported.
That is the surface-level cost.
The deeper cost is that the algorithm cannot learn. Facebook and Google use the conversions you send them to figure out who your real customers are.
When you ship 25 percent of the actual buyers, the algorithm builds its picture of "your customer" from a small sample of whoever happened to use a privacy-friendly stack that day.
The targeting drifts. CPMs rise. ROAS goes down.
The Safari piece is about to get worse
And if you think all of this is bad, it gets even worse.
Apple built link tracking protection which strips the click ID from the URL.
When a prospect clicks your ad, Facebook and Google append a click ID in the URL. That's how they know from which ad your customer came and they use it to optimize their algorithm.
Well, Apple started stripping that parameter from the URL which blinds Facebook and Google.
They're currently doing it by default in private browsing, but there's a manual toggle in Settings that does the same thing in normal browsing.
The default in regular browsing has not been flipped yet. Apple has built it, tested it, and shipped pieces of it. They are one decision away from making it default everywhere.
The day they flip that switch, every Safari conversion lands in your Ads Manager as an organic sale.
No click ID, no attribution back to the ad, no signal back to the algorithm.
The solution is server-side
Every ad platform has a server-side option now, because every platform sees the same decay you do.
On Facebook, the server-side option is the Conversions API, usually shortened to CAPI. It fires from your server, where ad blockers and browser policies cannot touch it.
The events arrive complete, with the click ID, the hashed customer data, the purchase value calculated on your backend instead of hardcoded into a snippet.
Facebook's official recommendation is to run both. The browser pixel AND the Conversions API, sending the same event in parallel, deduplicated server-side with a shared event_id.
In Facebook's own developer documentation, verbatim:
"For optimal ad performance, we recommend that advertisers implement the Conversions API alongside their Meta Pixel. We call this a 'redundant setup'..."
Facebook re-affirmed that guidance formally on April 15, 2026.
The practical reality is that the browser half of that redundant setup is the half being blocked.
So even when you run both, the server side is what is actually carrying the load. The pixel becomes the backup, the way Facebook intended.
You can run both for redundancy. You can also run server-side only and the algorithm will still optimize.
The thing you cannot do anymore is run browser only and expect the algorithm to see your customers.
Google does not work the same way
Here is where most advertisers, and most of the freelancers they hire, get it wrong.
Google Ads is built on the opposite model. There is no event_id dedup on Google Ads conversions.
The setup is either/or. Either you fire the conversion through the browser tag, or you fire it through the server-side tag. Not both for the same event.
That is in Google's own server-side tagging documentation, verbatim:
"Once your Google Ads Conversion Tracking tag works as intended, you can remove any equivalent Ads Conversion Tracking tags in a web container to avoid data duplication."
Remove the browser tag once the server tag is working. Google says it directly.
When both fire, Google does not transparently merge them. Reported conversions get inflated. Smart Bidding trains on the inflated number.
The campaign looks like it is winning, and meanwhile your real cost per acquisition is climbing, because the algorithm is bidding more aggressively on what it thinks is converting at twice the real rate.
Most advertisers never get past the browser tag on Google. They install the conversion snippet, hit a 30 to 60 percent block rate just like on Facebook, and never wire up server-side at all.
The ones who do wire up server-side often leave the browser tag firing too, because nobody told them Google works the opposite of Facebook.
What this all comes back to
Browser tracking is dying. The browsers turned on it.
The privacy stack turned on it. The platforms themselves stopped relying on it.
The pixel was never built for the web you are running ads on today.
The install most advertisers run was written for a web where the browser was a neutral party. That web does not exist anymore.
The fix is server-side. Run CAPI on Facebook. Pick one path on Google.
And stop assuming the install guide from two years ago is the install guide that works.
If wiring this up correctly across both Meta and Google sounds like more than you want to take on, TrueMetriks does it automatically.
It sets up CAPI for Facebook and the right server-side path for Google, with no developer required.
