How do I fire GTM tags on the cookie consent update event?
cookie_consent_update is a data layer event that a consent platform pushes when a visitor’s choice takes effect, so Tag Manager can run tags it held back. To fire tags on it, create a Custom Event trigger with that event name, add a condition that the category the tag needs is granted, read from a Data Layer Variable or the platform’s cookie, and use it instead of All Pages.
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
The trigger itself is quick to build. The trouble usually comes afterwards, as a page view counted twice or a tag that fires when the visitor said no. Here is what the event is for, how to wire it, and how to keep the numbers honest.
What is the cookie_consent_update event?
It is a custom event, the same kind your own site pushes with dataLayer.push({event: '…'}). Google does not define it. The consent platform chooses the name, and several platforms use cookie_consent_update in their Tag Manager guides; at least one says it sends that name so containers set up for another platform keep working. Velo pushes velo_consent_update, with the decision alongside it in a velo_categories object that holds analytics, ads, functional and personalization, each true or false.
It is not the same thing as Google’s consent update command. That command changes the consent state that Google tags and Tag Manager’s consent checks read. The custom event is the cue for your triggers: it is something a Custom Event trigger can match. A good consent platform sends both, in that order, so the state is already updated when your tag is judged.
Why do tags need a second trigger after consent?
Because Tag Manager checks consent once, at the moment a tag’s trigger fires. Google’s help on consent settings says a tag with additional consent requirements fires only if every listed consent type is granted when the tag is triggered. On a first visit, the All Pages trigger fires before the visitor has chosen anything, so a tag that requires analytics_storage is held. When the visitor accepts a few seconds later, nothing in the container goes back for it. The tag needs a trigger that fires after the choice, and that is the consent update event.
Consent is checked at the trigger. So trigger again.
- 1Page loadsAll Pages fires, no choice yet
- 2Tag is heldConsent reads denied
- 3Visitor acceptsPlatform pushes the update event
- 4Tag firesOn the update trigger
This is for tags without consent handling of their own: a Meta or Hotjar tag carrying Require additional consent settings, or Google tags in basic consent mode, which should not load at all until the visitor agrees. Google’s own tags in advanced mode read the consent state themselves, so they stay on their usual triggers. Our post on whether to block Google tags until consent covers that split.
How do I fire a GTM tag on the consent update event?
Find the event name your platform pushes
Open Tag Manager’s Preview on your site, accept in the banner and read the event list on the left. Take the name exactly as it appears. With Velo it is
velo_consent_update.Create a variable for the category
Add a Data Layer Variable that reads the category the tag depends on. With Velo that is
velo_categories.analyticsfor analytics tags andvelo_categories.adsfor advertising tags. Other platforms keep the state elsewhere, sometimes in a first party cookie, so check where yours puts it.Build the trigger with a condition
Create a Custom Event trigger on the event name and set it to fire on some custom events, where the variable equals true. Without the condition the trigger also fires when the visitor rejects, and a tag with no consent settings of its own then fires anyway.
Swap it in for All Pages
On the tag, remove the All Pages trigger and add the new one. Keeping both makes the tag fire twice for returning visitors, because the update event also fires on their page views.
Set page view tags to fire once per page
Under Advanced Settings, then Tag firing options, choose Once per page. A visitor who opens the banner again and saves a new choice pushes the event a second time on the same page.
Leave conversion tags on their own triggers
A purchase or lead tag should fire on the purchase or the form, never on the consent event. On the consent event it would count a conversion every time a visitor makes a choice.
Test it in Preview, then on the live site
Run the four checks below in a fresh browser session each time, then publish the container.
Why does my tag fire twice after consent?
Three setups make a tag count twice:
- Two triggers on one tag. A returning visitor already has a stored choice, so the tag can pass its consent check on All Pages, and then fire again on the update event a moment later. One page view becomes two.
- A choice changed on the same page. Each saved choice pushes the event again. Once per page stops the second page view.
- A conversion tag on the consent trigger. Every accept looks like a lead. Move the conversion tag back to the event that defines the conversion.
If the numbers jumped the week you installed a consent platform, check these before you blame the platform or the visitors.
When does Velo push velo_consent_update?
Every time a consent decision takes effect on a page, not only when someone clicks:
- when a visitor accepts, rejects or saves their choices in the banner;
- on every page view of a returning visitor, as the stored choice is applied again;
- when a visitor in a region with opt out rules sends a Global Privacy Control signal, which Velo records as a refusal;
- when a new visitor arrives in a region with opt out rules and Velo applies the default of everything allowed, which the banner still lets them reject.
That is why the trigger can stand in for All Pages: once a visitor has allowed a category, the tags on it fire on every page they view. Our help page on basic and advanced consent mode has the same setup as a short checklist, and installing a cookie banner with Google Tag Manager covers the Consent Initialization side that comes first.
How do I check the trigger works?
- First visit, before choosing: the tag shows as not fired, and the Network panel shows no request from it.
- After accepting: the tag fires once, on the update event.
- After a reload: the tag fires once per page, still on the update event, never a second time on Container Loaded.
- After rejecting: in a new session, browse two pages. The tag never fires.
Preview tells you what Tag Manager decided. The Network panel tells you what actually left the browser, so check both. Our routine for testing a cookie banner before going live has the full browser checklist.
Velo pushes velo_consent_update on every one of these paths, so a single trigger per category covers first visits, returning visitors and changed minds alike.
Common questions
What people ask about this topic.
What is the cookie_consent_update event, and how do I fire GTM tags on it?
It is a custom data layer event that a consent platform pushes when a visitor’s choice takes effect. Google does not define it; each platform names its own, and several use cookie_consent_update. Velo’s is velo_consent_update. To fire tags on it, create a Custom Event trigger on the event name with a condition on the consent category.
How do I fire GTM tags on cookie_consent_update?
Create a Custom Event trigger on the event name, add a condition on the consent category the tag needs, and use it in place of the tag’s All Pages trigger. Set page view tags to fire once per page, keep conversion tags on their own triggers, and test in Preview.
Why does my GA4 or Meta tag fire twice after consent?
Usually because the tag has both the All Pages trigger and the consent update trigger. A returning visitor’s stored choice lets it pass on All Pages, then the update event fires it again. Remove All Pages and set the tag to fire once per page.
Does the consent update event fire for returning visitors?
It depends on the platform, so check in Preview. Velo pushes velo_consent_update on every page view where a stored choice is applied, which is what lets the trigger replace All Pages.
Should Google tags use the consent update trigger?
Only in basic consent mode, where Google tags should not load until the visitor agrees. In advanced mode, Google tags read the consent state themselves, so they stay on their usual triggers without additional consent settings.
Website privacy, in one place.
Scan your site →