CookieBeam's GTM Bridge: What Fires and When
The CookieBeam GTM bridge is a consent mode integration that connects your cookie banner to Google Tag Manager's dataLayer. When CookieBeam loads alongside GTM, the bridge pushes consent default and consent update commands that tell Google tags (GA4, Google Ads, Floodlight, and any tag using consent checks) which categories the visitor has granted or denied. The push sequence depends on the loading mode: in direct-loader mode the stub pushes the default before GTM fires; in GTM-loaded mode the template owns the default and the runtime follows with an update. On every consent change, the bridge pushes consent update plus legacy cookie_consent_update events. It also publishes window.CookieBeamGTM, an API that GTM templates can query for consent state or use to show the banner. For the broader setup, see the Google Consent Mode v2 implementation guide.
TL;DR
In direct-loader mode, the stub pushes consent default and the runtime follows with consent update. In GTM-loaded mode, the template owns the default and the runtime pushes consent update for stored consent. On consent change, it pushes consent update, the legacy cookie_consent_* events, and dispatches cookiebeam:consentUpdate. Returning visitors also receive cookiebeam:consentRestored. window.CookieBeamGTM exposes getConsent(), hasConsent(), getConsentDetails(), and more for custom GTM templates.
What Gets Pushed to the DataLayer
CookieBeam pushes three kinds of entries to the GTM dataLayer: consent commands, legacy category events, and modal lifecycle events.
Consent commands
These use Google's gtag('consent', ...) format, which GTM reads natively. At page load, a consent default sets the initial state for all seven Consent Mode v2 keys:
ad_storage,ad_user_data,ad_personalization(denied for new EEA visitors)analytics_storage(denied for new EEA visitors)functionality_storage(granted by default)personalization_storage(denied for new EEA visitors)security_storage(granted always)
The default command includes wait_for_update: 2000 (configurable), which tells tags to pause up to 2 seconds for the consent update before firing with the default state. When ads_data_redaction is enabled in your banner settings, it's included too.
On consent change (accept, reject, or withdrawal), a consent update pushes the new state for the same seven keys, without wait_for_update.
Legacy category events
On every consent change (and at page load in direct embed mode for returning visitors), CookieBeam pushes dataLayer events that older GTM setups can use as triggers:
cookie_consent_updatefires on every consent changecookie_consent_marketingfires when the marketing category is acceptedcookie_consent_statisticsfires when analytics (or the legacy "statistics" name) is acceptedcookie_consent_preferencesfires when preferences (or "functional"/"functionality") is accepted
These are redundant if you use Consent Mode v2 natively, but they let older tags fire on a custom trigger. See Google Tag Manager and Consent for how to wire them.
Modal events
When the banner or preferences panel opens or closes, the bridge pushes cookiebeam_modal_shown and cookiebeam_modal_hidden with a modal_type (consentModal or preferencesModal) and a timestamp. Use these as GTM triggers to track how often visitors see the banner or open preferences.
| Entry | When | Contains |
|---|---|---|
| consent default | Page load (loader stub in direct-loader mode; or runtime in direct embed mode) | 7 consent keys + wait_for_update + ads_data_redaction |
| consent update | Page load (direct-loader runtime resolves state; GTM-loaded with stored consent) or on consent change | 7 consent keys |
| set (url_passthrough, ads_data_redaction) | Page load (direct embed and direct-loader modes) | url_passthrough: true, ads_data_redaction if enabled |
| cookie_consent_update | Page load (direct embed, returning visitor) and every consent change | Event name only |
| cookie_consent_marketing | Marketing accepted (page load or consent change) | Event name only |
| cookie_consent_statistics | Analytics accepted (page load or consent change) | Event name only |
| cookie_consent_preferences | Preferences accepted (page load or consent change) | Event name only |
| cookiebeam_modal_shown | Banner or preferences panel opens | modal_type + timestamp |
| cookiebeam_modal_hidden | Banner or preferences panel closes | modal_type + timestamp |
Direct-Loader vs GTM-Loaded Mode
CookieBeam's consent mode integration behaves differently depending on how it was loaded, and knowing which mode you're in affects what you see in the dataLayer.
Direct-loader mode means CookieBeam's loader stub is in your page HTML before GTM. The stub pushes a conservative consent default (all denied + wait_for_update). The runtime then pushes a consent update with the resolved state, including any stored consent for returning visitors.
GTM-loaded mode means CookieBeam runs as a GTM tag (via the Community Template). The template already pushed a conservative consent default (all denied + wait_for_update). CookieBeam then pushes a consent update if the visitor has stored consent or if regional defaults differ. For new visitors with no stored consent, no update is pushed because it would just echo the template's state.
The CookieBeamGTM API Object
CookieBeam publishes window.CookieBeamGTM on page load. GTM custom templates and custom HTML tags can call its methods to query or control consent:
getConsent()returns{ categories: string[], consentId, timestamp, isValid }hasConsent('marketing')returnstrueorfalsefor a specific categorygetConsentDetails()returns{ necessary, preferences, analytics, marketing }as booleans, with aliases for legacy names ("statistics" maps to analytics, "functionality" maps to preferences)updateConsent(['analytics', 'marketing'])programmatically updates the accepted categoriesshowBanner()andshowPreferences()open the consent or preferences modalisBannerVisible()returns whether the banner is currently showinggetConfig()returns{ mode, autoShow, revision, gtmEnabled }
For building a custom consent mode GTM template that reads from CookieBeam, getConsentDetails() and hasConsent() are the two methods you'll call most.
Verify the Bridge in GTM Preview and Tag Assistant
Open GTM Preview mode
In GTM, click Preview and enter your site URL. Tag Assistant opens alongside your page.
Check the Consent tab on the Container Loaded event
In Tag Assistant, click the "Container Loaded" event (or the first Summary entry). Go to the Consent tab. You should see all seven consent mode keys with their initial values. For a new EEA visitor, ad_storage, analytics_storage, ad_user_data, and ad_personalization should all show "denied". functionality_storage and security_storage should show "granted".
Accept the banner and check for the Consent Update event
Accept cookies. In Tag Assistant, a new "Consent" event should appear in the timeline. Click it and check the Consent tab: the keys matching your accepted categories should now show "granted".
Check the dataLayer for legacy events
Open DevTools on the page and type dataLayer.filter(e => e.event && e.event.startsWith('cookie_consent_')). You should see cookie_consent_update plus the category-specific events matching what you accepted.
Verify the API object
In DevTools Console, type window.CookieBeamGTM.getConsentDetails(). The returned object should match your current consent state: { necessary: true, analytics: true/false, marketing: true/false, preferences: true/false }.
Test tag firing behavior
In Tag Assistant, check which tags fired and which didn't on the Container Loaded vs Consent events. Tags with a consent requirement (like Google Ads or GA4) should wait for granted consent before firing. If a tag fires on Container Loaded despite denied consent, its consent configuration in GTM needs adjusting.
Common Mistakes
Duplicate consent defaults. If you have both a direct CookieBeam script tag and the GTM Community Template active, you'll get two consent default pushes. GTM may behave unpredictably when it sees competing defaults. Use one loading method, not both.
Triggering tags on the legacy events instead of consent mode. The cookie_consent_marketing events exist for backward compatibility. If your GTM tags support built-in consent checks (GA4, Google Ads, Floodlight), use consent mode instead. See Consent Mode: Advanced vs Basic.
Assuming CookieBeamGTM exists before GTM initializes. window.CookieBeamGTM is published when CookieBeam's runtime initializes. Inline scripts that run before CookieBeam won't find it.
For a full walkthrough of debugging consent mode in the browser, see How to Debug Consent Mode v2.
Frequently Asked Questions
Do I need the CookieBeam GTM Community Template or can I use the direct script tag?
Either works. The direct script tag gives you slightly earlier consent defaults (before GTM loads). The GTM template keeps everything inside GTM's container. Both push the same consent commands and events to the dataLayer. Don't use both at once.
What is wait_for_update and should I change it?
It's how long tags pause on page load before firing with the default (denied) state. The default is 2000ms, giving CookieBeam time to resolve stored consent for returning visitors. You could lower it if your script loads fast, but 2 seconds is safe for most setups.
Why do I see cookie_consent_statistics instead of cookie_consent_analytics?
CookieBeam supports both "analytics" and the legacy name "statistics" for the same category. The dataLayer event uses cookie_consent_statistics for backward compatibility with older GTM setups. It fires when either name is accepted.
Can I use CookieBeamGTM.updateConsent() to change consent from a custom button?
Yes. Calling CookieBeamGTM.updateConsent(['necessary', 'analytics']) updates the categories, triggers a consent update push, fires the legacy events, and stores the choice. It's equivalent to the visitor choosing through the banner UI.
Does the bridge push anything for returning visitors with stored consent?
Yes. In direct-loader mode, the runtime pushes a consent update with the stored choice after the stub's conservative default. In GTM-loaded mode, the runtime pushes a consent update to override the template's conservative defaults. In both modes, the runtime also dispatches cookiebeam:consentRestored so vendor bridges receive the stored state. Machine-written defaults (such as US opt-out auto-grants) are not restated. This restatement ships with the runtime release that includes the vendor bridge fix. A consent change on the current page fires cookiebeam:consentUpdate.
For all vendor bridges, see the consent mode integrations overview. For Google's reference, see the consent mode implementation guide and the GTM dataLayer developer documentation.