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.

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. Three EU enforcement bodies have addressed this directly:

1. The Dutch DPA (Autoriteit Persoonsgegevens) has stated that tracking without a valid consent record violates GDPR, regardless of what caused the consent mechanism to fail. Technical failures in the consent flow do not transfer responsibility away from the controller. (Source: autoriteitpersoonsgegevens.nl)
2. France's CNIL has published guidance that consent must be collected before any personal data is processed, and that organisations are responsible for ensuring their consent mechanisms actually function. Tags firing in an undefined fallback state fall outside that standard. (Source: cnil.fr)
3. Germany's DSK (Datenschutzkonferenz) has reinforced that consent-dependent processing must be verifiable and reproducible. Sessions that proceed without a consent record do not meet that requirement. (Source: datenschutzkonferenz-online.de)

All three bodies have cited consent flow reliability in active enforcement cases.

The only way to ensure compliance is to send nothing by default. It’s a golden path on the tracking and analytics market, but in conjunction with adblockers, it can cause real harm to your data. 

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 2025 research shows that only 26.6% of ad blocker users globally cite "stopping data collection" as a reason for using one. The majority (63.5%) say there are too many ads. Another 53.5% say ads interfere with browsing, according to Backlinko, 2025.

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 silently.

Fixing CMP delivery recovers those sessions.

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.

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.

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.