Ad blockers: some conversions never reach Google, and the ads learn without them

What is wrong

Some visitors arrive with an ad blocker or with tracking protection in the browser. For them the purchase data never reaches Google: the tag does not load, or the request never leaves the browser.

Example. The booking system shows 100 bookings, GA4 (Google's analytics) shows 90. The difference is the visitors with blockers. Their bookings are real; for Google they never happened.

Why this is money. Google Ads and Meta bid on the conversions (purchases and leads) they can see. The more specific the business, the more each conversion is worth for learning. Visitors with blockers are particular browsers, devices and habits, so the ads learn from a skewed sample and move the budget towards where purchases are visible. The visitor may well be fine with training the ads: they installed the blocker to see fewer pop-ups.

Reports understate the return. Uncounted revenue means an understated return on ad spend (ROAS), and the budget gets cut in campaigns that work.
Nobody knows where it was lost. Comparing "100 against 90" does not say at which step the data disappeared: in the browser, on the way, or when Google counted it.

Ways to close the gap

Every visitor action (a page view, a click, a booking) is sent to Google by the site as an event. There are three options, and they form a ladder: each step closes what the one before it left open.

1) Leave it as it is

Events go straight to Google's addresses. Zero infrastructure, zero cost. Blockers know those addresses, and everything they stop disappears without a trace: you know neither how much was lost nor at which step.

In the demo: the Classic GTM toggle.

2) A server-side Tag Manager

Events go to your own address, and on to Google from there. Blocker rules written against Google's addresses do not apply to them. Two ways to get one.

Hosted by a vendor (Stape and the like) on your subdomain. Quick to start, with loader and endpoint paths already chosen for you. Downsides: the container answers from someone else's address, there is a monthly fee, and the traffic passes through the vendor's servers.

Your own, on your own domain, at the same address as the site. Events and cookies come from your own address, the container is Google's official image, and the data passes through you. Downsides: your own server and its upkeep. And the loader's file name matters: a public list rule catches the path /gtm.js on any domain, including yours.

The size of the loss becomes visible along the way. Every event gets a receipt, so you can see whether it reached your server: which one was lost and at which step. And the verdict on whether the direct road to Google was open travels into analytics along the same server road, the one the blocker does not cut – so the share of blocked visitors shows up in a report as a number.

What this step does not give you: a guarantee. Lists change, and a rule on the endpoint path would stop both roads. How much the server road helps under a given blocker has to be measured.

In the demo.

3) A confirmed booking from your own system, straight to the ads

The only step that does not depend on the browser at all. The ad platform receives the confirmed booking even when the visitor's browser sent nothing.

How it works. The visitor arrives from an ad at an address like site.com/tour?gclid=ABC123 – the click identifier sits right there in the page address. That request reaches your server before a single line of code runs in the browser, and there is nothing for a blocker to cut. Your server remembers the identifier, and once the booking is confirmed and paid it sends the conversion to the ad platform from its own side. Google Ads accepts conversions by click identifier or by the customer's email and phone in encrypted form; Meta and Yandex work in a similar way.

What you get beyond the recovered losses. A browser sends the purchase the moment the thank-you page is shown. A server sends it when the money has actually arrived, and stays silent when the booking is cancelled. The ads learn from confirmed money.

What it needs from your side. The booking record has to have a field for the click identifier. If the form is on your site and the server behind it is yours, the browser attaches the identifier to the form submission by itself, because the domain is the same – all that is left is to store it next to the date and the amount. If the booking is made on an external platform, you either create the booking through its API from your own side, or pass the identifier into the address of its widget and the platform sends it back to you with the booking notification. A consent basis is needed separately: for visitors from the EU, the UK and Switzerland you cannot send anything without their consent.

Planned.

What the demo does

Every event leaves the browser twice: straight to Google, and through our server container on the site's own domain. The server container confirms every event, and a separate probe once per page checks whether the direct road to Google is open from this browser. The panel shows for every event which road worked. Server-side tagging does not remove consent: in the opt-in regime (EU, UK, CH) nothing loads before consent, and both roads wait.

Open the demo

The demo opens on the Events tab with server-side transport already selected. Use a private window for a clean run, because the regime and the transport stick in the browser.

Consent regimeAUTOAuto – the regime follows your locationUSForce US – opt-outEUForce EU – opt-in

Count the visit as

Open the demoLink the demo opens with

https://alpha.nexusnode.ru/?utm_source=GAds&utm_medium=CPC&utm_campaign=case_server_side&demo_click_id=GADS-11111&al_case=server-side-delivery&al_lang=en&al_transport=server&al_tab=events&al_regime=auto

Direct links, with Google Ads as the source:

Auto – the regime follows your location

Force US – opt-out

Force EU – opt-in

What you will see without a blocker:

The strip at the top of the Events tab: Direct path: reachable · Server path: 2/2 received · Loader: alpha.nexusnode.ru/gtm/loader.js · Lost on the direct road: none. The direct road is open, the server road delivered two events out of two, the container came from our own domain, nothing was lost.
Three chips on every event. reachable on the direct road means the request left the browser; there is no witness on Google's side, and the panel says so. received on the server road means the server container confirmed exactly this event. tag fired means the tag on the page really sent the event – so you can tell an event lost on the way from one that was never sent. Hover a chip to read what the value means.
Switch to Classic GTM in the top right and reset. The loader now comes from www.googletagmanager.com and the cookie is written by a script. The Data tab lists every key with who set it.

Try it on yourself

If you do not run a blocker, install any of the common ones – uBlock Origin or uBlock Origin Lite, AdGuard, Brave's built-in shields, Firefox strict tracking protection – and open the link above again in a private window. In the strip at the top the direct road turns to blocked while the server road stays received, and the loss chip shows how many events were cut on the direct road and how many of them the server still delivered: Lost on the direct road: 2/2 · saved by the server: 2/2. Those are exactly the events that would be missing from your analytics.

An honest word on the limits: what matters is not the name of the blocker but the rule list it has enabled. A rule on the endpoint path for any domain stops both roads, and such lists exist. Our measurement: default uBlock Origin Lite lists on [DATE] – direct blocked, server received from our own domain. The measurement is repeated after every change to the demo.

What the demo does not prove

That Google counted the event. reachable means the request left the browser. The proof is the count in the GA4 property, and it arrives with GA4's own delay.
That every blocker is handled. A list rule on the path /g/collect for any domain stops both roads. Custom loader and endpoint paths are what hosted services add; this demo does not build them.
That a delivered event is a counted conversion. Loader, collection endpoint, event quality and the destination platform are four separate checks.
How long the identifier lives in each browser. That is a separate test.

Who built this

Anton Kozhanov – marketing data and attribution engineer. Own server-side Tag Manager on own infrastructure, a first-party loader and cookies, a journey vault with export and deletion. Four years on a theatre's measurement (revenue ×2.3 on his watch, ad spend held near 7% of revenue) and a call-tracking → CRM → ads feedback pipeline for a manufacturer (cost per lead −25%, a 2.5-year low).

Book a call

Bring your website and the discrepancy you cannot explain. We trace one event through your setup and decide what is worth fixing first. If you walked through the demo, I open your journey record on the call: which events took which road, and what came back.