How to recover the conversions ad blockers are hiding

Somewhere between a quarter and half of your conversions may never reach your analytics — not because the sales did not happen, but because the customer's browser refused to report them. Ad-blockers, privacy extensions, and Apple's tracking restrictions silently cancel the requests that carry your tracking events.

The frustrating part is how invisible it is. The order lands in your PrestaShop back office, the money hits your account, but GA4, Google Ads, and Meta never hear about it. You are optimising campaigns and judging your store against numbers that are missing a large, biased chunk of reality. Here is exactly how the loss happens, and how to recover it.

How blockers cancel your events

Classic tracking is client-side: a script in the shopper's browser fires events like page_view and purchase to Google or Meta. Ad-blockers and privacy extensions maintain blocklists of analytics and advertising domains, and they cancel any request heading to one of them before it leaves the browser.

From your side this is completely silent. There is no error, no warning, no entry anywhere — the event simply never existed as far as your analytics is concerned. Blocking rates of ~30% are common across general audiences, and they climb higher among younger, more technical, and more privacy-aware shoppers.

Because adoption skews toward exactly the audiences many stores want most, the loss is not random noise you can shrug off. It is a systematic, biased hole in your data that distorts which campaigns and segments look profitable.

ITP and the cookie expiry problem

Ad-blockers are only half the story. Apple's Intelligent Tracking Prevention (ITP), built into Safari and iOS, attacks the cookies that tracking depends on. ITP caps the lifetime of cookies set by client-side JavaScript — sometimes to as little as 24 hours or 7 days.

The effect is subtle but corrosive. A shopper who clicks an ad today and buys next week returns with their tracking cookie already expired, so they look like a brand-new, unattributed visitor. The sale may still register, but stripped of the campaign that earned it. Multiply that across a mobile-heavy customer base and a huge share of your attribution quietly evaporates.

App Tracking Transparency compounds this by cutting off cross-app and cross-site signals, hitting Meta especially hard. Our glossary defines ITP, ATT, and the rest of these terms in plain language.

Why server-side tracking bypasses them

Server-side tracking changes where the event originates. Instead of asking the browser to report a conversion to Google or Meta, your store's server sends the event directly, server-to-server, through a self-hosted sGTM container.

Ad-blockers and privacy extensions live in the browser. They can only cancel requests that leave the browser — they have no reach into a server-to-server call your backend makes. ITP governs browser cookies, so a conversion sent from your server, anchored to the order itself rather than a fragile cookie, is unaffected.

This is the structural reason server-side tracking recovers what client-side loses: it moves the most important events out of the one place — the browser — where they are most likely to be blocked. See server-side vs client-side for the full comparison, or how it works on PrestaShop specifically.

What recovery actually looks like

When merchants move purchase tracking server-side, the typical recovery is in the range of 30-50% of previously missing conversions — sometimes more for audiences heavy on iOS or ad-blocker use. That is not a vanity bump in a dashboard; it is real sales becoming visible to the systems that spend your money.

The knock-on effects matter more than the headline number. Google's Smart Bidding and Meta's optimisation both learn from conversion data. Feed them the recovered 30-50% and they finally see the true value of each click and audience, stop underbidding on quietly profitable campaigns, and reallocate budget toward what actually works.

Your reporting also snaps back to reality: conversion rates stop looking artificially low, ROAS stops looking artificially poor, and GA4 revenue starts lining up with the money in your bank.

Recovery is not a loophole

It is worth being clear about what server-side tracking is and is not. It is not a trick to track people who declined consent, and it is not a way around privacy law. The events still respect consent signals, and personal data is normalised and hashed with SHA-256 before it ever leaves your store.

What server-side tracking fixes is a technical delivery failure: legitimate, consented conversions that the browser dropped for reasons that have nothing to do with the customer's wishes. A shopper whose order failed to report because their tab closed or their network dropped did not opt out of anything.

Run properly, with consent respected and a banner and policy in place, server-side tracking is simply a more reliable pipe for the data you are already entitled to collect. If you want your own loss measured against real orders, book a teardown.