Why tags gated on functionality_storage never fire
The tag fires only if every signal it requires reads granted when its trigger fires. A consent setup can deny functionality_storage and personalization_storage by default, then update only the four signals Google’s ad and analytics tags read. The two stay denied even after someone accepts. Map them in your banner, or require a signal that updates.
Start with a scan.
The free scan reads your homepage HTML and public Tag Manager container, and lists the tracking tags it finds.
Free · No signup · HTML and public GTM checks
What are functionality_storage and personalization_storage for?
Google’s consent mode overview lists seven consent types. It describes how tags respond to four of them: ad_storage, analytics_storage, ad_user_data and ad_personalization. The other three are defined by purpose. functionality_storage covers things like language settings, personalization_storage covers things like video recommendations, and security_storage covers authentication and fraud prevention.
So these two usually matter for one reason: someone named them on a tag. In Tag Manager, a chat widget or a recommendation script can carry an additional consent check under Consent Settings. Google’s rule for that check is strict. The tag fires only if every type on its list reads granted when the tag is triggered.
Why does the tag stay blocked after someone accepts?
Because accepting the banner and updating the signal are two separate events. On a consent remediation we audited in August 2026, the page set six signals to denied by default and left security_storage granted, which is normal. The consent platform’s configuration then updated the Google advertising and analytics signals and nothing else. A chat listener gated on functionality_storage never ran, even for visitors who clicked accept. Nothing reported a fault, because a blocked tag is what a consent setup is supposed to produce.
The check reads the state at that moment.
Which setups cause it?
- The update only names the Google signals. This is the case above, and the first one to rule out.
- The name is misspelt in the update. In a hand written update, a typo creates a different consent type, and the real one stays at its default.
- The banner has no matching category. With no functional or personalisation choice to offer, a platform has nothing to send for that signal, unless it maps another category to it.
- The visitor did not choose that category. Someone who accepted analytics only should leave the tag blocked. That is the setup working.
- The trigger only ran before the choice. We read the Tag Manager runtime in November 2026: a failed check ends that attempt, and nothing retries it when consent changes. The tag needs a trigger that runs after the update, which the post on the consent update event covers. If it also fires once per page, read the note on blocked attempts first.
The opposite fault is worth checking at the same time. Google’s template API documentation treats a consent type that was never set as granted, and the runtime applies the same logic to additional consent checks. If your default command leaves out these two signals, a tag gated on one of them can fire before the visitor has chosen anything.
How do you find out which one you have?
Accept everything in Tag Assistant
Open your site in Tag Assistant on a fresh browser profile and click Accept all. Accepting everything removes the visitor’s choice as a possible cause.
Read the signal after the choice
In the Summary, select the latest Consent event and open the Consent tab. Compare the default and update columns for the signal your tag requires. If the tab does not list it, run
google_tag_data.ics.entriesin the console. It is an internal object and can change, but it shows the default and update Google has stored for each type.Name the cause
Denied by default with no update after Accept all means your platform is not sending that signal. An update to granted means the signal is fine, so go to the tag. No state at all means the tag is passing its check rather than waiting for one.
Check the tag and its trigger
Open the tag’s Consent Settings and compare each required type with Google’s spelling, character by character. A misspelt type has no state, so that check passes when it should hold the tag. Then look at when it was blocked. A tag blocked only on a page load trigger before the choice needs a trigger that runs after the consent update.
Fix it where the fault is
If the signal never updates, map the banner category to it in your consent platform or in the update your own code sends. If your platform cannot send it, require a signal that it does send and that matches what the visitor agreed to.
Test accept, decline and the return visit
Repeat the check three ways. The tag should fire after Accept all, stay blocked after a decline or when only other categories are chosen, and fire again when the same visitor comes back.
Google’s Tag Assistant guide explains the Consent tab in more detail. If you are still deciding what a script should wait for, which consent category a script belongs in helps.
Should one banner category drive both signals?
It can. Some platforms send both from a single functional category, and others keep them apart. Either works if the words on the banner describe what the tags do. What matters is that every signal your container requires has a category behind it.
Velo keeps them apart. With Consent Mode switched on, every choice sends all seven types: the Functional category sets functionality_storage, Personalization sets personalization_storage, and security_storage stays granted. One setting to watch: where Velo asks before setting anything, a category you hide from the banner cannot be granted, so its signal stays denied even after Accept all. Check your container before you remove one. The Consent Mode guide has the setup.
Common questions
What people ask about this topic.
Why is my tag waiting for functionality_storage never firing?
One common cause is a signal that starts as denied and never receives an update from your consent platform. The tag only fires if every type it requires reads granted when its trigger fires, so it stays blocked even after someone accepts. Accept everything in Tag Assistant, open the latest Consent event and check whether the signal changed.
Do Google tags use functionality_storage or personalization_storage?
Google’s consent mode overview defines both, but it only describes how tags respond to ad_storage, analytics_storage, ad_user_data and ad_personalization. The two signals matter when a tag in your own container names them as a required consent type.
What happens if functionality_storage has no default state?
It passes. Google’s template documentation treats a consent type that was never set as granted, and the Tag Manager runtime we read in November 2026 does the same for additional consent checks. A tag gated on a signal with no state can fire before the visitor has chosen.
Does a blocked tag fire by itself once the visitor accepts?
No. The check is read when the trigger fires, and in the Tag Manager runtime we read in November 2026 a blocked tag is not retried when consent changes. It needs a trigger that fires after the consent update, such as your platform’s consent event.
Should functionality_storage be granted by default?
Only where the storage is strictly necessary for something the visitor asked for. Under the ePrivacy rules in the EU, other storage waits for consent, so a default of denied followed by a real update is the safe setup there. The UK now has its own exceptions, including one for adapting a site to a visitor’s preferences, so check the ICO’s guidance for UK traffic.
