Tags Still Firing After "Reject All"? A 6-Step Cookie Banner + GTM Consent Audit (2026)
When trackers fire after "Reject All", the banner is rarely the problem. The banner works; Google Tag Manager was never told about it. Here is the audit I run, in order, to wire a cookie banner into GTM properly.
Step 1: Find out where the banner is loaded
Before touching a single tag, find out whether the cookie banner (the CMP) is hardcoded in the website or loaded through GTM. Everything else depends on it.
How to check:
- Open the page source (Ctrl+U / Cmd+Option+U) and search for the CMP's name:
iubenda,cookiebot,otSDKStub(OneTrust),usercentrics,cookieyes,complianz. If the script sits in the<head>, above the GTM snippet, it's hardcoded. - Open the GTM container and search the tags for the same names. A CMP template firing on the Consent Initialization - All Pages trigger means it's loaded through GTM.
- Write down who owns it. A hardcoded banner is usually owned by the dev team, and the GTM tags by marketing. That split is where most consent bugs come from.
| Hardcoded in the site | Loaded through GTM | |
|---|---|---|
| Owned by | Developers | Marketing / tracking team |
| Loads before GTM | Yes | No, GTM loads first |
| Can keep GTM off until consent | Yes | No |
| Changing it | Needs a code release | Publish in GTM |
Why many businesses keep the banner out of GTM. On 19 March 2025 the Administrative Court of Hannover (VG Hannover, 10 A 5385/22) ruled that loading GTM itself needs consent. The reason: the GTM request sends the visitor's IP address and device details to Google before they've made any choice. It's one German court, not an EU-wide rule, but German legal teams now often ask for the banner to load first and GTM only after consent. You can't do that if the banner lives inside GTM.
There are other reasons too: the CMP's auto-blocking has to run before any other script, the banner shows faster, and it still works when an ad blocker kills GTM.
The catch. A hardcoded banner, even with auto-blocking, often doesn't reliably catch the scripts GTM adds after the page loads. So the banner can work perfectly while GTM keeps firing Meta, LinkedIn and friends after "Reject All". GTM has to be told about consent separately, which is what the next steps do.
This isn't legal advice. Check with the client's legal team before deciding whether GTM needs to wait for consent.
Step 2: Check the dataLayer and GTM Preview
Next, confirm the banner actually talks to Google's Consent Mode. Open GTM Preview, load the site in a fresh incognito window, and look at three things.
- The event list on the left. You want to see Consent Default near the top, before the first Container Loaded, and Consent Update once a choice is made. These names are examples: what you actually see depends on your CMP and how it sends consent. OneTrust, Cookiebot, iubenda and others label these events differently, so look for your CMP's default and update events in the same places.
- The CMP's own event. Most CMPs can push their own dataLayer event when consent changes. iubenda pushes
iubenda_gtm_consent_event(when GTM events are enabled in its config); OneTrust pushesOneTrustGroupsUpdated. Check your CMP's docs for its event name. You'll need it in step 5. - The Consent tab. Click any event, then Consent. It shows the default, the update and the current state of
ad_storage,analytics_storage,ad_user_dataandad_personalization.
| What you see in Preview | What it means | Next step |
|---|---|---|
| Consent Default before Container Loaded, Consent Update after a choice | The CMP sends Consent Mode correctly | Go to step 3 |
| Consent Update lands after Container Loaded | Normal for many CMPs, but tags on page load check consent too early | Fix the timing (step 5) |
| "Consent not configured" on the Consent tab | The CMP isn't sending Consent Mode at all | Turn on Google Consent Mode in the CMP, or add the CMP's GTM template, before anything else |
| No CMP event in the list | The CMP isn't pushing its own event | Turn it on in the CMP settings |
One thing worth knowing: if no consent default is ever set, Google treats every consent type as granted. "Not configured" doesn't mean "blocked". It means everything fires.
Step 3: Turn on Consent Overview in GTM
Consent Overview is one screen showing every tag's consent setting, and it's off by default.
- Go to Admin → Container Settings → Additional Settings and tick Enable consent overview. Save.
- Go to Tags and click the shield icon at the top right of the tag list.
- You'll see two groups: Consent Not Configured and Consent Configured. Tick several tags at once and set their consent in bulk.
Each tag gets one of three settings under Additional consent checks:
| Setting | What GTM does | Use it for |
|---|---|---|
| Not set | Nothing; the tag shows up as unconfigured | Nothing. This is the state you're cleaning up |
| No additional consent required | Fires normally | Tags that read Consent Mode themselves, and helper tags (listeners, dataLayer pushes) that don't set cookies |
| Require additional consent for tag to fire | Fires only if every listed consent type is granted at the moment it's triggered | Meta, LinkedIn, TikTok, Attentive, chat widgets and any other third-party pixel that ignores Consent Mode |
The goal is simple: zero tags left under Consent Not Configured.
Step 4: Google tags — let Consent Mode do the work
Google's own tags already follow Consent Mode. In Consent Overview these tags show built-in consent checks: GA4 (the Google tag and GA4 events), Google Ads conversion and remarketing, Floodlight and the Conversion Linker.
With consent denied, they still load, but they set no cookies and send only cookieless pings. Google uses those pings to model the conversions you'd otherwise lose. When the visitor accepts, the same tags start using cookies on their own, with no re-firing needed.
The four consent types they listen to:
| Consent type | What it controls |
|---|---|
ad_storage | Advertising cookies, like _gcl_au |
analytics_storage | Analytics cookies, like _ga |
ad_user_data | Sending user data to Google for ads, including enhanced conversions |
ad_personalization | Remarketing and personalised ads |
What to set:
- Native Google tags (GA4, Google Ads, Floodlight, Conversion Linker): No additional consent required.
- A custom HTML tag that loads gtag.js: same thing, because gtag.js reads Consent Mode itself. Better still, swap it for the native Google tag template.
- Don't tick Require additional consent on Google tags in this setup. It blocks them completely, so the cookieless pings stop and conversion modeling goes with them.
Advanced vs basic mode. Everything above is Google's advanced Consent Mode: tags load before a choice and send cookieless pings. If the legal team wants basic mode (nothing reaches Google before the visitor chooses, the stricter reading behind the Hannover ruling), then Google tags must be blocked too: set Require additional consent on them with the types in the cheat sheet below. You lose the pings and the modeling. That trade-off is a legal decision, not a tracking one.
One more thing: ad_user_data and ad_personalization are the Consent Mode v2 types. If your CMP only sends ad_storage and analytics_storage, update it. Google needs all four for EEA ad features.
Step 5: Meta and every other non-Google tag
Meta, LinkedIn and TikTok don't read Google Consent Mode. For these, GTM has to block the tag itself, with Require additional consent for tag to fire, using the consent types in the cheat sheet below. Microsoft UET is the exception: its official GTM template now reads Consent Mode, so it can be treated like a Google tag.
The timing trap
This is the one most setups miss. Many CMPs send the consent update after GTM's page-load triggers have already fired. A tag on All Pages checks consent too early, sees "denied", and gets blocked. GTM never tries it again. So the visitor clicks Accept and that page gets no Meta PageView.
For Google tags, the fix is on the consent default: set wait_for_update (for example 500 ms) so they wait for the CMP's update before sending anything. Most CMP templates have a field for it.
For every blocked non-Google tag that runs on page load:
- Create a Custom Event trigger with the event name of your CMP's event (e.g.
iubenda_gtm_consent_event). - Add it to the tag next to All Pages.
- In Advanced Settings → Tag firing options, choose Once per page.
"Once per page" is what stops duplicate page views. A returning visitor who already accepted gets the tag on page load, and the CMP event is skipped. A new visitor is blocked on page load and gets the tag once when they click Accept.
Tags on later events, like purchase or form submit, don't need this. Consent is already known by the time they fire.
Meta's own consent switch
Meta also has its own consent API. Call fbq('consent', 'revoke') before fbq('init'), then fbq('consent', 'grant') when the visitor accepts. The pixel loads but holds its events until consent is granted. It's handy when you want the pixel ready the moment someone accepts. For strict GDPR sites, blocking the tag in GTM is cleaner, because Meta's script never loads at all.
If you also send events server-side (Meta CAPI), check consent there as well. Blocking the browser pixel doesn't stop the server from sending. I cover that side in consent-compliant server-side tracking.
Cheat sheet: which consent each ad platform needs
This is the table I start every container audit from. "Reads Consent Mode" means the tag changes its own behaviour based on the consent state, so GTM doesn't need to block it in advanced mode.
| Tag | Reads Consent Mode itself | Consent types it depends on | GTM setting (advanced mode) |
|---|---|---|---|
| Google Ads conversion tracking | Yes | ad_storage, ad_user_data | No additional consent required |
| Google Ads remarketing | Yes | ad_storage, ad_user_data, ad_personalization | No additional consent required |
| Google Ads enhanced conversions | Yes | ad_user_data | No additional consent required |
| Conversion Linker | Yes | ad_storage | No additional consent required |
| Floodlight | Yes | ad_storage, ad_user_data | No additional consent required |
| GA4 (Google tag and events) | Yes | analytics_storage (plus the three ad_* types for Google signals and ads features) | No additional consent required |
| Microsoft UET (official template) | Yes, via UET Consent Mode | ad_storage | No additional consent required; check the template's consent settings |
| Meta Pixel (base and events) | No | ad_storage, ad_user_data | Require these |
| TikTok Pixel | No | ad_storage, ad_user_data | Require these |
| LinkedIn Insight and conversions | No | ad_storage | Require this |
| No | ad_storage | Require this | |
| SMS and email tools (Attentive, Klaviyo) | No | ad_storage, ad_user_data | Require these |
| Heatmaps (Hotjar, Clarity) | No | analytics_storage | Require this |
In basic mode, every row gets Require additional consent with the types in the third column, Google and Microsoft included.
For the rows marked "No", the consent types are my recommended mapping, not an official requirement from Meta, TikTok or the others: those platforms don't use Google's consent types at all. Match them to the categories in your CMP.
Microsoft has required consent signals for UET traffic from the EEA, UK and Switzerland since 5 May 2025. Unlike Google, it only models lost conversions if you run its Advanced Consent Mode, where UET loads before the choice and stays cookieless until consent is granted.
These requirements keep changing. Google, Meta and Microsoft revise their consent rules and GTM templates regularly; Microsoft's UET template, for example, only recently started reading GTM Consent Mode. This table reflects the platforms' documentation as of September 2026. Check each platform's current docs before you copy it into a live container, and use it at your own risk.
Step 6: Test it like a regulator would
Don't trust the settings screen. Test in an incognito window with GTM Preview on, DevTools open, and the Application → Cookies and Network tabs ready.
| Scenario | What should happen |
|---|---|
| Reject All | No _fbp, li_*, _uet*, _ttp cookies; no requests to facebook.com or linkedin.com. Google tags (and UET in advanced mode) send cookieless requests only |
| Accept on first visit | Blocked tags fire once, on the CMP event, right after the click |
| Reload after accepting | Tags fire once on page load, and are skipped on the CMP event |
| No choice yet | Same as Reject All |
| A conversion after accepting | Purchase and lead tags fire, with the right values |
The trap outside your site: booking engines and checkouts
If the funnel moves to another domain (a hotel booking engine, a hosted checkout, a Shopify store on its own domain), the consent choice doesn't follow. It's saved on the main domain, and the other domain can't read it.
If that domain has no banner of its own, GTM sees no consent state at all, treats everything as granted, and fires every tag, including for people who rejected on the main site. You can't fix this from GTM alone. Forcing tags off there kills all conversion tracking. The other domain needs its own banner, ideally sharing the choice from the main site. Check it with the same Preview test: open the Consent tab on the booking or checkout pages and see if it says Consent not configured.
Need a hand?
Most consent setups I audit have the same gaps: a hardcoded banner nobody wired into GTM, pixels with no consent setting, the timing trap, and a checkout domain with no banner at all. If trackers are firing after "Reject All" on your site, or you're not sure, book an audit. I'll go through the container and send you a fix list. Consent setup is part of every GTM implementation I do.
Sources
- Tag Manager consent mode support — Google (Consent Overview, built-in and additional consent checks, Consent Initialization trigger)
- Consent mode overview — Google (basic vs advanced mode, the four consent types)
- Set up consent mode on websites — Google (
wait_for_update, setting the default before measurement) - Consent mode reference — Google Ads (tag behaviour per consent type)
- Custom template APIs: isConsentGranted — Google (a consent type that's not set counts as granted)
- Google Tag Manager template: Consent mode — Microsoft (UET template reading GTM consent,
ad_storage) - Providing user consent signals on your Microsoft campaigns by May 5, 2025 — Microsoft Advertising
- Advanced Consent Mode — Microsoft Advertising (conversion modeling for UET)
- Meta Pixel: General Data Protection Regulation — Meta (the consent revoke/grant API)
- VG Hannover, 19.03.2025 – 10 A 5385/22 — the German ruling
- Does Google Tag Manager require user consent? — Didomi's summary of the ruling
For Hands-On Implementers
Stuck on this? Get it fixed live on a call.
1-hour screen-share debug session with a senior tracking engineer — bring your broken GTM, sGTM, or GA4 setup and leave with it working. $150 USD. If we can't help in the first 10 minutes, full refund.
Need Expert Help With Your Tracking Setup?
We handle complex tracking implementations so you can focus on growing your business.