Adobe Consent Mode: What the Bridge Does
Adobe Analytics consent mode is the consent signaling layer between your cookie banner and Adobe's Experience Platform Web SDK. The SDK accepts consent through the alloy('setConsent') command using Adobe's consent standard v2.0, which defines two consent fields: collect (controls data collection) and marketing.preferred (controls ad personalization). CookieBeam's Adobe bridge maps your banner categories to these fields automatically. When a visitor accepts the analytics category, the bridge sets collect.val to 'y'. When they accept the marketing category, it sets marketing.preferred to 'y'. Both default to 'n' when denied. Because the bridge reads the same Google Consent Mode v2 keys (analytics_storage and ad_storage) that your Google tags already use, a single banner decision keeps both Google and Adobe consent in sync. If the Adobe Web SDK hasn't loaded when the consent event fires, the bridge queues the signal and retries every 200ms for up to 10 seconds.
TL;DR
CookieBeam calls alloy('setConsent', payload) on consent changes (cookiebeam:consentUpdate) and for returning visitors (cookiebeam:consentRestored). Analytics category maps to collect.val: 'y'. Marketing category maps to marketing.preferred: 'y'. Both default to 'n' when denied. If the Adobe Web SDK hasn't loaded yet, the bridge queues the signal and retries every 200ms for up to 10 seconds.
How Adobe Experience Platform Handles Consent
Adobe's consent model uses the Experience Platform Web SDK (the alloy function) with a structured consent payload. The setConsent command accepts an array of consent entries, each following a named standard. CookieBeam uses the Adobe standard at version 2.0, which has two consent fields:
- collect controls whether Adobe may collect analytics and behavioral data. Value
'y'permits collection;'n'stops it. - marketing.preferred controls whether Adobe may use data for ad targeting and personalization. Value
'y'permits marketing use;'n'blocks it.
When the Web SDK receives collect.val: 'n', it stops sending hits to Adobe's servers. Existing cookies like kndctr_<orgid>_identity and kndctr_<orgid>_consent remain but are treated as inactive. For a deeper look at Adobe Analytics consent gating, including server-side considerations, see Adobe Analytics Consent: Gate It the Right Way.
How CookieBeam Maps Banner Categories to Adobe's Consent Standard
The bridge reads two consent mode keys from the cookiebeam:consentUpdate event and builds the Adobe consent payload from them.
analytics_storage (granted when the visitor accepts your analytics category) maps to collect.val. When granted, it's 'y'; when denied, 'n'.
ad_storage (granted when the visitor accepts marketing) maps to marketing.preferred. The bridge also considers ad_user_data and ad_personalization: if any of the three ad-related consent mode keys is granted, the marketing field becomes 'y'. In CookieBeam's category model, all three are granted together when a visitor accepts the marketing category.
This gives you independent control: a visitor can accept analytics but reject marketing, and Adobe will collect behavioral data while blocking ad personalization. Or they can accept both, and Adobe operates with full permissions.
CookieBeam banner category to Adobe consent standard mapping
| Banner Category | Consent Mode Key | Adobe Field | Granted Value | Denied Value | |
|---|---|---|---|---|---|
| Analytics | Analytics | analytics_storage | collect.val | y | n |
| Marketing | Marketing | ad_storage / ad_user_data / ad_personalization | marketing.preferred | y | n |
The Consent Payload Structure
The bridge constructs the exact payload that alloy('setConsent') expects. Here's what it looks like when a visitor accepts both analytics and marketing:
alloy('setConsent', {
consent: [{
standard: 'Adobe',
version: '2.0',
value: {
collect: { val: 'y' },
marketing: { preferred: 'y' }
}
}]
});When the visitor rejects both categories, val and preferred are both 'n'. When they accept analytics but reject marketing, collect.val is 'y' and marketing.preferred is 'n'.
Before Consent, After Accept, After Reject
Before the visitor decides: The bridge does not call setConsent. No default state is pushed to the Web SDK. The protection comes from your banner blocking Adobe's scripts from loading until the appropriate category is accepted, so the Web SDK shouldn't be active before consent in the first place.
After accept: CookieBeam dispatches a cookiebeam:consentUpdate event. The bridge reads the consent mode state, builds the Adobe payload, and calls alloy('setConsent'). If the alloy function isn't available yet (because the Web SDK is still loading), the bridge queues the payload and retries every 200ms for up to 10 seconds.
After reject: The same event fires with denied consent mode keys. The bridge calls setConsent with collect.val: 'n' and marketing.preferred: 'n'. The Web SDK stops sending data.
On withdrawal: When a visitor changes their consent, the bridge fires again with the updated state. The Web SDK adjusts its behavior immediately on receiving the new setConsent call.
Returning visitors: On later page views, the runtime re-announces the stored explicit choice as cookiebeam:consentRestored, and the bridge re-applies the matching setConsent call. A consent change on the current page fires cookiebeam:consentUpdate. This restatement ships with the runtime release that includes the vendor bridge fix. Machine-written defaults (such as US opt-out auto-grants) are not restated.
The Retry Queue
The Web SDK often loads asynchronously. If the consent decision happens before alloy exists, the bridge stores the payload and polls every 200ms, retrying up to 50 times (10 seconds total). Once the SDK loads, the bridge flushes only the most recent payload. If multiple consent changes happened while queued, earlier ones are discarded. If the SDK never loads, the queue is silently dropped.
How to Verify the Adobe Bridge in Your Browser
Open DevTools on a page with Adobe Web SDK
Load a page that has both your CookieBeam banner and the Adobe Experience Platform Web SDK. Open DevTools (F12) and go to the Console tab.
Check that alloy is loaded
Type typeof window.alloy in the console. If it returns 'function', the Web SDK is loaded. If it's 'undefined', the SDK hasn't loaded yet (or isn't on this page).
Monitor setConsent calls
In the Console, enable Verbose logging for the Web SDK by running alloy('setDebug', { enabled: true }). This logs all SDK commands, including setConsent, so you can see exactly what the bridge sends.
Reject the banner and check the console
Reject the cookie banner. You should see a setConsent log entry with collect.val: 'n' and marketing.preferred: 'n'.
Accept and verify the updated payload
Accept the banner with both analytics and marketing. The console should log a new setConsent call with both values set to 'y'.
Check cookies in the Application tab
In the Application tab, look for Adobe Web SDK cookies (kndctr_<orgid>_identity, kndctr_<orgid>_consent, kndctr_<orgid>_cluster). After rejection, these should not contain active tracking data. After acceptance, they should be populated normally.
Common Mistakes with Adobe Consent Mode
Not blocking the Web SDK before consent. The bridge signals consent state but doesn't prevent the SDK from loading. If the Web SDK initializes before consent, it may send an initial hit. Use CookieBeam's script blocking to defer the Web SDK until analytics is accepted.
Confusing the Adobe consent standard with Google's consent mode. Adobe's setConsent and Google's gtag('consent', 'update') are separate APIs. CookieBeam signals both from the same banner decision, but they don't interact. The bridge calls the Web SDK directly.
Expecting the bridge to work with older Adobe implementations. The bridge targets the Adobe Experience Platform Web SDK (alloy). If your site uses the legacy AppMeasurement library (s.t() / s.tl()) or Adobe Launch's older tag management, the bridge has nothing to call. Those implementations need separate consent handling.
For the full Adobe Analytics consent setup including data processing agreements and regional requirements, see Adobe Analytics Consent: Gate It the Right Way. For Adobe's consent documentation, see the Adobe Experience Platform consent overview.
Frequently Asked Questions
Does the Adobe bridge work with Adobe Analytics or only Adobe Experience Platform?
The bridge calls the Experience Platform Web SDK (alloy). If your Adobe Analytics implementation uses the Web SDK (which is Adobe's recommended path), the bridge works. If you're still on the legacy AppMeasurement library, the bridge has no API to call and you'll need separate consent handling for that setup.
What happens if the alloy function never loads?
The bridge queues the consent signal and retries for 10 seconds. If alloy still isn't available after 50 attempts, the signal is dropped. This is safe: if the Web SDK isn't on the page, there's no Adobe tracking to consent to.
Can I use the Adobe bridge alongside Google Consent Mode and other vendor bridges?
Yes. All vendor bridges listen to cookiebeam:consentUpdate and cookiebeam:consentRestored independently. A single banner decision drives Google, Adobe, Meta, Microsoft, and other vendor signals simultaneously.
Does the bridge handle Adobe's IAB TCF consent standard?
No. The bridge uses Adobe's own consent standard (version 2.0), not the IAB TCF standard that setConsent also supports. If your site uses TCF for Adobe, you'd need to configure that separately through the Web SDK's TCF integration.
Why does the bridge only send the last queued value instead of all of them?
Consent is a state, not an event stream. If a visitor accepts, then immediately changes their mind and rejects, the correct state is rejected. Sending both in order would work but adds complexity for no benefit. The last value is always the current truth.
For the broader picture, see the vendor bridge overview.