Ad Blockers and Your Analytics: How Much Data You Lose and How to Recover It

Open your analytics, then open your shop platform. Compare visits, or compare purchases. There is almost always a gap, and a portion of it is caused by something running in your visitors' browsers that you never installed: an ad blocker.

This article explains how ad blockers and privacy tools interfere with analytics and advertising tags, how big the problem might be for your own store, and what you can do about it in a way that stays on the right side of privacy. As with everything on this topic, the honest answer includes limits, so we will cover those too.

How ad blockers work

An ad blocker is a browser extension, or a feature built into some browsers, that inspects the requests a page tries to make. It compares each request against lists of rules and blocks the ones that match. The rules come from community-maintained filter lists, and they contain thousands of entries.

Two kinds of rules matter for tracking:

• Domain rules. Block anything going to a known analytics or advertising domain, such as the hosts that serve Google Tag Manager, Google Analytics, the Meta pixel or TikTok's pixel.
• Path and pattern rules. Block requests whose URL looks like a tracking call, for example files with familiar names or endpoints such as those used for collecting events, regardless of which domain they come from.

Some browsers go further. Brave blocks many trackers by default. Firefox's Enhanced Tracking Protection blocks known trackers in strict modes, and Safari restricts cross-site tracking as well. Separate from blockers, privacy-focused DNS services can also stop tracking domains from resolving at all.

What gets lost when a tag is blocked

If the tag manager script itself is blocked, nothing that depends on it runs: no page views, no purchase events, no remarketing lists. If only certain tags are blocked, you get a partial picture, which can be even more misleading because the data looks plausible.

The result in your reports:

• Fewer sessions and events in analytics than actually occurred.
• Purchases missing from analytics that exist in your shop platform.
• Ad platforms reporting fewer conversions, so bidding algorithms train on incomplete data.
• Remarketing audiences that are smaller than they should be.

Importantly, the people who block trackers are not random. They skew toward technically confident, privacy-aware users, and depending on your market, that group can include your best customers. The data you lose is not necessarily a fair sample.

How much are you missing?

Estimates of blocker usage vary widely by country, audience and device. Developer and technology audiences tend to block much more than general consumer audiences, and desktop users block far more than mobile users. Rather than trusting a generic percentage, measure your own gap:

1. Compare orders. Take the number of orders in your shop platform for a week and the number of purchase events in analytics. Allowing for normal attribution differences, an unexplained shortfall suggests blocked or failed events.
2. Segment by browser and device. A shortfall concentrated in desktop Chrome or Firefox, where extensions are common, points to blockers.
3. Run a controlled test. Load your store in a clean browser profile, then again with a popular blocker enabled, and watch the network requests and events. You will see exactly what disappears.

The test in step three is surprisingly revealing. It takes ten minutes and often shows the tag manager script or the analytics endpoint blocked outright.

Why loading tags from your own domain helps

Blocklists are built around the domains and paths that other people use for tracking. When your tagging endpoint lives on your own subdomain, such as track.yourstore.com, the domain-based rules no longer match. To the browser it looks like a request to your own site, which is exactly what it is.

That is the core of server-side tagging: the browser sends its events to your server rather than directly to a dozen third-party domains, and your server forwards the data to the platforms. Fewer third-party requests leave the page, so fewer are available to block.

Custom loader paths

The Google Tag Manager script has a well-known name and location, and filter lists target it. A custom loader serves that same script from a path you choose on your own tagging domain, for example a random-looking file name, so a rule written for the standard path does not match. On FlyNode this is the Custom Loader power-up, available on every plan: you enable it, choose a path, and update the script URL in your site's snippet. See sGTM power-ups explained for the steps.

The honest limits

This is where many vendors overpromise. Being straightforward about limits will save you from disappointment:

• It is an arms race. Filter list maintainers watch for evasion techniques. A path that works today may be added to a list tomorrow. First-party hosting and custom paths raise the bar; they do not end the contest.
• Some blockers work by behaviour, not just lists. Strict tools can block based on what a script does, not merely where it comes from.
• Network-level blocking exists. If a visitor's DNS or router blocks a category of hosts, your own subdomain may be caught if it resolves to a flagged address.
• Consent still applies. A visitor who uses a blocker is often sending a clear signal about their preferences. Recovering their data is not automatically appropriate. See below.

The consent question you should think about honestly

There is a real ethical and legal distinction here that deserves a straight discussion. Two situations look similar in analytics but are not the same:

1. A blocker catching your analytics by accident. The visitor did not make a specific decision about your store; a general-purpose list simply matched a common domain. Serving your own first-party analytics reliably, with a proper privacy notice and consent where required, is a reasonable response.
2. A visitor who has explicitly declined tracking. If they used your consent banner to refuse, or a signal such as Global Privacy Control, that decision must be honoured regardless of how your data pipeline is built.

Server-side tagging changes how data travels, not whether you may collect it. Build your setup so that consent choices are respected on the server as well, and do not use these techniques to circumvent explicit refusals. That is both the right approach and the sustainable one, since regulators and browsers are increasingly attentive to evasion.

A practical plan for a store

1. Quantify. Run the order comparison and the blocker test described above. Write down the baseline.
2. Move tagging to your own subdomain. Deploy a server-side GTM container and attach a first-party domain. Our guide on custom first-party tracking domains covers the DNS steps.
3. Enable the custom loader. Serve the tag manager script from a custom path on that domain.
4. Send key events server-side. Route purchases and other high-value events through the server, so their delivery does not depend on a third-party script loading in the browser.
5. Verify with the blocker on. Repeat the controlled test. Confirm the events now arrive, and use the Event Logs tab to see requests reaching your server.
6. Keep monitoring. Re-check monthly. If a new filter rule starts matching your path, change it.

Beyond blockers: other reasons events go missing

Do not assume every gap is a blocker. Before spending effort, rule out the ordinary causes:

• Tags configured to fire on a page that some customers never reach, such as a thank-you page they close early.
• Slow scripts that have not finished by the time the visitor navigates away.
• Consent banners that block tags until a choice is made, then never fire them for that page view.
• Single-page application routes where page-view events are not sent on navigation.
• Payment providers that redirect customers to an external page and back, breaking the session.

Our troubleshooting checklist and the article on GA4 e-commerce tracking help separate these from blocker losses.

What to tell your team

If you need to explain this to a manager or client, keep it simple:

• Some of our visitors use tools that block analytics and advertising scripts, so our reports under-count real activity.
• Serving tracking from our own domain, and delivering key events from a server, reduces that loss and gives ad platforms better data to optimise with.
• It will not capture everyone, and it will never override a visitor's explicit consent choice.

How to check whether it is working

After you change your setup, verify the result rather than assuming. Open your store in a browser profile with a popular blocker enabled, open the network panel in developer tools and reload. Filter requests by your tagging domain. You should see events going to your own subdomain and returning successful responses, while third-party analytics domains no longer appear for the events you moved server-side. Then complete a test purchase and confirm that it shows in your Event Logs and in the reports of each platform you send it to. Repeat this test every few weeks, since filter lists change and a rule that missed you last month may match you today.

Keep a short record of what you tested, in which browser and with which blocker version. When numbers shift later, that record helps you decide whether the cause is a filter update, a theme change or a real change in customer behaviour.

The bottom line

Ad blockers are a fact of the modern web, not a scandal. A meaningful share of visitors will always slip past third-party tags, and the ones who do are often the most engaged. You can recover a good portion of that measurement by hosting your tracking on your own domain, loading the tag manager from a custom path and delivering important events from a server, all while respecting consent.

Ready to try it? Deploy your first server-side GTM container on FlyNode, enable the Custom Loader, and rerun the blocker test. The comparison will tell you more than any estimate we could give.