A Deadline That Already Passed, With Teeth
On May 5, 2025, Microsoft made UET consent mode mandatory for any advertiser whose traffic includes the EEA, the UK, or Switzerland. Universal Event Tracking (UET) is Microsoft Advertising's equivalent of the Google Ads tag, and after that date, sites that don't send a valid consent signal have conversion tracking and remarketing suspended for those users. If you never configured consent mode, Microsoft defaults the state to denied in the EEA, which means every request is treated as no-consent and your Microsoft campaigns lose their measurement. This one bites quietly, because nothing errors. Your tag still loads, it just stops counting.
One Signal: ad_storage
Microsoft kept its consent mode deliberately simple. There's a single signal, ad_storage, with two values, granted and denied. It controls whether UET may store advertising cookies on the device. On the wire, every UET event carries an asc (ad storage consent) value of G or D so Microsoft knows which state applied. You set a default before the tag loads, then update it after the visitor decides. The syntax mirrors Google's, which is intentional.
// Set the default BEFORE the UET tag loads. In the EEA,
// default to denied so nothing stores before consent.
window.uetq = window.uetq || [];
window.uetq.push('consent', 'default', {
'ad_storage': 'denied'
});
// After the visitor accepts marketing, update to granted:
window.uetq.push('consent', 'update', {
'ad_storage': 'granted'
});
// If they decline or withdraw, update back to denied:
window.uetq.push('consent', 'update', {
'ad_storage': 'denied'
});How It Differs From Google Consent Mode v2
If you already run Google Consent Mode v2, you're most of the way to Microsoft compliance, but the two are not identical and the differences matter. Google uses four signals; Microsoft uses one. Google models the conversions it can't observe; Microsoft doesn't. Treat them as separate systems that happen to share a decision, not as one config that covers both.
Google Consent Mode v2 vs Microsoft UET Consent Mode
| Aspect | Google Consent Mode v2 | Microsoft UET Consent Mode |
|---|---|---|
| Consent signals | Four: ad_storage, analytics_storage, ad_user_data, ad_personalization | One: ad_storage |
| Denied-consent behavior | Advanced mode sends cookieless pings and models conversions | No modeling. Denied means the data is simply gone |
| EEA default when unconfigured | Tags may be blocked or run in basic mode depending on setup | Denied. All requests treated as no-consent |
| TCF alternative | Supported alongside Consent Mode | Supported. Pass an IAB TCF 2.0 string instead of ad_storage |
| Mandatory since | March 2024 for EEA ad personalization and measurement | May 5, 2025 for EEA, UK, and Switzerland |
Microsoft Does Not Model the Gap
This is the single most important difference. Google's Advanced Consent Mode softens the blow of denied consent by modeling conversions from aggregate, cookieless signals. Microsoft has no equivalent. When a visitor declines, Microsoft doesn't estimate the conversion you missed, it records nothing. So the reporting drop you see after implementing UET consent mode is real, not a modeling artifact, and it reflects your actual consent rate. Don't respond by loosening the gate to claw the numbers back. The fix for a low consent rate is a better banner, not a leakier one, and there's a real playbook for that in improving consent rates without dark patterns.
If You Already Run Google Consent Mode
The practical path is to derive Microsoft's ad_storage from the same consent decision that drives Google's. Your visitor accepts or rejects the marketing category once, and both tags read that one choice: Google's four signals map from it, and Microsoft's single ad_storage maps from the advertising portion of it. In a tag manager this is one consent variable feeding two tags. Don't build a second banner or a second decision for Microsoft. The alternative, if you're a publisher already sending an IAB TCF 2.0 string, is to let Microsoft read that string directly instead of the ad_storage signal. For how the TCF string relates to Google's model, see TCF 2.2 vs Google Consent Mode v2.
Cookies and Verification
UET sets _uetsid (session) and _uetvid (visitor) cookies, and it reads Microsoft's MUID. Under a correct default-denied setup, these should not carry a usable value before consent. Run the standard test: clear cookies, load the page, leave the banner untouched, and confirm that _uetsid and _uetvid are either absent or placeholder-only until you accept. Some UET builds initialize the cookies with null placeholders while denied, which is fine, as long as no real identifier is stored. A scanner makes this repeatable across your whole site rather than one page at a time.
Microsoft UET Consent Checklist
A default consent state of denied is pushed before the UET tag loads
In the EEA, UK, and Switzerland, denied is the correct starting point.
ad_storage updates to granted only after the marketing category is accepted
One decision drives it, ideally the same one that drives Google's tags.
Withdrawal pushes an update back to denied
Consent has to be reversible in real time. A choice made once at first visit that the visitor can't change later isn't enough.
You've accepted that denied conversions are lost, not modeled
The reporting drop is your real consent rate. Fix the banner, not the gate.
_uetsid and _uetvid hold no real identifier before consent
Placeholders are acceptable. Actual visitor IDs before acceptance are not.
Doing It With CookieBeam
CookieBeam wires the UET consent signal to your banner, pushing ad_storage denied by default and updating to granted the moment the visitor accepts marketing, with withdrawal handled the same way. Because the decision lives in one place, the same acceptance can drive your Google, Meta, and Microsoft signals together instead of three disconnected setups drifting apart. The scanner then confirms that _uetsid and _uetvid hold nothing real before consent, so you can prove the gate works rather than assume it. One banner, one decision, every ad platform reading from it.
Related Guides and Sources
Continue with Consent Mode: Advanced vs Basic, GA4 and Google Ads Consent Mode, and Meta Pixel and Conversions API Consent Gating. Primary sources: Microsoft Advertising's user consent signals announcement, the UET consent mode setup help page, and Microsoft's TCF for UET documentation.