Ad blockers were built to remove ads. As a side effect — and for many blocking tools, an increasingly deliberate feature — they also block analytics scripts, including Google Analytics’s gtag.js. This means every store owner using standard client-side tracking is looking at data with a structural, invisible hole in it, and most don’t realize the scale of what’s missing until they specifically go looking.
Why Ad Blockers Block Analytics, Not Just Ads
Most popular ad blockers (uBlock Origin, AdBlock Plus, and others) rely on filter lists — community-maintained lists of domains and script patterns known to be associated with advertising and tracking. google-analytics.com and googletagmanager.com, the domains GA4’s tracking scripts load from, appear on many of these lists, specifically because analytics scripts are used for tracking regardless of whether they’re directly serving an ad. Some browsers go further, building blocking directly into the browser itself — Brave, for instance, blocks trackers by default without requiring any separate extension.
This means a visitor doesn’t need to be deliberately trying to block your specific analytics — they may simply have a general-purpose ad blocker installed for unrelated reasons (blocking ads on other sites, or general privacy hygiene), and your Google Analytics tracking gets caught in that same net incidentally.
How Widespread Is This, Really?
Ad blocker adoption estimates vary by source and audience, but figures in the 25–40% range for general web traffic are commonly cited, with meaningful variation by demographic — audiences skewing more technical, younger, or more privacy-conscious tend to block at higher rates, sometimes well above that range. There’s no single universal number that applies to every store, but the honest baseline expectation for most WooCommerce stores is that a substantial, non-trivial minority of visitors are running some form of blocking that prevents gtag.js from ever loading.
What Actually Happens When a Visitor’s Ad Blocker Is Active
This is worth being precise about, because the effect is more complete than people often assume. When an ad blocker prevents gtag.js from loading, no client-side tracking of any kind occurs for that visitor — not a pageview, not a scroll event, not an add-to-cart, and critically, not a purchase, even if that visitor goes on to complete a full transaction. The script simply never runs, so it has no opportunity to send any data whatsoever. This is a binary, all-or-nothing effect per visitor, not a partial degradation.
The Business Impact, Beyond Just “Missing Data”
Understated revenue. Every completed purchase from an ad-blocked visitor is invisible to Google Analytics, meaning your actual revenue is higher than what your reports show — sometimes substantially so.
Deflated conversion rate, as covered in our dedicated guide on this topic — because ad-blocked visitors still generally show up in whatever traffic measurement isn’t entirely dependent on the same blocked script (server logs, for instance, or partial session data captured before a block takes effect), the mismatch between “sessions recorded” and “purchases recorded” specifically deflates your calculated conversion rate, even though the true underlying rate is higher.
Corrupted attribution. If GA4’s attribution modeling is working from an incomplete picture — missing a chunk of the actual customer journeys that occurred — its assessment of which channels deserve credit for conversions is working from partial information, potentially undervaluing channels that happen to attract a higher share of ad-blocker-using visitors.
Distorted Google Ads optimization. If your Google Ads account imports GA4 conversion data for bidding optimization, and a portion of your actual conversions are invisible to GA4, Google Ads is optimizing against an incomplete signal — potentially failing to properly credit and reinforce campaigns that are performing better than the visible data suggests.
Why This Isn’t Evenly Distributed Across Your Traffic
A subtlety worth understanding: the impact of ad blocking isn’t necessarily uniform across every channel and audience segment, which means the resulting distortion in your reports isn’t just a flat, predictable discount you can mentally adjust for — it’s an uneven one. A channel or campaign that happens to attract a more technically sophisticated or privacy-conscious audience will show a proportionally larger tracking gap than one attracting a more general audience, meaning your reported relative performance between channels can be skewed, not just your absolute totals. This makes ad-blocker-related data loss a genuinely harder problem to simply “adjust for” mentally than if it applied evenly everywhere.
The Fix: Server-Side Tracking
As covered in depth in our dedicated guide on server-side WooCommerce tracking, the structural fix for this specific problem is sending purchase (and optionally other key ecommerce) events directly from your web server to GA4’s Measurement Protocol API, rather than relying solely on the visitor’s browser to send them. Because this transmission happens server-to-server, entirely outside the customer’s browser, an ad blocker running in that browser has no opportunity to intercept or prevent it — the browser-level blocking mechanism simply isn’t in the data’s path at all.
This doesn’t require asking customers to disable their ad blockers, doesn’t involve any adversarial cat-and-mouse attempt to detect and circumvent blocking technically, and doesn’t compromise on respecting genuine consent choices — it simply moves the critical revenue-tracking step to a part of the system ad blockers were never designed to reach in the first place.
How TrueAna helps
How TrueAna Handles This for WooCommerce Stores
Implementing server-side Measurement Protocol tracking from scratch means building and maintaining infrastructure most store owners never signed up to manage: a server-side endpoint, event payload construction that matches GA4’s schema, client ID and session stitching so server-sent events line up with whatever client-side data did get through, and ongoing maintenance as GA4’s API evolves. TrueAna builds this directly into the plugin, so the fix described above is a setting rather than a development project.
Once enabled, TrueAna sends purchase and other configured WooCommerce events to GA4 through the Measurement Protocol from your WordPress server itself, alongside the standard client-side gtag.js tracking. Because the request originates from your server rather than the customer’s browser, it’s outside the reach of ad blockers entirely — the order goes through the same way whether or not that specific customer’s browser blocked analytics scripts.
A few things this addresses directly for WooCommerce stores specifically:
- Orders placed by ad-blocked visitors are still recorded in Google Analytics, closing the exact gap described above without asking anything of the customer.
- Client ID matching is handled automatically, so server-sent events are attributed to the same session as whatever client-side activity did register, rather than showing up as a disconnected, attribution-less transaction.
- It’s built to work alongside Consent Mode v2, so server-side delivery respects the same consent state a visitor has already set — this isn’t a way of bypassing consent choices, just the browser-blocking mechanism.
- Because it’s purpose-built for WooCommerce, it uses native WooCommerce order and subscription data rather than requiring a generic, hand-mapped event schema.
This doesn’t replace client-side tracking — as noted above, that’s still the source of most behavioral data — but it means the single highest-stakes event, the completed purchase, isn’t left exposed to a gap that a meaningful share of visitors will otherwise fall into.
What Server-Side Tracking Doesn’t Fix
Worth being clear-eyed about scope: server-side tracking closes the ad-blocker (and related browser-restriction) gap specifically for whatever events you configure it to send — typically the purchase event, since that’s the highest-stakes one for revenue accuracy. It doesn’t restore the behavioral data (page views, scroll depth, add-to-cart events) that would have been lost to the same ad-blocked visitor’s earlier browsing activity, unless you extend server-side delivery to those events too, which is a more involved and less commonly implemented undertaking than purchase-event coverage alone. For most stores, prioritizing server-side delivery specifically for the revenue-critical purchase event delivers the large majority of the practical benefit relative to the implementation effort involved.
A Simple Way to Estimate Your Own Gap
Without implementing anything new, you can get a rough sense of your store’s specific exposure: compare your GA4-reported transaction count against your actual WooCommerce order count for a recent, representative month. The percentage gap between the two is a reasonable (though not perfectly precise, given the other contributing factors covered in our broader guide on GA4/WooCommerce discrepancies) proxy for how much of your revenue picture is currently invisible — and a useful, concrete number to reference when deciding whether investing in server-side tracking is worth prioritizing for your specific store.
The Compounding Problem for Growing Stores
For a store in active growth mode — scaling ad spend, testing new channels, expanding into new markets — the ad-blocker gap compounds in a specific, dangerous way: every new marketing decision gets made against a data foundation that’s already understating performance, and the errors accumulate across an increasing volume of spend and decisions rather than staying contained to a single static baseline. A store spending $5,000 a month on ads and looking at understated conversion data might reasonably conclude a channel isn’t worth scaling further, when the true, complete picture would have shown a healthier return. As spend grows, the cost of continuing to make decisions on incomplete data grows proportionally — which is part of why addressing this specific gap tends to matter more, not less, as a store scales, rather than being a concern that only applies to very large, high-volume operations.
Frequently Asked Questions
Is there a way to detect which specific visitors have ad blockers active?
Some techniques exist for detecting ad-blocker presence, but using this to specifically ask visitors to disable blocking in order to use your site is generally a poor user-experience tradeoff for most ecommerce stores, and doesn’t address the underlying data gap the way server-side tracking does — it just shifts the burden onto the visitor rather than solving the measurement problem directly.
Do ad blockers affect Google Ads’ own conversion tracking the same way they affect GA4?
Yes, similarly — Google Ads’ standard conversion tracking also typically relies on client-side scripts subject to the same blocking. This is part of why Google has introduced Enhanced Conversions, which incorporates server-side and hashed-data elements to improve tracking resilience in a broadly similar spirit to GA4’s server-side Measurement Protocol approach.
Does implementing server-side tracking mean I no longer need client-side tracking at all?
No — most well-built implementations run both together, since client-side tracking still captures rich behavioral data beyond just the final purchase (page views, add-to-cart activity, the full funnel) that remains genuinely useful, with server-side specifically filling the gap for the revenue-critical purchase event.
Is this problem getting worse over time as more people adopt ad blockers?
Ad blocker and browser-privacy-tool adoption has generally trended upward over recent years as privacy awareness has grown, and browser vendors have increasingly built blocking capability directly into their products by default — this suggests the scale of the client-side tracking gap is more likely to grow than shrink over time, making server-side tracking an increasingly rather than decreasingly relevant investment.
Do all ad blockers affect analytics equally, or do some allow it through?
There’s meaningful variation — some blockers are configured primarily around visible ad content and are less aggressive toward analytics scripts specifically, while others (particularly privacy-focused browsers and stricter blocklist configurations) block analytics domains just as thoroughly as ad domains. This variation is part of why the affected-traffic percentage differs across sources and audiences, and why a single universal estimate should be treated as a rough guide rather than a precise figure for your specific store.
Do I need to build server-side tracking myself, or is there a plugin that handles it?
For WooCommerce stores, this doesn’t need to be a custom development project. TrueAna implements Measurement Protocol delivery as a built-in setting, handling event payloads, client ID matching, and Consent Mode v2 alignment out of the box, so store owners can close the ad-blocker gap on the purchase event without writing or maintaining any server-side integration themselves.
