Microsoft Clarity Consent Mode with CookieBeam: How the Bridge Signals Analytics Consent

What the Clarity Consent Bridge Does

The CookieBeam Clarity consent bridge is the component that translates your cookie banner's marketing and analytics categories into the two consent signals Microsoft Clarity's consentv2 API expects: ad_Storage (capital S) for advertising data sharing and analytics_Storage (capital S) for behavioral analytics like session recordings and heatmaps. Unlike UET, which uses a single ad_storage signal, Clarity needs both because it serves dual purposes: recording visitor behavior (analytics) and feeding that data to Microsoft Advertising for audience building (advertising). Since October 31, 2025, Clarity enforces these consent requirements for EEA, UK, and Swiss visitors. CookieBeam's bridge sends both signals from a single visitor decision, mapping your analytics category to analytics_Storage and your marketing category to ad_Storage. For the manual API setup, see the Clarity consent mode guide.

Two Signals, One Decision

Clarity's consentv2 API accepts two consent types. analytics_Storage (capital S) controls whether Clarity can store cookies for session recordings and heatmaps. ad_Storage (capital S) controls whether Clarity can share data with advertising platforms like Microsoft Advertising.

CookieBeam maps these from the resolved Consent Mode v2 state:

• analytics_Storage reads from analytics_storage in the consent mode state, which corresponds to your banner's analytics category.
• ad_Storage reads from a combination of ad_storage, ad_user_data, and ad_personalization. If any of those is granted (all three come from the marketing category), ad_Storage is sent as granted.

This means a visitor who accepts analytics but rejects marketing will have Clarity record sessions (analytics allowed) without sharing that data with Microsoft Advertising (ad sharing denied).

What Fires and When

The bridge fires on the cookiebeam:consentUpdate event, the same event that triggers Google and Microsoft Advertising consent updates. Here's the sequence:

1. Visitor arrives. Clarity loads with its own defaults (denied for EEA, UK, and Swiss visitors since October 2025).
2. Visitor accepts analytics and marketing. CookieBeam fires cookiebeam:consentUpdate with analytics_storage: 'granted' and ad_storage: 'granted'.
3. The bridge calls window.clarity('consentv2', { 'ad_Storage': 'granted', 'analytics_Storage': 'granted' }). Clarity begins recording sessions and can share data with advertising.
4. If the visitor later withdraws just marketing, the bridge sends ad_Storage: 'denied' while keeping analytics_Storage: 'granted'. Clarity continues recording but stops advertising data sharing.

Queue Handling

Clarity's JavaScript snippet uses a queue pattern similar to Google's gtag. If window.clarity doesn't exist when the bridge runs, the bridge creates a queue stub: a function that pushes arguments to window.clarity.q. When Clarity's actual script loads later, it processes the queue and picks up the consent signal.

There's a guard for a specific edge case. If window.clarity exists but isn't a function (which can happen if another script partially initialized it), the bridge exits rather than overwriting it. This prevents breaking Clarity's initialization in rare script-loading scenarios.

Returning Visitors

On later page views, the runtime re-announces the stored explicit choice as cookiebeam:consentRestored, and the bridge sends the matching consentv2 call, so Clarity knows immediately whether it can record. If the stored consent includes analytics but not marketing, Clarity records sessions without advertising data sharing from the first page view. 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.

Why Both Signals Matter for Session Recordings

Session recordings capture everything a visitor does on the page: clicks, scrolls, form interactions, mouse movements. Under GDPR, this is personal data processing that requires consent. The analytics_Storage signal controls whether Clarity can collect this data at all.

The ad_Storage signal matters when Clarity is connected to Microsoft Advertising. With the connection active, Clarity's behavioral data enriches ad targeting and audience segments. A visitor might be comfortable with heatmaps (analytics accepted) but not with that data flowing into advertising (marketing rejected). The two-signal design lets them make that distinction.

For a deeper look at privacy implications of session recording tools, see session replay and consent.

For all vendor bridges, see the consent mode integrations overview. For the UET side, see the CookieBeam UET bridge. Microsoft's official documentation covers the Clarity consent configuration and the Clarity API reference.