Ad Blockers and Conversion Tracking: What Actually Gets Blocked (and How to Get the Data Back)

The short answer: Ad blockers break conversion tracking by blocking the browser requests that pixels like the Meta Pixel and Google tag depend on, hiding roughly a quarter to a third of conversions from your ad platforms. The fix is server side conversion tracking, which sends events from your server, so there is no browser request to block.

Every guide on this topic says the same two things: ad blockers are common, and server-side tracking is the answer. Both are true. But most of those guides are fuzzy about what an ad blocker actually blocks, which matters, because the popular workarounds fail for reasons you can only see at the request level. This post gets specific: what gets blocked, what survives, how to measure the damage on your own site, and what a real fix looks like.

The scale of the problem, briefly

Roughly one in three internet users runs some form of ad blocking, and the share climbs close to half among 16 to 24 year olds. In the US, blocking skews heavily toward desktop, where uptake runs more than double the mobile rate. If your audience is technical (developers, IT, marketers themselves), assume well above average.

Here is the part that matters for your reports: those users still buy things. They click ads in places blockers cannot reach, they convert on your site, and the pixel that was supposed to report the sale never fires. Your platform dashboards do not show an error. They just show fewer conversions than you actually got, and every downstream decision inherits the gap. We covered the full landscape of leakage in why you’re losing conversion data; this post drills into the ad blocker slice specifically.

How ad blockers actually block tracking

An ad blocker is a request firewall. Extensions like uBlock Origin and AdBlock Plus sit inside the browser and check every outgoing network request against filter lists, community-maintained catalogs of URL patterns. The two lists that matter here are EasyList, which targets ads, and EasyPrivacy, which targets analytics and tracking endpoints. When your checkout page tries to call facebook.com/tr or googleads.g.doubleclick.net, the request matches a filter and dies before it leaves the browser. In Chrome DevTools it shows up as ERR_BLOCKED_BY_CLIENT. The page works fine. The signal is simply gone.

One detail almost nobody mentions: the default lists differ by blocker. uBlock Origin ships with EasyPrivacy enabled, so it kills tracking pixels out of the box. AdBlock Plus ships with it disabled, so plenty of AdBlock Plus users block your ads but still fire your pixels. “Ad blocker user” is not one population, which is why generic loss estimates vary so widely.

It is also worth separating ad blockers from the browser-level privacy features they get lumped in with. Safari’s ITP and Firefox’s tracking protection mostly attack cookies and storage, which degrades attribution: the event arrives but loses its connection to the click. An ad blocker erases the event entirely. Different failure mode, different fix, and a diagnosis that confuses the two usually ends with someone buying the wrong solution. Some browsers and blockers also strip click IDs like gclid and fbclid from URLs on arrival, which means even a surviving pixel can report a conversion the platform cannot match to a click.

What gets blocked on a typical site

Tag	Typical blocked endpoint	Blocked by default filter lists?
Meta Pixel	connect.facebook.net, facebook.com/tr	Yes (EasyPrivacy)
Google Ads conversion tag	googleadservices.com, googleads.g.doubleclick.net	Yes
GA4	googletagmanager.com, google-analytics.com	Yes (EasyPrivacy)
TikTok Pixel	analytics.tiktok.com	Yes
LinkedIn Insight Tag	snap.licdn.com, px.ads.linkedin.com	Yes
Microsoft Ads UET	bat.bing.com	Yes
First-party server-side endpoint on your own domain	yourdomain.com/collect	Rarely
Server-to-server Conversions API call	never leaves your server	Never

The last two rows are the entire story of the fix, and we will get there. First, the misconception that keeps marketers from taking this seriously.

The blocked-ad paradox: they never saw my ad, so who cares?

The comfortable objection goes: if someone blocks ads, they never saw the ad, so there is no conversion to miss. That logic holds on desktop display and not much else.

Browser ad blockers live in the browser. They cannot touch the Instagram app, the TikTok app, the Facebook app, or any native in-app feed, which is where the large majority of paid social impressions are served. A desktop-ad-blocking user scrolls Instagram on their phone, sees your ad, taps it, browses in the in-app browser, then finishes the purchase later on their laptop, where uBlock Origin kills the Meta Pixel on your confirmation page. The ad was seen. The click happened. The purchase happened. Meta records nothing.

So the population “saw and clicked an ad, then converted invisibly” is much larger than the phrase “ad blocker user” suggests. The gap between where ads are served (increasingly in apps, unblockable) and where conversions are measured (your website, very blockable) is exactly where the recoverable conversions live. That gap is measurement loss, not demand loss, and measurement loss is fixable.

The knock-on cost is algorithmic. Smart Bidding and Advantage+ train on the conversions they can see. Feed them 70 percent of reality and they optimize toward the visible subset, complete with whatever bias ad-blocking demographics introduce. We walked through that failure mode with a worked model in client side vs server side tracking.

Test your own site in five minutes

Do not take loss percentages from vendor blogs, including this one. Measure your own site:

1. Install uBlock Origin in a fresh browser profile, default settings.
2. Open your landing page with DevTools open on the Network tab.
3. Filter for facebook, google, tiktok, or just look for red rows with ERR_BLOCKED_BY_CLIENT (Chrome) or NS_ERROR_ABORT style failures (Firefox).
4. Complete a test conversion and watch which event calls die on the form or checkout page.
5. Then compare a week of backend truth (orders, signups in your database or CRM) against what each ad platform and GA4 reported for the same period.

The delta in step 5 is your total measurement gap from all causes. The blocked requests in steps 3 and 4 tell you how much of it is ad blockers doing the work. For most sites the combined gap lands somewhere between 20 and 40 percent, with the ad blocker share tracking your audience’s desktop and demographic skew.

Why the popular workarounds fail

Adding another pixel. A second Meta Pixel matches the same filter as the first. Nothing changes.

Renaming or self-hosting the script. You can host the tag JavaScript anywhere you like; the event still has to POST to the platform’s collection endpoint, and that endpoint is what the filter matches. Blocked.

CNAME cloaking. The sneakier version: point a subdomain of your own site at the tracking vendor so requests look first-party. Filter maintainers un-cloak CNAMEs (uBlock Origin on Firefox does it automatically) and add the disguised subdomains to the lists, usually within weeks. You are in an arms race against volunteers who enjoy this, and platform policies and privacy regulators dislike the disguise too.

Here is the honest rule that separates fixes from decorations: if your tracking still depends on the user’s browser successfully delivering an event to an ad platform’s domain, you have not fixed anything. You have redecorated the thing being blocked.

What actually works: move the event out of the browser

Server side tracking changes the architecture instead of the disguise. The conversion is captured first-party (a lightweight script talking only to your own domain, plus events your backend already knows about, like a completed order), and your server, or a managed service acting as your server, sends it to Meta, Google, TikTok, and Microsoft through their Conversions APIs. Two properties make this ad-blocker-proof in practice:

• A first-party endpoint on your own domain is not on the filter lists, because blocking it would break real site functionality across the web. Filter lists target known third-party tracking domains, not yours.
• The server-to-server leg never touches the browser at all. There is nothing for an extension to inspect or block.

This is exactly what server side conversion tracking with Convultra does: one line of JavaScript for first-party capture, then managed Conversions API delivery with click ID storage, hashing, and deduplication handled for you. It is the difference between running tracking infrastructure and getting tracking outcomes, and it is how customers get to 95 to 98 percent tracking accuracy on ad-blocked traffic that pixels were silently dropping.

What server-side tracking does not fix

Credibility requires the caveats, so here they are. Server-side tracking does not exempt you from consent: GDPR and CCPA apply to data you process on a server exactly as they do in a browser, and consent signals must still be respected. It does not recover clicks that never happened, so a desktop display ad hidden by a blocker is genuinely lost demand, not lost measurement. And it cannot invent identifiers that never arrived: if a click ID was stripped en route, matching falls back to hashed email or phone, so your match rate depends on what your funnel collects. What it does fix is the largest and most fixable slice: real conversions from real ad clicks that your platforms currently cannot see.

FAQ

Do ad blockers block Google Ads conversion tracking?

Yes. The Google Ads conversion tag calls domains like googleadservices.com and googleads.g.doubleclick.net, both on the standard filter lists most blockers use. When blocked, the conversion never reaches Google Ads and Smart Bidding never learns from it.

How many conversions do ad blockers hide?

It depends on your audience’s device and demographic mix. Sites typically find a 20 to 40 percent gap between backend conversions and platform-reported conversions from all causes combined, with ad blockers a leading contributor on desktop-heavy and technical audiences. Measure your own gap against your CRM or order database rather than trusting an average.

Does server-side tracking bypass ad blockers?

For measurement, yes. Events are captured first-party and delivered server-to-server through platform Conversions APIs, so there is no third-party browser request to block. It does not bypass consent requirements, and it does not make blocked ads visible, it makes completed conversions countable.

Do ad blockers affect GA4 too?

Yes. GA4’s scripts and collection endpoints are on EasyPrivacy, so blocked users are missing from analytics as well as ads. That is why comparing GA4 to your ad platforms understates the problem: both are losing overlapping traffic.

Can I just detect ad blocker users and ask them to disable it?

You can detect a failed tracking script and show a banner, and publishers funded by ad impressions sometimes should. For an advertiser it is the wrong ask: the visitor is ready to buy and you are interrupting checkout to negotiate about a pixel. Fix the measurement server-side instead.

Get the data back

Ad blockers are not going away, and every quarter you run pixels alone, your platforms optimize on a shrinking slice of the truth. Start your free Convultra trial and see the conversions your dashboards have been missing, usually within the first day of install.