Ad blockers don't just block tracking: They block cookie consent banners too

Ad blockers can prevent CMP scripts from loading entirely. When a Consent Management Platform (CMP) is blocked, the consent banner doesn't appear and the user's consent state is never recorded, and tags dependent on Consent Mode V2 fire in an undefined state. This creates both a GDPR compliance gap and a measurement gap.

This article covers what happens technically, what GDPR enforcement bodies require, and how server-side GTM with first-party CMP hosting removes the vulnerability.

In short: CMPs that load from a third-party CDN can be blocked by filter lists the same way any tracking script is. When that happens the banner never renders, no consent is recorded, and tags either fail to fire or fire without a lawful basis. Explicit Consent Mode V2 defaults fix the tag behaviour but not the missing consent record. The underlying fix is serving the CMP from a first-party subdomain so it isn't matchable by filter lists in the first place.

What happens when an ad blocker blocks your consent banner?

The sequence starts with the CMP script. Most CMPs (like Cookiebot, OneTrust, or Quantcast) deliver that script from a third-party CDN. Each provider uses CDN domains that are publicly known, consistent across thousands of implementations, and updated on predictable schedules.

That consistency is what makes them targetable. Filter lists work by matching request destinations against known domains. A CDN domain that appears across thousands of sites is exactly the kind of stable pattern filter list maintainers look for. EasyPrivacy, uBlock Origin's privacy filters, and several browser-native blockers already include common CMP CDN domains.

When a visitor with one of those blockers active lands on a page, the browser requests the CMP script. The blocker intercepts it. The script never loads. The page renders without a consent banner.

The visitor sees the page normally. Nothing appears broken. On the site's side, there is no consent state recorded for that session.

What happens next depends on how the tag setup handles an absent consent signal: 

• Tags configured with Consent Mode V2 wait for a signal that never arrives.
• Tags with fallback defaults operate on whatever those defaults were set to.
• Tags with no explicit consent configuration may fire without a lawful basis.

In all three cases, the user was never shown a banner. There is no record of a decision.

What Consent Mode V2 does when consent is undefined

Google's Consent Mode V2 controls tag behaviour through per-category signal states:

analytics_storage, ad_storage, and ad_personalization. Each category gets set to either granted or denied. Tags listen for the relevant signal before acting.

When the CMP is blocked, no signal fires. The tag does not receive denied and hold. It does not receive granted and does not fire. It falls through to its default state, a configuration that lives in the GTM container, usually inside a tag template or an initialisation block.

Some setups skip explicit defaults entirely. The assumption is that the CMP loads fast and fires a signal before any tag acts. That assumption works when the CMP loads.

Platform behaviour in the undefined case is often not what teams expect:

• GA4: an undefined state may allow modelling signals to pass through.
• Advertising tags: partial firing in an undefined state can register an event that feeds attribution.
• Some tag templates: the absence of an explicit denial is treated as granted.

The result is measurement data that cannot be attributed to a verified consent record.

Why this is a GDPR compliance problem, not just a UX problem

GDPR Article 7 puts the burden of proof on the controller. Consent must be freely given, specific, informed, and unambiguous. When challenged, the controller must be able to demonstrate that consent was given, with records, for that session.

A blocked CMP leaves the controller with no evidence: no record of the banner rendering, no record of the user responding.

Regulators have not ruled specifically on blocked CMPs. What they have established is that a malfunctioning consent mechanism is the controller's problem, not an excuse.

The Dutch DPA has issued formal warnings to more than 200 websites over cookie banners and stepped up monitoring through 2026, and fined Kruidvat €600,000 for pre-ticked consent boxes. Independent audits have found similar problems on sites already running established CMPs — broken opt-out buttons, non-functional preference centres, banners that fail to block scripts — which suggests deploying a recognised tool is not by itself the end of the obligation.

France's CNIL fined Criteo €40 million in 2023 for consent management failures that included incomplete consent records. Criteo is an adtech vendor rather than a publisher, so the circumstances differ, but the finding that mattered was the failure to demonstrate valid consent. That is the same gap a blocked CMP creates, arriving by a different route.

The pattern is that the obligation attaches to whether consent was validly collected and recorded, not to whether your vendor's script happened to reach the browser.

Sending nothing by default is the correct compliance posture. Combined with a blocked CMP, it's also the configuration that quietly costs you the most data, because those sessions go dark without anyone choosing that outcome.

This is also worth getting right before the rules shift. The EU's Digital Omnibus, proposed in November 2025, would move rules on storage and access on terminal equipment into a new GDPR Article 88a where personal data is involved, and introduces changes around consent mechanics including single-click accept and reject. It's still in negotiation, with adoption unlikely before late 2026 and application in 2027 at the earliest. Current ePrivacy and GDPR rules continue to apply. But every version of the proposal assumes a consent layer that actually reaches the user, which is the part a blocked CMP fails at regardless of which rulebook applies.

The data loss, and who it actually affects

The compliant path has a real cost. Sessions where the CMP was blocked generate no attribution data, no conversion signals for ad platforms, and no GA4 events.

The scale depends on the audience. Approximately 30% of internet users globally use some form of ad blocker (GWI, 2025). For technical audiences (developers, marketers, analytics professionals) the share is higher.

Most of those users are not blocking measurement intentionally. GWI's data shows the most common reasons are too many ads (63.5%) and ads interfering with browsing (53.5%), with privacy concerns cited by 42.4%.

That distinction matters. Most users with an ad blocker installed are not opting out of analytics. They want fewer ads and faster page loads. If a consent banner reaches them, many will accept it, and their data flows with a lawful basis.

The sessions that remain dark are those where the banner never appeared, not because the user declined, but because the consent mechanism failed.

Fixing CMP delivery recovers those sessions.

How to check whether this is happening on your site

Three checks, in order of effort.

Test it yourself. Install uBlock Origin with default lists, or enable EasyPrivacy, and load your own site in a clean browser profile. If your banner doesn't render, you've reproduced the problem in under two minutes. Repeat with a couple of common blockers, since filter lists differ.

Compare consent records against sessions. Pull your CMP's consent log count for a period and compare it against total sessions for the same period in your analytics. The two will never match exactly, since not every session reaches the banner. A persistent gap well beyond that is the signal.

Check your CMP's script origin. Look at where your consent script loads from. If it's a domain belonging to your CMP provider rather than a subdomain of your own site, it's matchable by filter lists. Most CMPs support first-party hosting as a configuration option, but it usually isn't the default.

How server-side GTM removes the consent banner vulnerability

The root of the problem is where the CMP script is hosted. A third-party CDN has a fixed, known domain. That domain appears in filter lists. Any CMP delivered from a well-known CDN is a stable target.

Hosting the CMP script on a first-party subdomain changes that. The subdomain belongs to the site. It does not appear in generic filter lists targeting CMP providers. A blocker cannot match against it without also blocking the site's own first-party assets, which most filter lists specifically avoid.

When the browser requests the CMP script from a domain the site controls, the script loads. The banner renders. The user sees the prompt, and a consent signal goes out before any tags have fired.

This is the same infrastructure principle described in the article Why Server-side Tracking can still lose data (and how the Enhanced Tracking Script fixes it). There, moving the tracking request to a first-party endpoint prevented blockers from matching it against known analytics CDN patterns. Applied to the consent layer, the same server-side setup protects a different piece: the CMP reaches the browser instead of being intercepted before the banner can appear.

Server-side GTM can handle CMP delivery as part of a broader first-party setup. When the CMP script is served from the same subdomain as the server container, the consent signal reaches the container before any measurement or advertising tags fire.

The TAGGRS dashboard can help verify this is working. Under server-side analytics, check whether consent-gated tags are firing in sessions with no recorded CMP request. That pattern, events active but no CMP call visible, means the consent banner is not reaching part of the audience.

If your CMP is loading from a provider CDN, moving it behind your own subdomain is the fix. Install the TAGGRS Enhanced Tracking Script to serve both your consent layer and your tracking requests from a first-party endpoint.

What a resilient consent setup requires

1. Host the CMP script on a first-party subdomain. Remove the fixed CDN domain from the equation. Filter lists cannot silently block a subdomain the site controls.

2. Set explicit Consent Mode V2 defaults for all regions. Every tag in the container must have a defined behaviour for the case where no consent signal has fired. No tag should operate in an undefined fallback state.

3. Fire consent banner tags first in the GTM container. Configure the consent initialisation block to execute before any measurement or advertising tag. The signal must exist before anything acts on it.

4. Verify through the TAGGRS dashboard. Check that consent-gated tags are not firing in sessions where no CMP request is recorded. Catch gaps before they appear in an audit.

5. Document the consent architecture. Record the CMP provider, the hosting path, and the explicit default states for each region and tag category. When a regulator requests evidence, documentation is the first thing a controller produces.

Most of this list is configuration you can do in an afternoon. The one piece that needs infrastructure is first-party CMP delivery, because it depends on serving the script from a domain you control.

Create a free TAGGRS account to set that up, or run a free audit to see which of your scripts are currently exposed to filter lists.

FAQ

Can ad blockers block any CMP, or only specific platforms? 

Any CMP that delivers its script from a third-party CDN is exposed. Default installations of Cookiebot, OneTrust, and Quantcast all load the script from the provider's own infrastructure. CMPs that support first-party hosting as a configuration option are not inherently affected, but the feature must be actively enabled.

How do I know if my consent banner is being blocked for some visitors?

The clearest signal is a mismatch between server-side request volume and CMP consent log entries. If the server container receives requests in sessions where no consent signal appears in the CMP records, the banner likely did not load for those users. The TAGGRS dashboard makes this visible through request categories. You can also test directly by enabling a common filter list in a browser and checking whether your own consent banner renders.

Is setting Consent Mode V2 defaults to "denied" enough to stay GDPR compliant when a CMP is blocked?
It handles tag behaviour correctly, but it does not fix the root problem. Setting defaults to denied means tags will not fire in the undefined state, which is the right configuration. What it cannot do is show users a banner they were never given. A regulator asking to see evidence of consent for a specific session will not find it. The defaults address compliance at the tag layer. First-party CMP hosting addresses compliance at the consent collection layer.

What is the difference between a blocked consent banner and what the Enhanced Tracking Script protects against?
The Enhanced Tracking Script protects the tracking request after consent has been collected. It prevents ad blockers from intercepting the browser-to-server event before it reaches the server container. A blocked consent banner is one step earlier: the user was never shown a prompt, no consent signal was ever recorded, and any tags that fired did so without a lawful basis. The two problems share the same infrastructure fix (first-party delivery) but sit at different points in the data flow. TAGGRS’ Enhanced Tracking Script is a perfect tool to hide the CMP from adblockers and properly load a cookie banner via the server GTM container. 

Does Consent Mode V2 work if the CMP never loads?
No. Consent Mode V2 is a signalling framework, not a consent collection mechanism. It controls how tags behave once a signal arrives. If the CMP never loads, no signal is sent, and tags fall through to whatever default state is configured in the container. If no defaults were set, behaviour varies by platform and some tag templates treat the absence of a denial as permission.

Can I just host my CMP script myself?
Most CMP providers support first-party hosting, either through a CNAME record pointing a subdomain of your site at their infrastructure, or by serving the script from your own server. It is rarely the default installation, so it usually has to be enabled deliberately. Check your provider's documentation for first-party or custom domain setup.