How to recover the conversions ad blockers are hiding

Some of your conversions 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. Nobody can tell you exactly how much you are losing — no verifiable industry average exists — and that is precisely the problem: from the inside, the loss is invisible.

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 a first-party, server-side design gets it back.

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 — googletagmanager.com and google-analytics.com sit near the top — 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. Roughly 3 in 10 internet users run an ad blocker (GWI, 2025), and adoption climbs 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. Under Apple's own WebKit policy, cookies set by client-side JavaScript are deleted after 7 days without a return visit — and capped at 24 hours when the visitor lands from a link decorated with tracking parameters (webkit.org).

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 the first-party, server-side design survives

The fix has two halves, because the loss has two halves.

The first half is the money. With PrestaSignal, purchase and refund never depend on the browser at all: when PrestaShop confirms an order, your back office reports the sale server-to-server, through a managed tracking server we run for you. Ad-blockers live in the browser and can only cancel requests that leave it — they have no reach into a call your shop's server makes. The sale is recorded exactly once, and a refund follows with the matching transaction ID so revenue reverses correctly.

The second half is everything else — page views, product views, cart and checkout steps. Those still happen in the browser, but they no longer travel to a third-party analytics domain. The module places a small connector on your shop's own web address, and the browser records events through it — the same domain the shopper is already buying from — with the Google tag libraries served from your domain too. Blockers work from filter lists of known tracking domains: today's lists target Google's domains, and with everything loading from your own address there is no third-party analytics domain on the page for them to match.

That is the structural difference: the everyday events stay on first-party ground, where today's filter lists are not aimed, and the events that pay the bills never touch the browser in the first place. 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 conversions their shoppers’ browsers were blocking become visible again — most of all 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 conversions 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.