Imagine running a shop where a third of your customers walk out with their shopping and the till never records it. You’d still be making money. You just wouldn’t know which products were selling, which ads brought people in, or where to spend next month’s budget.
That’s what a lot of ad accounts look like right now.
Where the data goes missing
When someone clicks an ad and buys something, a small piece of code on the website reports it back to Google or Meta. That code runs in the visitor’s browser. That’s the problem.
- Ad blockers stop those scripts from loading at all.
- Safari’s ITP (Intelligent Tracking Prevention) deletes the small files that remember where a visitor came from, sometimes within a day or a week.
- Consent banners and privacy settings cut the signal further.
None of this throws an error. The sale happens, the money arrives, and the ad platform simply never hears about it. So the platform thinks your ads are doing worse than they are, and it learns from an incomplete picture.
How much is missing
The figure you’ll see most often, including from Stape, one of the main companies in this space, is that server-side tracking recovers around 30% more data on average. It varies a lot by audience. A tech-savvy audience full of ad blockers loses more. A site with mostly Android visitors loses less.
I treat 30% as a reasonable industry benchmark, not a promise. But even half of that is too much to leave on the table when every ad platform now uses conversion data to decide who sees your ads next.
What server-side tracking changes
Instead of the browser talking straight to Google and Meta, it talks to a server we control first, on the client’s own domain. That server then passes the data on.
Think of it as moving the till from the shop floor into the back office. Customers can’t knock it over on the way out.
Because the data goes to the client’s own domain, ad blockers are much less likely to stop it. And because the server sets the tracking cookies itself, browsers treat them as the site’s own and let them live longer.
Our setup
For OnDigi’s own site, the tracking server runs on Google Cloud Run using server-side GTM (Google Tag Manager), on our own subdomain. From there it feeds:
- GA4 (Google Analytics 4) for the full picture of what visitors do.
- Google Ads for conversion tracking.
- Meta’s CAPI (Conversions API), which is Meta’s way of receiving data server to server instead of from the browser.
We also use Stape’s add-ons, which fix specific leaks. Click ID Restorer keeps hold of the ID that tells Google which ad someone clicked. Cookie Keeper stops browsers from deleting important cookies early. Custom Loader disguises the tracking script so ad blockers don’t recognise it by name.
We set this up for every client from day one, not as an upgrade later. Retrofitting tracking onto a live account means months of data you can’t compare with what came before.
The part nobody tells you
Getting it working is the easy part. Getting it right took real troubleshooting. On our own setup, the containers disagreed about which environment they were in, and untangling that took a proper debugging session. Server-side tracking is powerful, but it’s another system, and systems need someone who actually checks them.
That’s the whole point, really. Ads can only learn from what actually happened. Our job is to make sure they’re told.