How Adblockers Block Your Analytics

1. How Filter Lists Work

Strip it down and most adblockers run on nothing more than a list of URL patterns. Every network request your browser makes gets checked against one or more of those lists, and a match kills the request before it ever leaves.

The major filter lists relevant to analytics are:

EasyPrivacy

The most widely used tracking-specific filter list. Maintained by the EasyList team, included by default in uBlock Origin and AdBlock Plus. Contains explicit entries for virtually every analytics and tracking service. Updated multiple times per week as new tracking endpoints appear.

uBlock Origin's built-in filters

uBlock ships with its own curated lists beyond EasyPrivacy, including specific filters for Google Analytics, GTM, and other services. It also includes Peter Lowe's Ad and Tracking server list.

Disconnect.me Tracking Protection List

Used by Firefox Enhanced Tracking Protection and some other browsers. Classifies domains into categories (Advertising, Analytics, Social, Content) and blocks the Analytics and Advertising categories by default.

Brave Shields

Brave compiles filter list content into a high-performance native engine. It uses uBlock's lists plus Brave's own additional rules, applied at the browser level without requiring any extension.

The syntax handles wildcards and domain matching, so an entry like ||google-analytics.com^ catches every URL on google-analytics.com, subdomains included. Changing the query string or path won't get past that; the domain itself is what's blocked.

2. What Gets Blocked and Why

The exact endpoints every major adblock targets, tool by tool:

Google Analytics 4

||google-analytics.com^ (blocks all GA4 data collection)||googletagmanager.com/gtag/ (blocks gtag.js loading)||analytics.google.com^ (blocks GA4 Measurement Protocol)

All GA4 events — pageview, scroll, click, purchase, custom events — are sent to google-analytics.com/collect or analytics.google.com/g/collect. Both are explicitly blocked.

Google Tag Manager

||googletagmanager.com^ (blocks gtm.js container loading)||www.googletagmanager.com/gtm.js (explicit GTM container block)

GTM itself is the container. When the GTM script is blocked, every tag inside it fails to execute — GA4, Facebook Pixel, Google Ads, LinkedIn, Hotjar, all of it.

Facebook / Meta Pixel

||connect.facebook.net^ (blocks fbevents.js and all pixel events)||facebook.com/tr/ (blocks server-to-browser pixel calls)

The Facebook Pixel script and every event it fires (PageView, Purchase, AddToCart, Lead) are blocked. Custom conversions, custom audiences, and event deduplication all fail.

Other Common Tools

||static.hotjar.com^ (Hotjar script blocked)||cdn.amplitude.com^ (Amplitude SDK blocked)||api.mixpanel.com^ (Mixpanel event collection blocked)||sc-static.net^ (Snapchat Pixel blocked)||snap.licdn.com^ (LinkedIn Insight Tag blocked)

Most tracking and analytics services are blocked. The filter lists are comprehensive and maintained by large communities who actively add new trackers.

3. The GTM Cascade Problem

Google Tag Manager is a single point of failure for every analytics and marketing tool deployed through it. Here's what happens when GTM is blocked:

1The browser attempts to load googletagmanager.com/gtm.js
2The adblock intercepts the request and blocks it — the script never downloads
3The GTM container never initializes
4No tags inside the container can fire: GA4, Facebook Pixel, Google Ads conversions, LinkedIn Insight Tag, Hotjar, custom HTML tags — all silenced
5The dataLayer still receives pushes from your site code, but with no GTM to consume them, nothing happens

For a visitor who blocks GTM, that cascade means total data loss, not partial. It's not just GA4 going dark — every tool in your marketing stack loses that visitor at the same moment. On many sites, that adds up to 100% data loss for 25-40% of visitors.

4. Browser-Native Blocking (No Extension Needed)

No extension required for a growing share of blocking these days — modern browsers just ship tracking protection out of the box.

Brave Browser

Brave ships with a built-in adblock that compiles uBlock Origin filter lists into a native Rust-based engine (called 'Brave Shields'). It runs before the browser's network stack, blocking analytics requests with essentially zero overhead. No extension required, on by default for all users.

Impact on analytics

100% of standard analytics endpoints blocked by default. Brave has ~3-4% browser market share globally, higher in developer and tech audiences.

Firefox Enhanced Tracking Protection (ETP)

Firefox ships with ETP enabled by default since version 69 (2019). In 'Standard' mode, it blocks known trackers in third-party contexts using the Disconnect.me list. In 'Strict' mode, it also blocks tracking content in first-party contexts and fingerprinting scripts.

Impact on analytics

Standard ETP blocks some analytics endpoints. Strict mode blocks significantly more. Firefox has ~3-4% market share. Any Firefox user with an ETP-compatible blocker (uBlock Origin) gets full blocking.

Safari Intelligent Tracking Prevention (ITP)

Safari's ITP works differently — it uses machine learning to classify domains as trackers and then restricts their ability to set and read cookies. JavaScript-set first-party cookies are capped at 7 days. Cross-site tracking is prevented entirely. ITP doesn't block network requests outright, but it severely limits attribution and user identification.

Impact on analytics

Less severe for pageview counting, but significant for attribution, returning user identification, and any analytics that depends on cookie persistence beyond 7 days. Safari has ~18-20% browser market share.

Edge Tracking Prevention

Microsoft Edge includes a Tracking Prevention feature with three modes: Basic, Balanced, and Strict. Strict mode blocks all detected trackers including analytics tools. Balanced mode (the default) blocks trackers that appear to cause security or compatibility issues.

Impact on analytics

Strict mode users get analytics blocking similar to uBlock Origin. Edge has ~5% market share.

Add it up and even a site where nobody installed an adblock extension still loses a meaningful chunk of analytics to browsers doing it automatically, with zero effort from the visitor.

5. Why First-Party Proxies Bypass Blocklists

A filter list can only match what it knows about — domains and URL patterns it already has entries for. A domain it's never heard of simply isn't in the list.

Reroute a signal through a first-party subdomain, analytics.yoursite.com instead of google-analytics.com, and the adblock is looking at a domain with no rules attached. It has no idea the request gets forwarded to Google Analytics server-side afterward. Nothing to block, so it goes through.

Request flow with a first-party proxy

Browser sends event to

analytics.yoursite.com/collect

Your own domain — no filter list match

Proxy receives and forwards to

google-analytics.com/collect

Server-to-server, never seen by the browser's adblock

GA4 receives

Complete event data ✓

Full data received, no data loss

That's the whole reason first-party proxying holds up better than other approaches — it operates at the network layer instead of trying to rename scripts or obfuscate a domain. There's no rule to write against a domain nobody's flagged yet, and a genuinely first-party subdomain has no reason to ever land on a public blocklist.

Visitor context preservation

Proxies aren't interchangeable here. A naive one forwards requests with its own server as the apparent source, and that corrupts analytics in a way that's easy to miss: GA4 and Facebook lean on geographic context for location attribution, anti-fraud filtering, and session data. Show GA4 a datacenter in Virginia instead of an actual visitor in Berlin, and your geographic reports go wrong while anti-bot filters start behaving unpredictably.

Done properly, a proxy reads the visitor's original context off the incoming connection and carries it into the forwarded request, whether that's headed to Google, Facebook, or anywhere else. The recovered signal ends up indistinguishable from one that was never blocked in the first place — same location, same session context, nothing degraded.

6. How to Check If Your Analytics Are Being Blocked

A few practical ways to measure the actual gap on your own site:

Brave browser test

1Open your site in Brave browser with Shields enabled (the default)
2Open DevTools → Network tab
3Look at requests: any request to google-analytics.com, googletagmanager.com, or connect.facebook.net will show as blocked (often with a red X or simply absent)
4Compare against Chrome with no extensions — the difference is what Brave users are blocking

Compare GA4 sessions vs server logs

1Pull your GA4 session count for a date range from Google Analytics
2Pull your server-side request count for the same pages and period from your web server logs or CDN logs
3The gap (server requests - GA4 sessions) / server requests approximates your blocked percentage
4Note: server logs count bots too, so the gap will be slightly larger than the true blocked percentage

Check the browser console

1Open your site with uBlock Origin installed and enabled
2Open DevTools → Console
3Look for failed network requests (usually shown in red)
4You'll see entries like 'Failed to load resource: net::ERR_BLOCKED_BY_CLIENT' for analytics endpoints

7. Solutions Compared

Once blocking is confirmed, there are a handful of ways to actually get that data back:

Do nothing

Pros

+No effort required

Cons

−Lose a large share of analytics data permanently (29.5% of visitors block trackers globally)
−Marketing campaigns optimize on wrong data
−A/B tests run on a biased sample

Not recommended for any site where data quality matters

Server-side tracking (move analytics to backend)

Pros

+Can work with GA4 Measurement Protocol
+Full control over data

Cons

−Significant engineering effort — weeks of work
−Loses client-side context (scroll depth, click events, etc.)
−Requires per-platform implementation
−Expensive ongoing infrastructure

Viable for large engineering teams with dedicated analytics infrastructure

Full analytics proxy (route all traffic through proxy)

Pros

+Works for most analytics tools

Cons

−Routes ALL analytics traffic, not just blocked — high cost at scale
−Adds latency for every visitor, not just blocked ones
−DNS/CNAME required regardless of blocking
−Single point of failure for your analytics

Works but is expensive and over-engineered for the problem

Targeted signal recovery (Introtrace approach)

Pros

+Only intercepts signals that are actually blocked — normal traffic unaffected
+One script tag, 2-minute setup
+Works for all analytics platforms simultaneously
+Visitor location context preserved — geographic attribution stays accurate
+Free to start, low cost at scale
+No latency added for non-blocked visitors

Cons

−Requires adding a script to your site

Lowest overhead approach — you only pay for what's actually recovered

Summary

None of this is mysterious: adblockers match your analytics URLs against maintained filter lists, deterministically. GA4, GTM, Facebook Pixel, and most of the rest have sat on those lists for years, and there's no version of using them that dodges users who have those lists switched on.

Routing the affected requests through a domain that isn't on any blocklist is the only fix that actually holds up. The practical way to do that, short of proxying all your traffic or rebuilding analytics server-side, is detecting which requests get blocked and recovering just those. That's what Introtrace does — through cdn.introtrace.com by default, or a first-party subdomain you own via CNAME on a paid plan, the sturdier of the two for the reasons above.

That's the gap Introtrace closes. Add the script tag and you'll see how much of your own site's data was missing, recovered starting immediately.

See How Much Data You're Losing

One script tag, and analytics signals blocked by adblockers start coming back. Free up to 20,000 recovered signals a month.

Start Free

Frequently Asked Questions

Can filter lists be updated to block first-party proxies?

In theory. In practice, extremely unlikely. A maintainer would have to add your specific subdomain by name, and public blocklists exist to target shared tracking domains used across millions of sites — chasing individual custom subdomains one by one would be an unmanageable maintenance burden, and it'd break legitimate first-party API traffic along the way. There's a legal wrinkle too: blocking a company's own subdomain sits on different footing than blocking Google's shared infrastructure.

Does using a proxy affect visitor location data seen by analytics?

Only if it's built lazily — see the visitor context preservation section above for why. To check any proxy you're evaluating: pull up a recovered session's GA4 city/region and compare it against where that visitor actually was. If it comes back as a datacenter or the same single city regardless of where your traffic originates, the proxy is dropping visitor context on the way through, and your geographic and anti-fraud reports are quietly wrong.

Are server-side tracking tools like GA4 Measurement Protocol immune to adblockers?

The browser never sees a server-to-server request, so a browser-based adblocker has nothing to block. The trade-off is real, though: you lose client-side context like scroll depth, time on page, and click events, and getting deduplication and session handling right takes real engineering. It's also platform-specific — every tool needs its own server-side build.

Will Google penalize my site for using a first-party analytics proxy?

Nothing in Google's webmaster guidelines prohibits it. Plenty of large sites route analytics through their own domain, and Google's own server-side GTM runs on the same principle. Rankings care about page quality and user experience, and how your analytics signal gets transported has no bearing on either.

How do I know how much data my site is currently losing to adblockers?

Install uBlock Origin in one browser and compare a session with it on versus off — the Network tab in DevTools will show you the blocked requests directly. For a number you can put in a report, compare GA4 session counts against your server or CDN access logs for the same period; the gap is a reasonable approximation of your blocked share. Developer and tech-focused audiences typically land around 30-50% blocked, general consumer sites more like 15-30%.