Consent Mode Integrations Overview
Consent mode integrations are the vendor-specific API calls that tell each marketing and analytics tool on your site whether a visitor has granted or denied cookie consent. Every major vendor designed its own consent API independently: Meta Pixel uses fbq('consent', 'grant'), Microsoft Advertising UET uses uetq.push('consent', 'update', ...), Microsoft Clarity uses consentv2, HubSpot checks _hsq doNotTrack, Matomo reads setCookieConsentGiven, Shopify exposes setTrackingConsent, Adobe expects alloy('setConsent'), and Webflow reads a localStorage key. A site running four or five tools therefore needs four or five separate consent wirings. CookieBeam's vendor consent bridges eliminate that work: a single visitor decision on your cookie banner is resolved into Google Consent Mode v2 keys (ad_storage, analytics_storage, and four more), and each enabled bridge reads those keys and calls its vendor's native API. This article maps every bridge, which banner category drives it, and how to verify it in the browser.
TL;DR
CookieBeam listens for cookiebeam:consentUpdate (consent changes) and cookiebeam:consentRestored (returning visitors). Each vendor bridge reads the resolved Consent Mode v2 state and calls the vendor's own API. Ad platforms (Meta, Microsoft Ads) key off ad_storage (your banner's marketing category). Analytics tools (HubSpot, Matomo, Webflow) key off analytics_storage (your analytics category). Microsoft Clarity, Shopify, and Adobe read both. Enable each bridge in your banner settings; no per-vendor code needed.
The Shared Model
All eight bridges share the same architecture. When a visitor accepts, rejects, or withdraws consent, CookieBeam dispatches a cookiebeam:consentUpdate window event. The event's detail.consentMode carries the resolved Consent Mode v2 state. A shared dispatcher function translates that state into two internal values: adStorage (granted if any of ad_storage, ad_user_data, or ad_personalization is granted) and analyticsStorage (granted if analytics_storage is granted). Each bridge reads one or both of these values and calls its vendor's API accordingly.
The bridges are opt-out: they're enabled by default for banners created before the toggle existed, so existing customers keep the behavior they had. You can disable any individual bridge in your banner's vendor consent settings. A disabled bridge ships zero code to the page.
For returning visitors with stored explicit consent, the runtime dispatches a separate cookiebeam:consentRestored event on page load, and each bridge re-applies the same vendor call. Machine-written default records (such as US opt-out auto-grants) are not restated; only a stored explicit choice triggers the event. This restatement ships with the runtime release that includes the vendor bridge fix. A consent change on the current page fires cookiebeam:consentUpdate. And if a vendor's script loads after the consent event fires, bridges for Meta and Adobe queue the signal and poll until the vendor becomes available (every 200ms, up to 10 seconds).
How Each Bridge Maps Your Banner Decision
The table below shows the consent mechanism, what each vendor withholds before consent, what changes when the visitor accepts, and where to verify in the browser. For the full walkthrough on each vendor, follow the link in the card grid below.
Vendor Bridge Comparison
| Mechanism | Withheld Before Consent | On Accept | Verify Via | |
|---|---|---|---|---|
| Meta Pixel | fbq('consent', 'grant'/'revoke') | _fbp, _fbc cookies; all events | Pixel sets cookies and sends events | _fbp cookie, /tr/ network requests |
| Microsoft Ads (UET) | uetq.push('consent', 'update', {ad_storage}) | _uetsid, _uetvid cookies | UET sets session and visitor cookies | _uetsid cookie, bat.bing.com requests |
| Microsoft Clarity | clarity('consentv2', {ad_Storage, analytics_Storage}) | _clck, _clsk cookies; recordings | Clarity records sessions and heatmaps | _clck cookie, clarity.ms requests |
| HubSpot | _hsq doNotTrack + _hsp revokeCookieConsent | __hssc, __hssrc, __hstc cookies | Page-view and session tracking resumes | __hstc cookie, track.hubspot.com requests |
| Matomo | _paq setCookieConsentGiven / forgetCookieConsentGiven | _pk_id, _pk_ses cookies (tracking continues cookieless) | Matomo sets visitor and session cookies | _pk_id cookie, matomo.php requests |
| Shopify | Shopify.customerPrivacy.setTrackingConsent({...}) | Marketing and analytics tracking | Per-category tracking enabled | Shopify.customerPrivacy.currentVisitorConsent() |
| Adobe (Alloy) | alloy('setConsent', {collect, marketing}) | Data collection and marketing signals | Experience Platform receives events | alloy() calls in Console, kndctr_ cookies |
| Webflow | wf.allowUserTracking / denyUserTracking + localStorage | Webflow Optimize personalization | Optimize activates experiments | localStorage key intellimize_user_tracking_choice_* |
Before Consent, After Accept, On Withdrawal
Before consent (first visit, banner untouched): no bridge has fired. Vendors that load on the page run in their default state. If you've tagged vendor scripts under the right banner category, CookieBeam blocks them from loading at all. If a vendor loads via Google Tag Manager's consent mode advanced setup, the bridge gates its behavior once the consent event fires.
After accept: the bridge fires immediately. For queued bridges (Meta, Adobe), if the vendor script hasn't loaded yet, the command waits in a queue and flushes when it appears.
On withdrawal: revoking a category in the preferences panel fires the bridge again with the denied state. The vendor clears cookies and stops collecting. This happens on the same page view, not on the next load.
Detailed Guides for Each Vendor
Vendor Consent Bridge Guides
Meta Pixel
fbq consent grant/revoke, the queue, and Limited Data Use
Microsoft Ads (UET)
Single ad_storage signal, no conversion modeling
Microsoft Clarity
consentv2 API with capital-S ad_Storage
HubSpot
doNotTrack and revokeCookieConsent from analytics consent
Matomo
Cookie consent vs tracking consent, cookieless fallback
Shopify
Customer Privacy API with per-category consent
Adobe (Alloy)
Experience Platform setConsent for collect and marketing
Webflow
Optimize personalization via localStorage and wf API
Frequently Asked Questions
Do I need to configure each vendor bridge separately?
No. All eight bridges are enabled by default. You can disable any individual one in your banner's vendor consent settings. When enabled, the bridge fires automatically whenever a visitor accepts, rejects, or withdraws consent. No per-vendor code changes are needed.
What happens if a vendor's script loads after the consent decision?
Two bridges (Meta, Adobe) include a queue that holds the consent signal and polls every 200ms until the vendor's SDK becomes available, up to 10 seconds. The other bridges fire directly into the vendor's command queue (_paq, _hsq, uetq), which the vendor processes when it loads.
Why do some bridges use the marketing category and others use analytics?
Ad platforms (Meta, Microsoft Ads) read ad_storage because they're placing advertising cookies. Analytics tools (HubSpot, Matomo, Webflow) read analytics_storage because they're measuring site behavior. Clarity, Shopify, and Adobe read both because they span advertising and analytics functions.
Does the bridge replace script blocking?
They're complementary. Script blocking prevents a vendor's code from loading at all until consent. The bridge tells an already-loaded vendor what the visitor chose. Use both when the vendor script might load before consent (e.g., via GTM advanced consent mode). If you block the script by category, the bridge confirms the consent signal once it loads.
How does this relate to Google Consent Mode v2?
Google Consent Mode v2 is the underlying system. CookieBeam resolves your banner categories into Consent Mode v2 keys (ad_storage, analytics_storage, etc.) and pushes them to Google's gtag('consent', ...) API. The eight vendor bridges then read those same resolved keys and translate them into each vendor's own format. Google is the core; the bridges are the spokes. See Google Consent Mode v2: Complete Implementation Guide for the full picture.
Getting Started
If you're setting up consent mode from scratch, start with the Google Consent Mode v2 guide to understand the core system, then set up GTM consent mode if you use Google Tag Manager. The vendor bridges layer on top of that foundation. For each vendor you run, read the dedicated guide above to understand the exact behavior and verify it in your browser. The bridges ship no code for vendors you don't enable, so there's no performance cost to leaving unused ones off. For a single-vendor dive, the Google consent mode developer reference and the Google Analytics consent mode help page cover the Google side in depth.