How to install a cookie banner with Google Tag Manager

Why the order is the whole job

Installing a banner in Tag Manager is not really about the banner. It is about making sure the banner sets the consent state before your analytics and advertising tags decide whether to fire. Get that sequence right and everything else falls into place. Get it wrong and you have a banner that looks perfect and blocks nothing, because GA4 already fired while the banner was still loading.

Tag Manager gives you one trigger built for exactly this: Consent Initialization - All Pages. It is guaranteed to run before every other trigger, including the ordinary All Pages trigger. Your default consent state and your banner both belong there, and almost every broken setup we are called in to fix put one of them somewhere else.

The install, in order

Six steps, done in this order. The first four get the banner live; the last two are the checks that separate a banner that works from one that only looks like it does.

1. Set the default consent state first

   Add a Consent Mode tag on the Consent Initialization - All Pages trigger that defaults ad_storage, analytics_storage, ad_user_data and ad_personalization to denied. This has to run before any other tag evaluates, which is exactly what the Consent Initialization trigger guarantees. All four signals have to be present, not just the two analytics ones.

2. Load the banner on the same trigger

   Add your consent banner as a Custom HTML tag, or a CMP template from the Community Gallery, on the same Consent Initialization - All Pages trigger. The banner then paints before your analytics and advertising tags get a chance to fire, so the visitor makes a choice while the tags are still waiting rather than after they have already run.

3. Update consent when the visitor chooses

   Wire the banner's accept and reject actions to push a consent update into Tag Manager, flipping the relevant signals to granted or leaving them denied. Tags on the same page that were held back can now fire in the correct state. This is the link that turns a static banner into a working consent control.

4. Gate the tags that are not essential

   On each GA4, Google Ads and third party tag, set the built in consent checks, or an additional consent requirement, so the tag only fires once the matching signal is granted. Essential tags stay ungated. A banner with no gated tags is decoration: it collects a choice and then ignores it.

5. Confirm the banner fires before GA4

   Open Preview mode and the browser network panel, load the page as a fresh visitor, and confirm the Consent Initialization tags fire first and the default denied state is set before GA4 sends anything. This is the check the vendor guides skip, and it is where most setups silently break: the container loads a fraction late, GA4 fires against no consent state, and Preview mode still shows green.

6. Test the repeat visit, not just the first

   Clear the consent cookie and reload, then load again with the cookie already set. A returning visitor with a stored choice has to restore that state without showing the banner again and without firing the tags they declined. First visit passing does not mean the returning visit does, and stale consent bugs only ever show up on the second load.

Where this silently breaks

The install steps above are the easy part. The failures are all in the gaps the walkthroughs gloss over. The first is timing: if your container loads asynchronously and a Google tag is present in the page rather than in the container, the tag can fire before Tag Manager has even parsed the Consent Initialization trigger. Preview mode, which waits for the container, will not show you this. Only the live network panel will.

The second is the difference between a banner that fires and a tag that obeys. A CMP template can load flawlessly on the right trigger and your GA4 tag can still fire on a rejected session, because gating tags on consent is a separate step that is easy to skip. Confirm it by declining consent and watching for a collect request that should not be there. The third is the returning visitor with a stored choice, which almost nobody tests and which is where regional edge cases and stale cookies surface.

None of these throw an error. That is what makes them expensive: on a typical site around a third of sessions sit behind the banner, so a leak here quietly distorts a large slice of your measured traffic while every dashboard still reads normal. That 34% is a measured baseline across Amplio Data client implementations, not a fixed rate for every site, but it is large enough that a silent consent leak is never a rounding error.

This is the whole reason Velo exists. It ships the Consent Initialization ordering, the four default denied signals, the accept and reject wiring and the audit trail as one configured layer, so the sequence above is correct by default rather than reassembled by hand in a Custom HTML tag every time your site changes. You install one tag, and the order is handled for you. For teams who prefer to wire it themselves, the GTM template gives you the same ordering as a starting point.

Common questions