The Microsoft Clarity Consent API passes a visitor's privacy choices to Clarity. Use consentv2 for new integrations, with separate analytics and advertising permissions. Denying those permissions does not necessarily stop data collection: a loaded Clarity tag can continue operating without cookies. Microsoft's Consent API v2 reference.
A reliable implementation therefore answers two questions: what permission should Clarity receive, and should the Clarity script run at all in that state? This guide covers the website integration, the distinction between cookie control and collection, and a practical browser test plan.
What changed in Clarity's consent requirements?
Microsoft began enforcing consent signals for page visits from the EEA, UK and Switzerland on 31 October 2025. Its announcement ties valid signals to full feature functionality. This is Microsoft's product requirement, not a new law or a legal deadline introduced by Microsoft. Clarity's cookie consent update.
The visitor's location matters, even when the organisation operating the website is elsewhere. Check actual regional defaults in each Clarity project rather than assuming the location of your business determines the configuration.
Microsoft now recommends consentv2; its integration guide describes the older clarity('consent', true | false) API as deprecated. An existing banner is not sufficient if its decisions never reach the running tag. Clarity CMP integration guide.
Decide whether Clarity should load before consent
Clarity's Consent Mode controls cookie use. Microsoft documents that denied analytics consent still allows cookieless collection when the tag loads. Denied advertising consent prevents sharing with Microsoft Ads according to its current behaviour table. Clarity consent management.
Choose and document the collection behaviour your organisation intends to permit:
| Implementation decision | What to verify |
|---|---|
| Clarity is blocked until the relevant permission is granted | Neither its script nor its collection requests run before permission. A grant releases the tag and passes the approved state. |
| Clarity loads with denied storage permissions | Consent Mode is configured correctly, cookies match the denied state, and any continued collection has been assessed and disclosed. |
| Clarity is excluded from particular pages | Direct visits and client-side navigation cannot activate it on those pages. |
These are implementation choices, not a statement that both collection models are legally available in every situation. Cookieless does not mean exempt from privacy rules. The UK's current guidance addresses storage and access technologies beyond cookies, including when consent or an exception applies. Assess the actual technology and purposes rather than assuming an analytics label creates an exemption. ICO storage and access technologies guidance.
For the wider assessment, read our GDPR cookie consent guide. A working API does not settle lawful basis, transparency, contracts or international transfers.
Map analytics and advertising choices separately
The direct API uses case-sensitive property names with a capital S. Its values are lowercase strings, not booleans.
| Clarity API field | Choice to map | Example |
|---|---|---|
analytics_Storage | Permission for the relevant analytics purpose | "granted" or "denied" |
ad_Storage | Permission for the relevant advertising purpose | "granted" or "denied" |
Do not grant advertising permission merely because a visitor accepted analytics. Microsoft documents that these permissions work independently. Clarity CMP integration guide.
For example, a visitor accepts the analytics purpose disclosed for Clarity and rejects advertising. Once your integration has resolved those choices, the corresponding call is:
window.clarity('consentv2', {
analytics_Storage: 'granted',
ad_Storage: 'denied'
});
This is an illustrative API call, not a complete banner or installation. It assumes the Clarity function or its command queue exists. Connect it to your CMP's documented state and lifecycle callbacks; do not paste a permanent grant into a page-load trigger. The API reference shows the supported permission combinations.
Connect the CMP without competing updates
Start by inventorying how Clarity is installed: direct code, a tag manager, a CMS extension, or an advertising integration. Check for duplicate installations before adding another consent handler.
Then choose a maintained integration path:
- Use the CMP's documented Clarity integration where it supports your configuration.
- Use
consentv2when a custom connection is necessary. - Evaluate Clarity's support for existing Google Consent Mode signals if that is already your integration route.
Microsoft documents that Clarity can interpret Google's ad_storage and analytics_storage signals. Those lowercase Google names differ from the direct Clarity API's property names. Verify the selected route on your site rather than adding both routes without checking their interaction. Clarity's Google Consent Mode support.
Resolve a returning visitor's saved preferences before issuing unnecessary state changes. Send the default when no decision exists, the saved state when it does, and updates when a visitor finalises a new choice. Microsoft recommends queueing calls if its script has not loaded and avoiding a default-then-saved-state sequence when saved choices are already available. Clarity CMP integration guide.
For each implementation, record which component owns consent updates. Check that a delayed plugin callback cannot restore an old grant after a visitor rejects tracking.
Handle withdrawal and later visits
When a visitor withdraws both permissions, send both as denied. If only one permission changes, keep the other consistent with the visitor's actual choice.
Microsoft describes rejection as removing existing Clarity cookies and restarting in a limited mode without them. That is different from stopping every request. Do not present a denied API state as proof of zero collection. Clarity Consent API v2.
If your design requires all Clarity collection to stop after withdrawal, test that separate requirement against the already-running script. A tag-manager trigger that blocks future page loads does not demonstrate that code already executing has stopped. Define and verify the lifecycle behaviour with your implementation team.
Keep the revised choice available on subsequent pages and visits. Check that route changes, delayed events and restored browser tabs cannot reapply a stale permission. Withdrawal also does not establish that previously collected information has been erased; handle any applicable deletion request separately.
Test the signal, cookies and requests
Microsoft's project setting can require consent before cookies are written; Consent Mode is enabled by default for visitors from the EEA, UK and Switzerland. Verify the project setting and regional behaviour rather than relying on that default alone. Clarity Consent Mode.
Use an isolated browser profile and the browser's network and storage panels. Test a fresh visit, each supported choice combination, a returning visit and withdrawal. Include representative pages, slow loading and client-side navigation.
| Test | Evidence to inspect |
|---|---|
| No choice yet | The resolved default, script-loading behaviour, outgoing requests and cookie storage |
| Analytics accepted, advertising rejected | Distinct permission values rather than a single grant for both |
| Both rejected | Denied state, expected cookie behaviour and whether collection continues |
| Saved preferences on return | The saved state reaches Clarity without a temporary, unwanted grant |
| Withdrawal after acceptance | Updated signal, cookie removal and the intended collection behaviour on the current page |
| New route or delayed plugin execution | No duplicate installation or stale consent update |
Clarity documents a diagnostic command for a running installation:
window.clarity('metadata', (data, upgrade, consent) => {
console.log('consentStatus:', consent);
}, false, true, true);
The diagnostic output uses lowercase field names and uppercase state values, unlike the direct API input. Check the result against the visitor's choice, then inspect actual requests and storage. A console value alone does not prove correct behaviour. Microsoft's verification instructions.
Microsoft lists _clck for user identification and preferences and _clsk for joining page views into a recording. Its cookie inventory also includes third-party Microsoft cookies. Check the relevant inventory and browser restrictions rather than treating the absence of one cookie as a complete test. Clarity cookie reference.
Interpret reporting changes and review captured content
Without cookie consent, Microsoft documents fragmented reporting: page views become separate sessions, returning visitors are not recognised as returning, and multi-page funnels lose continuity. A rise in session counts after a consent change may reflect that fragmentation rather than increased traffic. Reporting without cookie consent.
Record implementation changes alongside analytics reporting. Compare like-for-like configurations before drawing conclusions about conversion performance or visitor behaviour.
Review capture settings separately from consent. Microsoft's FAQ distinguishes masking of page URL parameters from referrer and clicked URLs, which that setting does not cover. Inspect representative journeys for personal information in URLs, page content and custom data. Consent should not become a reason to collect information the analysis does not need. Clarity masking FAQ.
Frequently asked questions
Does rejecting Clarity cookies stop session recording completely?
Do not assume so. Microsoft documents limited cookieless collection and fragmented, single-page sessions. To require no Clarity collection, control and test whether the tag executes as well as the consent state. Clarity reporting documentation.
Is Clarity Consent API v2 the same as Microsoft UET Consent Mode?
They are separate product interfaces. An integration may connect them, but test the actual installation and its scope. Use our Microsoft UET Consent Mode guide for Microsoft Advertising implementation decisions.
Can Google Consent Mode pass consent to Clarity?
Microsoft documents that it can. Confirm that Clarity receives the intended values and that another integration does not overwrite them. This does not make the two products' APIs interchangeable. Clarity GCM support.
Does a successful consent test establish GDPR or CCPA compliance?
It establishes only the behaviour you tested. Legal scope, purposes, disclosures and other obligations still need review. For California, start with the actual transfers and uses in our sale versus sharing guide, rather than assigning a universal classification to the product name.
Related implementation guides
- Consent signals across Google Consent Mode, GPC and GPP.
- Microsoft UET Consent Mode.
- GDPR cookie consent.
For a review of the banner, consent signals and tag behaviour on your website, request a free consent audit.
