In 2025, it's still a common misconception that using server-side Google Tag Manager (ssGTM) makes web analytics ad blocker-resitant, and analytics data more accurate[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, ...].
Gains? Just a few percentage points. Blockers adapt and always catch up.
So if you're looking to implement ssGTM purely to circumvent ad blockers, stop. You'll inevitably end up with hard workarounds that result in wasted effort.
Take a look at how popular privacy tools and ad blockers identify and block both client-side and server-side GTM requests:
The above was tested using uBlock for Chrome with default settings and default GTM/ssGTM, though the same behavior occurs across Brave, Ghostery, AdGuard and many other popular blockers and privacy tools. You can check this yourself by opening Developer Tools (F12) with any of the above blockers installed.
Some of your users use blockers. Thus, your behavioural analytics is missing 15% to 50% of data – losing insights into advanced, tech-savvy user segment.
This article will explain exactly how ad blockers block server-side GTM and what you can do to secure your analytics data reliably.
Why "server-side" in ssGTM's name is misleading
You should already know that Server-Side Google Tag Manager depends on client-side JavaScript code and, moreover, sends events from the client — through your server, and in fact only to a few of your connected marketing products.
Sure, with ssGTM you have the ability to send events from the server — but something has to trigger it, right? In 99% of cases, it's the client. The entire architecture of GTM is built around client-side event triggers, also allowing to send events from the server.
Ideally, you'd imagine Server-Side Google Tag Manager working like this:
But if we take a closer look at what happens between Client and Server, in a typical setup we’ll discover that there are plenty of scripts and network requests — even to third-party servers:
Which means:
- "Server-Side" GTM still loads JavaScript and sends hits from the client, initiating network requests directly from the browser.
- Some third-party products in your server-side container (such as Microsoft Clarity, HotJar, and others) are still loaded via third-party domains.
- And, most importantly, all requests can still be manipulated by blockers because they inevitably contain URL and JavaScript patterns.
To summarize: Server-Side Google Tag Manager still heavily relies on client-side execution.
Users' browsers must run JavaScript, set cookies, and make network requests — precisely what privacy tools and ad blockers target. That's just how the web is designed.
The tests above were performed on first-party ssGTM from Cloudflare, although the behavior is similar across all other setups.
How much data is lost to blockers?
Statistics you can find online are largely outdated due to the adoption of privacy tools to block server-side tagging.
If you're wondering what the current ad blocker impact on Google Tag Manager looks like (approximately), here's a chart based on aggregated usage data from our product:
So in practice, server-side GTM – when compared to client-side GTM – limits the promised accuracy gains to just a few percentage points, mainly by bypassing "simple" network blockers like Pi-hole and privacy VPNs.
But the blocker industry has already gone far beyond just DNS-level blocking. Nearly 80% of widely used blocker software can detect and block server-side GTM – even in custom setups.
The exact percentage of data lost to blockers varies by business niche, ranging between 15% and 50%. It's best to trial it live to see how it applies to your traffic. But at a glance, any kind of blocker is used by:
- 15-20% of users in retail
- 20-30% of users in gaming & tech
- Up to 50% of users in crypto
Even more importantly: if your website or web app ever appears in public filter lists, there's a high chance it will be maintained there indefinitely. Just take a look at this chart – the number of open-source contributions to filter lists keeps growing steadily:
Why do ad blockers block Google Tag Manager?
The reason privacy software and ad blockers exist in the first place is because of how the web is designed – and the flexibility it gives to filter out unwanted resources from websites.
In contrast, when you play your favorite mobile or desktop game, software like ad blockers can't really do anything (such as remove analytics collection, etc.). With modern tech, it's nearly impossible – technically speaking[1, 2].
The web is, fortunately or not, very flexible and transparent. Anyone can open their browser's Developer Tools (F12) and examine almost the source code of any web app, the network requests it makes, and the data it transmits or stores – everything.
And that's exactly where blockers thrive — trying to block everything that is "not necessary" for the web application to run. From the ad blocker's perspective, their business is justified: there's no reliable way to tell who's well-behaved and who isn't, so they assume that everyone is ill-behaved.
Even though GTM is just a tool (like JavaScript itself), in 99% of cases, neither it nor the marketing products it loads are intended to be harmful. Of course, we'd need to define what "harmful" means in this context – but that's a nuanced discussion for another article.
For the purpose of this one, we assume your use of Google Tag Manager is genuine, valid, respectful, and properly consented – especially if you process any personally identifiable data – in full accordance with GDPR or other applicable regulations.
How do ad blockers block Google Tag Manager and Google Analytics?
Now onto the technicals. You know the web is made up of HTML, CSS, JavaScript, and network requests. Blockers — mainly browser extensions, installed software, or privacy-focused web browsers – are able to control nearly every bit of a web application:
- Block network requests using URL patterns.
- Replace text patterns in HTML or scripts.
- Hook deep into JavaScript APIs (using "scriptlets", etc.).
Server-side Google Tag Manager fails at step 1, regardless of your domain or path prefix setup.
Here's a sample of the network requests made with first-party ssGTM installed on Cloudflare, where /metrics is the path prefix:
- https://demo.com/metrics/
- https://demo.com/metrics/?id=G-AAAAAAAAAA&cx=c>m=123&tag_exp=...
Next requests may vary depending on your setup and marketing products:
- https://demo.com/metrics/g/collect?v=2&dma=1&dma_cps=...
or:
- https://stats.g.doubleclick.net/g/collect?v=2&dma=1&...
- https://www.clarity.ms/tag/7gkmj15l3q
- https://d.clarity.ms/collect
As you can see, there are plenty of recognizable patterns ad blockers can target.
Looking at the huge EasyPrivacy filters list – which is included in nearly every ad blocker – you'll find that any URLs containing these patterns are typically blocked:
If not blocked by URL, the next easiest thing for an ad blocker is to cut out your GTM <script> tag from either HTML or JavaScript – so Google Tag Manager never even loads.
And this is just the tip of the iceberg. Dig a little deeper and you'll find much more sophisticated collections of rules capable of blocking nearly everything:
You'll also come across DNS-level filtering and other crawling tools used by the blocker ecosystem – and much more.
The ultimate takeaway:
- Even if ssGTM gets an update that lets you hide URL patterns, your tracking will still end up blocked – sooner or later.
- Your custom workarounds take time to implement, but they're only effective until discovered.
How to protect Google Tag Manager and Google Analytics from being blocked by ad blockers
If your use of GTM, GA, and your marketing stack complies with privacy standards and regulations (as explained earlier), you may just need to fix the technical side — namely, the blockers that prevent non-harmful tools from running on your front end. At the end of the day, it’s always up to you how you run your service.
DataUnlocker 2.0 solves exactly that – making your web app "unpatchable".
Before we dive into why its approach can withstand blockers, let me shed some light on the history of this product.
The history of DataUnlocker (1.0)
It all started with this article about avoiding ad blockers back in 2017. At that time, the solution was simply to create a proxy for Google Analytics – and it worked.
"Legacy" DataUnlocker 1.0, as I now call it, was released in 2021 after a small PoC gained popularity on GitHub. It was running really well – I applied it in a few companies I worked at that time. In about a year – with no marketing at all – we had 400 users on the platform and plenty of referral interest.
Approximately a year after the 1.0 launch, blockers figured out that they could simply "uninstall" DataUnlocker 1.0 from websites using some not-so-sophisticated patterns – just removing the <script> from the page.
Worse, they've got tools which were able discover DNS CNAME records pointing to DataUnlocker's proxy, exposing a small portion of the websites using our product.
Despite offering several installation options, some of our users unfortunately followed the simplest path to install DataUnlocker 1.0:
...which led to the problems described above. Most of the websites that used proper proxy-enabled installation methods remain undiscovered to this day.
Apart from being a great product, DataUnlocker 1.0 had many issues – it was primarily a "proof of concept," a quickly delivered product. It wasn't engineered to face blockers – let alone outlast them – but simply to hide traffic from them.
Playing the cat-and-mouse game quickly became infeasible, especially given the complexity of keeping analytics data unblocked across all websites. Customers either had to maintain the solution constantly – or give up and let it get blocked.
What changes the game in DataUnlocker 2.0
I took 2 years to build a beast – DataUnlocker 2.0.
Some might call it a real challenge to internet privacy (which I believe is unaffected), but it effectively does one thing:
turns your website into a "mobile app" that can't be tampered with
No one minds using mobile apps, right?
In other words, the new DataUnlocker gives developers a toolset to build protected web apps and data collection pipelines — and most importantly, without replacing your existing code, products, or beloved Google Tag Manager.
While similar solutions still play a cat-and-mouse game with ad blockers, we realized that the one thing blockers try to avoid at all costs is breaking the web app itself 💡
This turned out to be a very complex problem. You can't implement it in GTM – nor in any other third-party analytics product alone – because ad blockers will still find ways to circumvent it. Instead, you need to bake it into the web app itself, protecting the web app itself and enabling all third-party products to just do what they're supposed to.
That's how we ended up with DataUnlocker 2.0 – and a scalable approach. It makes your website work and collect 100% accurate data, even with blocker software installed.
DataUnlocker now deeply integrates with web apps. If it's attempted to be removed or tampered with, the web app becomes non-interactive:
None of your users will see this banner – even those using ad blockers. But it's a very important and necessary user experience compromise between the ad blocker (trying to "patch" your website) and the random user who may face this screen due to network glitches, for example.
This might look familiar to you – something you've already seen across the internet, like Cloudflare DDoS protection:
Unlike Cloudflare's screen that makes users wait 5 seconds, DataUnlocker's limited mode doesn't disturb users at all – not even those with ad blockers – unless they try to tamper with your app.
Read on to learn how it works, how to apply this to Google Tag Manager, and why it guarantees your data safety in the long term.
How DataUnlocker 2.0 protects your marketing and analytics products from ad blockers
DataUnlocker doesn't change how your web app runs, nor does it forcefully collect data – it simply protects your app from external interference and gives you tools to enforce that.
In its essence, DataUnlocker 2.0 creates a cryptographically protected network channel between your web app and your destination servers (such as your ssGTM, Google, or Facebook). It also binds critical browser APIs – such as network fetching, HTML element creation, etc. – to this channel, and prevents the web app from even starting if that networking layer is compromised.
Effectively, you can use DataUnlocker to protect any network requests end to end, making all your data fully first-party and eliminating third-party network requests.
In simple terms, DataUnlocker is a proxy that works like blockchain – cryptographically protected and immune to external manipulation. Your web application is programmed to securely communicate via this channel, and if that's not possible, it becomes non-interactive – which is exactly what blockers try to avoid.
So, blockers are left with a binary choice:
- Either block the entire web app (let it remain non-interactive)
- Or do nothing
DataUnlocker gives its users a full protection toolset. It notifies you when new filter rules are added against your domain, and it monitors and updates its protections in the background – no code changes required. Also, our support is always ready to help and assist live, if needed.
Just add your website to DataUnlocker – and you'll immediately see whether any filter rules are already targeting it. It's free.
Installing DataUnlocker
If you know what to do, you can install DataUnlocker in 5 minutes on your website.
- admin.dataunlocker.com provides guided instructions
- You can also follow this video tutorial and explore other materials
The steps are:
- Create a transport endpoint (a protected network channel)
- Integrate DataUnlocker Defender into your web application
- Configure protection for your resources
It's important to carefully follow the setup instructions and initial configuration – because if done incorrectly, blockers may be able to circumvent your protection in the future. Read more in this article.
As a result, you'll be able to configure a proxy for your ssGTM. On the DataUnlocker's Network Protection page:
- For third-party ssGTM, add a config for
your-prefix.yoursite.com - For first-party ssGTM, add a config for
yoursite.com/your-prefix
You can choose whether DataUnlocker will proxy these resources:
- On demand – only when an ad blocker is detected
- Always – after DataUnlocker loads and until the web page is closed
Both options provide solid protection. Follow the guides in the Admin UI to understand which mode best suits your case.
Final thoughts
DataUnlocker effectively makes your web analytics a dependency of your web application. In other words, your web app won't even run without analytics – and that's exactly what prevents blockers from stripping it away.
This benefit, however, comes with a few trade-offs you should consider:
- Network failures on protected resources proxied through DataUnlocker will trigger the web app's limited mode.
In practice, and at scale, it means that approximately 0.2% of your users may encounter your app in limited mode – typically due to random network issues. This is inevitable on the web – connection failures happen. Fortunately, users are generally trained to hit "refresh" when something doesn't load.
DataUnlocker gives you an option to reclaim that 0.2% of users by disabling end-to-end protection – but keep in mind that doing so opens a door: blockers may later create simple rules to filter tracking out of your web app again.
That said, we're continuously working to make DataUnlocker smarter – to handle slow or unstable connections without interruptions.
DataUnlocker also runs on Cloudflare – the world's largest and stable compute CDN – which guarantees its robustness and uptime.
Try it today even on a single page of your website – it's free.