If a slice of your visitors use ad blockers – anywhere from 15% to 50% depending on who they are – a chunk of your analytics never arrives. The usual fix is to proxy your tracking through your own domain so it looks first-party. That only helps if you also rename the recognizable URLs – keep a path like /collect or /gtag/js and a generic filter rule blocks it on day one. And even when it's done right, the recovered data tends to quietly disappear a few months later. If you've ever set one up, you already know the catch (hint: ad blockers eventually find it anyway – unless your site is too niche to bother with).
The methods that genuinely last all share one property: blocking them has to cost the user, not just you. Anything that only costs you as a developer – your time, your maintenance – is a fight you slowly lose. The blocker community is bigger, more automated, and more patient than any single site owner or a community.
Here are three approaches, roughly in order of how long they hold up.
1. Proxy through your own domain (buys months)
This is the default advice, and it's a reasonable first step. A reverse proxy on your own origin – not a CNAME, which is already caught – defeats domain-based blocking because the request genuinely comes from your site.
What it doesn't defeat is filter rules that match URL paths and parameters regardless of domain, plus the fact that anyone can report your domain by hand. So a proxy survives only as long as you keep renaming endpoints and watching the lists. It's worth doing, but treat it as a temporary fix, not a solution. I covered exactly why, with the dates and the filter rules, in the companion post on why proxies are a time bomb.
2. Make the tracker something the reader wants (durable, but narrow)
This is my favorite approach, and you can build it yourself without any product.
In my personal blog, each article shows its view count and its comments. Both come from a single API endpoint – one request from the page that does three things at once:
- returns the view and comment counts the page shows,
- returns the comment text to render, and
- records the view, server-side.
That last one is the tracking. It isn't a separate beacon bolted onto the page – it's the same request that fetches a feature the reader actually wants to see.
That puts a blocker in an awkward spot. To block the "tracking," it has to block the useful endpoint. But blocking the endpoint also removes the view counter and the comments – visible, wanted parts of the page. Blockers work hard not to break visible functionality, because a blocker that breaks pages gets disabled or uninstalled. So they leave it alone. The count is honest, the comments load, and the view gets recorded – all or nothing, and "nothing" is the option that annoys the user.
The caveats matter, though, and I'd rather state them plainly than oversell this:
- It only works when the tracking can be genuinely fused to something the user wants to see. View counts, comment threads, like counts, "X people are looking at this" – fine. A background analytics beacon or an ad pixel has no user-facing payload to hide behind, so this doesn't generalize to Google Analytics, Meta Pixel, or conversion APIs, at least easily.
- It's custom backend work. You're designing an endpoint, not pasting a snippet. A simple task for Cloudflare workers but can be harder if you're not on Cloudflare.
- It buys you the view-and-engagement signal, not your full marketing stack. But! You can still extract the real number of views, and compare them reliably to what you get in your analytics stack.
So it's a good fit for a specific case – content sites, dashboards, anything where a number on the page is the metric – not a general answer.
3. Couple the data channel to the app itself
The single-endpoint trick works because blocking it breaks something. Generalize that idea and you get the only approach I know that doesn't expire: make the analytics transport a dependency of the application, so the channel that carries your events is the same channel the app needs to run. Strip it and the app stops working – which is the one move blockers avoid.
This is what DataUnlocker does. It doesn't replace your analytics – it wires whatever you already use (Google Analytics, server-side GTM, Plausible, Mixpanel, the Meta Pixel, or your own pipeline) into a cryptographically protected channel bound to the app. A blocker gets a binary choice: let it work, or break the page for that user. There's no quiet middle where it strips the tracking and leaves the site fine, and blockers definitely don't want to maintain all edge cases arising from limiting JavaScript functionality on a site.
It's not magic, and the trade-offs are real: at scale roughly 0.1% of users can hit a "refresh me" (limited app) state on a flaky network, and cosmetic or script filters can still partially break a page. But the failure mode is one you can see and tune, not one that silently erodes your data for months. Whether to trade data accuracy for one more almost-never-visible UX check (when compared to almost-always-visible, for instance, Cloudflare Challenge Page) is your choice.
So which should you use?
If you run a content site and the metric you care about is views or engagement, the single-endpoint approach is the cheapest durable thing you can build, and it's yours forever. If you need your real analytics and marketing stack to keep reporting accurately across users with blockers, coupling the data channel to the app is the version that doesn't decay. A plain proxy is a fine stopgap as long as you remember it's a stopgap.
The common thread across all three: stop trying to hide the tracking. Instead, make removing it cost the user something the blocker isn't willing to pay. Hiding is a race against far more people than you can match. Raising the cost of blocking is the part you control.