Ad blockers (uBlock Origin, Brave's built-in shields, AdGuard, Ghostery) don't just strip ads from the page — many of them, uBlock Origin especially, ship filter lists that specifically target analytics and tag management requests. EasyList, EasyPrivacy, and uBlock's own default lists block google-analytics.com, googletagmanager.com first-party fallbacks, and dozens of named marketing pixels outright. The result is that a meaningful slice of your real traffic — often 15-30% depending on audience, with technical and privacy-conscious audiences running much higher — never fires a single analytics event, and you have no row in GA4 or your CRM representing that visit at all.

Client-side GTM is the most exposed layer

A standard client-side GTM container loads googletagmanager.com/gtm.js, which is on nearly every ad blocker's default blocklist. When that request is blocked, the entire container fails to initialize — not just the ads pixels inside it, but GA4, Hotjar, and any other tag riding in the same container. This is the single biggest reason client-side-only measurement undercounts: it's not sampling or bot filtering, it's a hard request block before any tag has a chance to run.

Blocking surface by implementation

Implementation	Typical block rate	Why
Client-side GTM (gtm.js from googletagmanager.com)	High	Domain is on nearly every default filter list
Client-side gtag.js direct	High	google-analytics.com and googletagmanager.com domains both listed
Server-side GTM via first-party subdomain (e.g. sgtm.yourdomain.com)	Low	Request looks like first-party traffic to your own domain; not matched by domain-based filter lists
Server-side GTM via Google-managed *.appspot.com / run.app URL	Medium	Some filter lists have started targeting default Cloud Run/App Engine hostnames used for sGTM

Server-side tagging is a measurement fix, not just a privacy one

Most teams adopt server-side GTM for consent/privacy reasons, but its biggest measurable win is often ad-blocker evasion. Routing the sGTM endpoint through a first-party subdomain means the browser request looks identical to any other request to your own domain — filter lists that block by third-party domain pattern simply don't match it. This alone commonly recovers a meaningful percentage of previously-lost sessions, though it doesn't recover users who block at the DNS or network level (Pi-hole, NextDNS).

What blocking actually does to your funnel data

Blocked tracking doesn't distribute evenly across your funnel — it skews. Ad-blocker usage correlates with technical sophistication and privacy motivation, which correlates with browser choice (Firefox and Brave users block at far higher rates than default-browser mobile users) and often with higher-intent, lower-noise traffic. Practically: your reported conversion rate is biased upward (you lose denominator — total sessions — more than you lose numerator — conversions, since converters are more likely to have gotten far enough to be captured on an earlier page before blocking kicked in, or because high-intent users are sometimes more willing to disable blockers for sites they trust). Channel-level comparisons get distorted too: a channel that disproportionately drives privacy-conscious or developer audiences (organic search for technical content, Hacker News referrals) will show artificially poor measured performance relative to its true volume.

blocked_pixel_detection.ts

typescript

// Lightweight client-side check: did our primary analytics beacon actually fire?
// Useful as a QA signal, not a replacement for fixing the gap itself.
function detectAnalyticsBlocked(timeoutMs = 2000): Promise<boolean> {
  return new Promise((resolve) => {
    let fired = false;

    // Hook into GA4's internal event queue if available
    window.addEventListener("ga4-beacon-sent", () => {
      fired = true;
      resolve(false); // not blocked
    });

    setTimeout(() => {
      if (!fired) {
        resolve(true); // likely blocked — no beacon confirmed within window
      }
    }, timeoutMs);
  });
}

detectAnalyticsBlocked().then((blocked) => {
  if (blocked) {
    // Log to a first-party, unblockable endpoint for aggregate blocking-rate reporting
    fetch("/api/telemetry/blocked", { method: "POST", keepalive: true });
  }
});

Mitigation options, ranked by effort and durability

First-party server-side tagging on your own subdomain is the highest-leverage fix and the one to prioritize if you're still on pure client-side GTM. Beyond that: route analytics requests through a same-origin reverse proxy path (e.g. /collect instead of a third-party-looking path) rather than obvious names like /analytics/ or /tracking/, since some filter lists match on URL path patterns, not just domain. Measurement Protocol server-to-server calls (triggered from your backend on form submit or purchase, independent of any client-side script) are effectively unblockable since they never touch the browser. None of these fully close the gap — modern filter lists adapt, and users who block at the network/DNS level bypass domain-obfuscation tricks entirely — so treat mitigation as reducing the gap, not eliminating it.

Don't try to detect and circumvent ad blockers for ads themselves

Anti-adblock scripts that detect blocking and nag or wall off users are a different (and riskier) practice than fixing measurement gaps — they can violate platform policies, damage user trust, and trigger blocker-side countermeasures that escalate the arms race. The goal here is recovering accurate measurement of real visitors, not forcing ad display.

What's Next?

Ad blockers are one source of silent data loss, but they sit alongside a broader category of traffic quality problems — bot and crawler activity that inflates the same reports from the opposite direction, adding volume that was never a human at all.

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →