The Google Tag Manager trigger mistake behind most cookie consent leaks

You install a consent tool. The banner looks right, it has an "Accept" and a "Reject" button, and Tag Manager's preview shows your tags firing. And yet the site sends data to Google and Meta before anyone has clicked anything.

On the sites we look at closely, the cause is rarely the banner itself. It is usually a trigger in Google Tag Manager.

What our scan showed

In October 2026 we scanned 23,367 small-business websites in seven EU countries with a real Chromium browser and recorded what loaded before any consent choice and after a click on "Reject":

• 9,329 sites ran Google Analytics, Tag Manager or Google Ads.
• On 66.7% of them (6,219), we saw no Consent Mode default at all. Only 24.7% started with consent denied, which is the correct setup.
• 4,309 sites fired Google Ads before consent, and 69.7% of those sent no Consent Mode signal.
• On the 3,514 sites whose banner had a first-layer "Reject" button, Google Analytics/GTM kept firing after Reject on 231 sites, and the Meta Pixel on 381.

A scanner can't look inside a GTM container, so we can't say how many of these come from triggers specifically. But when we dig into sites like these, "the tag fires on All Pages and nobody told it about consent" is one of the most common answers.

GTM doesn't know about consent unless you tell it, per tag

Installing a consent tool doesn't make every tag inside Tag Manager respect it. Most consent tools integrate with GTM in one of two ways:

1. They push the consent state into the dataLayer, and you use it in trigger conditions.
2. They set Google's Consent Mode (ad_storage, analytics_storage, ad_user_data, ad_personalization), which Google's own tags read through GTM's built-in consent checks.

Either way, the gating is opt-in per tag, not a container-wide default. A tag added without that condition, by anyone, at any point, fires unconditionally.

There is a second trap. Consent Mode is understood by Google's tags. A Custom HTML tag with the Meta Pixel, Hotjar, Microsoft Clarity or the TikTok Pixel doesn't read it on its own. Those tags need either an explicit consent requirement in their settings or a trigger that checks your consent tool's variable.

Three ways a tag quietly loses its consent condition

• A new tag is added by a marketer or an agency who copies an existing tag, but not its trigger condition.
• A tag is duplicated for an A/B test or a staging setup, and the copy keeps the default "All Pages" trigger.
• Consent settings were added only to the tags created after consent handling was set up. The older tags were never updated.

None of these produce an error. The tag fires, which is exactly what a tag with a met trigger is supposed to do. GTM has no way of knowing that a condition is missing.

Why Preview mode won't catch it

Tag Assistant shows what fires and when. The trap is the state of your browser: if you have ever clicked "Accept" on that site in that profile, the consent cookie is already there, and everything looks correctly gated. The test only means something from a clean, no-consent state.

A 10-minute audit

1. Watch the network from a clean state. Open a private window, open DevTools → Network, tick "Preserve log", load the site and touch nothing. Filter for:

google-analytics.com   googleadservices.com   doubleclick.net
connect.facebook.net   clarity.ms   hotjar.com   analytics.tiktok.com

Anything that shows up here fired before consent.

2. Check what consent state the page starts with. In the console:

dataLayer.filter(e => e && e[0] === 'consent')

You want to see a default entry with the four parameters set to denied, pushed before your tags run, and an update entry only after the visitor accepts. An empty result means no Consent Mode. A default of granted is worse than nothing: it tells Google that consent was given.

3. Click "Reject" and test again. Clear the log, click "Reject all", then open two or three more pages. Anything from the list above that appears now ignored the refusal.

4. Look at the container itself. In GTM, turn on the consent overview (Admin → Container Settings → enable consent overview). The Tags list then shows which tags have consent settings and which don't. Go through every tag that isn't configured.

The fix

• Google tags: set a Consent Mode default of denied (most consent tools ship a GTM template that does this on the Consent Initialization trigger) and update it only when the visitor accepts.
• Non-Google tags: under the tag's consent settings, require additional consent (for example ad_storage for an ad pixel, analytics_storage for session recording), or add a trigger condition on your consent tool's variable. Copy whatever pattern your correctly gated tags already use.
• Hard-coded snippets: if the same pixel is also pasted into the theme header or a "custom code" field, remove that copy. GTM can only gate what goes through GTM.
• Test both paths after every change: tags fire after "Accept", nothing fires after "Reject", across several pages.

Once a missing condition is found, the fix itself is usually a couple of minutes per tag. Finding it is the hard part, which is why the clean-state test matters more than reading the container.

What our scan can't see

The sample came from website links on public Instagram business profiles in seven EU countries, so it leans toward consumer-facing small businesses and isn't a random sample of the web. We loaded the homepage and up to two more pages; trackers that fire deeper in a site, or server-side, don't show up. None of this is a legal assessment of any site, and we name none.

This article first appeared on the Bannerproof blog. Bannerproof runs the clean-state and Reject tests above automatically: you can check a site for free at bannerproof.app. The full study is here.