TL;DR
CookieBeam's UET bridge sends ad_storage consent signals to Microsoft Advertising through the standard uetq.push('consent', 'update', ...) API. It maps your banner's marketing category to Microsoft's single consent signal. The bridge doesn't set the initial default because Microsoft handles EEA defaults server-side (denied since May 2025).
Which Microsoft consent guide do you need?
- This guide: how CookieBeam's UET bridge sends
ad_storagesignals automatically. - UET consent mode explained: the May 2025 deadline, the signal, and how it differs from Google.
- Clarity consentv2 API: manual Clarity consent implementation.
- CookieBeam Clarity bridge: how CookieBeam sends Clarity consent signals.
- Clarity and Bing Ads together: combined setup for both tools.
What the UET Consent Bridge Does
The CookieBeam UET consent bridge is the component that translates your cookie banner's marketing category into the ad_storage consent signal that Microsoft Advertising's Universal Event Tracking (UET) tag expects. UET uses a single consent signal, ad_storage, with two values: granted and denied. Since May 5, 2025, Microsoft defaults this to denied for visitors from the EEA, UK, and Switzerland, meaning sites that never send an update lose all conversion tracking and remarketing for those users. The bridge pushes uetq.push('consent', 'update', { ad_storage: 'granted' }) when a visitor accepts marketing cookies, and the denied equivalent when they reject or withdraw. It fires on the same cookiebeam:consentUpdate event that drives Google Consent Mode v2, so both platforms read from a single visitor decision. For the policy background, see the UET consent mode explainer.
How the Bridge Maps Categories to Signals
The bridge reads CookieBeam's resolved Consent Mode v2 state and derives a single ad_storage value for UET. It checks three consent signals: ad_storage, ad_user_data, and ad_personalization. If any of those three is granted, the bridge sends ad_storage: 'granted' to UET. If all three are denied, it sends denied.
In practice, these three signals all come from the same place: your banner's marketing category. When a visitor accepts marketing, all three are granted. When they reject it, all three are denied. The OR logic handles edge cases where a custom category mapping grants one signal but not the others.
| CookieBeam Category | Consent Mode Signals | UET Signal Sent | Effect on UET |
|---|---|---|---|
| marketing (accepted) | ad_storage, ad_user_data, ad_personalization: granted | ad_storage: granted | UET stores cookies, tracks conversions and remarketing |
| marketing (rejected) | ad_storage, ad_user_data, ad_personalization: denied | ad_storage: denied | UET stops cookie storage, no conversion or remarketing data |
| analytics | analytics_storage | Not sent to UET | UET does not use analytics_storage |
| necessary | security_storage | Not sent to UET | Always allowed, not relevant to UET |
What Fires and When
The bridge listens to the cookiebeam:consentUpdate event, which fires whenever the visitor makes a consent decision: accept all, reject all, or a specific category change. The same event drives Google's consent mode, Meta's consent signal, and every other vendor bridge CookieBeam supports.
Here's the sequence for a first-time visitor:
- Visitor arrives. CookieBeam sets Google consent defaults via gtag. UET uses Microsoft's own EEA default (denied for EEA, UK, and Swiss traffic since May 2025).
- Visitor accepts marketing. CookieBeam fires
cookiebeam:consentUpdatewithad_storage: 'granted'. - The bridge pushes
uetq.push('consent', 'update', { 'ad_storage': 'granted' }). UET begins conversion tracking and cookie storage. - If the visitor later withdraws marketing consent, CookieBeam fires another
cookiebeam:consentUpdatewithad_storage: 'denied'. The bridge pushes the denial to UET.
No Default Signal, by Design
The bridge sends update, never default. This is intentional. Microsoft's UET tag handles its own default for EEA, UK, and Swiss visitors: it treats unconfigured traffic as denied. So UET already starts in a compliant state without CookieBeam telling it to.
CookieBeam's bridge only needs to tell UET when the visitor's decision changes, not what the starting state should be. If the UET tag loads before the visitor interacts with the banner, nothing stores. When they accept marketing, the bridge pushes the update, and UET begins tracking from that point forward.
Returning Visitors
On later page views, the runtime re-announces the stored explicit choice as cookiebeam:consentRestored. If the stored consent includes marketing, the bridge pushes ad_storage: 'granted' to UET, so conversion tracking is active from the first page view. The banner doesn't reappear. If their stored consent explicitly denied marketing, the event still fires with ad_storage: 'denied', which matches UET's own default. Machine-written defaults (such as US opt-out auto-grants) are not restated. A consent change on the current page fires cookiebeam:consentUpdate. This restatement ships with the runtime release that includes the vendor bridge fix.
How to Verify in the Browser
Clear all cookies and storage
Open your site in Chrome and clear cookies and site data for the domain.
Inspect the UET queue before consent
Load a page where the UET tag is installed. Open DevTools > Console and type window.uetq. You should see the queue array. Check that _uetsid and _uetvid cookies are either absent or hold only placeholder values.
Accept marketing cookies
Accept cookies with the marketing category included. In the Console, inspect window.uetq again. You should see a ['consent', 'update', { ad_storage: 'granted' }] entry in the queue.
Verify UET cookies
Reload and confirm that _uetsid and _uetvid now hold real session and visitor IDs in DevTools > Application > Cookies.
Withdraw marketing consent
Reopen the banner and switch off marketing. The bridge should push another entry: ['consent', 'update', { ad_storage: 'denied' }].
Confirm conversion data matches consent rate
In Microsoft Advertising, compare your conversion volume before and after enabling the bridge. The drop reflects your actual consent rate. Microsoft does not model the missing conversions the way Google does.
Common Mistakes
The most frequent problem is running both a manual UET consent setup and CookieBeam's bridge. If your tag manager also pushes uetq.push('consent', ...), the two can conflict: one might update to granted while the other hasn't fired, or withdrawal might reach one path but not the other. Use one or the other. If CookieBeam's bridge is enabled, remove any manual UET consent commands from your tag manager.
The second mistake is expecting Microsoft to model conversions lost to denied consent. It won't. Google's Advanced Consent Mode estimates denied conversions from aggregate signals. Microsoft has no equivalent. The conversions you lose are gone. The right response is better banner design, not a looser gate. For practical strategies, see improving consent rates without dark patterns.
Frequently Asked Questions
Is the Microsoft UET bridge enabled by default in CookieBeam?
Yes. Under your banner's vendor consent signals settings, Microsoft is on unless you explicitly switch it off. This matches the behaviour before the setting existed: customers who never touched the toggle were already receiving the bridge.
Does the bridge handle both Microsoft Advertising and Microsoft Clarity?
They're separate bridges. The UET bridge sends ad_storage to Microsoft Advertising's uetq queue. The Clarity bridge sends ad_Storage and analytics_Storage to Clarity's consentv2 API. Both fire on the same consent event, but they signal different products with different parameters. See the Microsoft Clarity consent bridge guide for Clarity's behaviour.
What happens if UET hasn't loaded when the visitor accepts?
The bridge initializes window.uetq as an empty array if it doesn't exist, then pushes the consent command. When UET's script loads later, it processes the queue and picks up the consent signal. This is the standard UET queue pattern: commands pushed before the tag loads are replayed when it initializes.
Do I need to change my UET tag code to use the bridge?
No. The bridge pushes consent signals to the same uetq queue your UET tag uses. You don't need to modify the UET snippet or add consent commands to it manually.
Can I use the bridge with IAB TCF instead of CookieBeam's category-based consent?
Microsoft UET also accepts IAB TCF 2.0 strings as an alternative to ad_storage. CookieBeam's bridge sends ad_storage, not a TCF string. If you need TCF-based consent for Microsoft, handle that through your TCF implementation rather than this bridge. See the Microsoft consent mode for Clarity and Bing Ads guide for TCF alternatives.
For all vendor bridges, see the consent mode integrations overview. For the Clarity side, see the CookieBeam Clarity bridge. Microsoft's official documentation covers UET consent mode setup and the May 2025 deadline announcement.