Which Consent Signals Should You Use for Additional Consent Checks in GTM?
A plain guide to Google Consent Mode’s seven signals, GTM Additional Consent Checks, and why adding extra checks to Google tags can break tracking.
6 min readBranislav Mateas
Copy post as Markdown
On this page
Consent Mode is a set of permissions, not a cookie banner
Here is my blunt take: most confusing Google Consent Mode setups start with the wrong mental model. People treat its consent types as seven kinds of tags. They are not.
A consent type is a signal about what the visitor has allowed. A tag can read that signal and change its behaviour. Google Tag Manager can also use the same signal as a gate that stops a tag from firing. Those are two different jobs, and mixing them up causes a surprising amount of broken tracking.
GTM exposes seven relevant consent and storage types. The first four are the core Google Consent Mode parameters. Functionality, personalisation, and security storage are broader privacy types available for tag control. The difficult part is deciding which tags should merely read them and which tags must be blocked by them. Google documents the distinction here.
What do the seven consent types actually mean?
The names describe purposes, not specific tools. Map them to what a tag really does, and to the categories in your CMP.
analytics_storage allows analytics-related storage. Require it for a third-party measurement tag that reads or writes analytics identifiers and does not handle consent itself.
ad_storage allows advertising cookies or device identifiers. Require it for a non-Google advertising or retargeting pixel that would otherwise access that storage as soon as it loads.
ad_user_data covers sending user data to Google for advertising. Use it as a gate for custom code that sends user-provided data to Google Ads. Do not use it as a generic name for data sent to Meta, TikTok, or another vendor.
ad_personalization covers using data for personalised advertising, including remarketing. Require it when a consent-unaware tag activates that purpose. Native Google Ads tags already understand it.
functionality_storage covers storage used by optional site features, such as remembered language or player settings. Require it when the feature should wait for the corresponding CMP choice.
personalization_storage covers stored preferences used to tailor content, products, or recommendations. Require it for a personalisation tool that cannot suppress this behaviour itself.
security_storage covers authentication, fraud prevention, and user protection. Essential security tools often need to run regardless of optional consent, so add this gate only when your policy truly makes that storage conditional. Never use the label to disguise marketing.
Required Additional Consent Checks are a firing gate
Now we get to the GTM setting that causes the trouble. In a tag’s Consent Settings, built-in consent checks show which signals the tag already understands. Required Additional Consent Checks are different. They tell GTM that the tag may fire only when the selected consent types are granted.
If you require several consent types, every selected requirement must be granted. This makes the setting useful for tags that do not understand Consent Mode themselves. A third-party heatmap tag, for example, may set analytics cookies as soon as its script loads. Requiring analytics_storage can stop that script until analytics consent exists.
The interface also offers “No additional consent required.” That does not mean consent is irrelevant. It means GTM should not add another firing condition beyond any consent logic already built into the tag.
Why Google tags usually need no additional checks
Google tags that support Consent Mode already have built-in consent checks. They read the relevant signals and adjust what they store or send. Google Tag Manager Help therefore says Google tags normally do not need Additional Consent Checks.
This distinction matters because Consent Mode can be implemented in two broad ways. With a basic setup, tags wait for consent before loading. With an advanced setup, supported Google tags can load while consent is denied and send limited, cookieless signals. They then change behaviour after consent is granted.
If you add analytics_storage as an extra firing requirement to a Google Analytics tag, GTM may block the tag completely while consent is denied. The tag never gets the chance to apply its built-in denied-state behaviour. You have not made its internal checks stricter. You have changed the implementation from “fire and adapt” to “do not fire.”
Sometimes that is intentional. Your legal interpretation, company policy, or CMP design may require a basic implementation. Fine. But make that decision consciously. An extra check is not a harmless checkbox, and Google’s built-in checks are not permission to ignore consent law.
A practical rule for choosing the setting
For a supported Google tag, I normally keep “No additional consent required” and let its built-in checks handle the state. For a custom HTML or third-party tag without built-in support, I identify its actual storage and data uses, then add the minimum consent requirements that match them. For a tag that is strictly necessary, I document why it is necessary instead of hiding it under security_storage.
In practice, a heatmap or session-recording tag commonly maps to analytics_storage. A third-party advertising pixel commonly maps to ad_storage and may also need ad_personalization. A recommendation engine commonly maps to personalization_storage. A preference widget may map to functionality_storage. These are starting points, not vendor verdicts. Read what the specific tag stores and sends.
Once per page can swallow the consent update
An Additional Consent Check is evaluated when a trigger event occurs. If a tag is blocked on All Pages because consent is denied, granting consent later does not replay that old event. The tag needs another trigger, usually the CMP’s consent-update event after it has updated the consent state.
This is where GTM’s Tag firing options matter. “Once per page” allows one attempt across the page, while “Once per event” allows one attempt on each data layer event. In practice, a consent-blocked attempt can consume the Once per page allowance. A tag with both All Pages and consent_update triggers may therefore be blocked at page load and remain silent after the visitor grants consent.
For this pattern, use Once per event and trigger the tag again on the CMP event emitted after the consent update. The denied page-load attempt can fail, while the later event gets a fresh check. But Once per event is not a deduplication system for the whole page. If the CMP pushes several update events, the tag can run on each one. Restrict the trigger to the granted state, emit one deliberate post-update event, or make the vendor loader safe to initialise more than once.
Once per page is still fine when consent is already restored before the tag’s first trigger and the library genuinely needs to load only once. Test both cases: a returning visitor whose choice is known on load, and a new visitor who grants consent without reloading the page.
The main takeaway is almost boring: built-in checks control behaviour inside a supported tag, while Additional Consent Checks control whether GTM lets the tag fire at all. Once you keep those two layers separate, the seven consent types become much easier to use.
