Open your WooCommerce store’s cookie banner and find Microsoft Clarity. Chances are it is sitting in the analytics category — alongside Google Analytics, right where you put it when you installed the plugin. It looks correct. It feels compliant. It is neither.
Microsoft Clarity is a marketing cookie under GDPR. Not analytics. The distinction is not semantic — it determines whether your consent is legally valid, whether your session data is being collected at all, and whether your cookie banner is accurately disclosing what actually happens to your visitors’ data. From October 31, 2025, Microsoft began enforcing consent signals for EEA, UK, and Switzerland visitors. Stores that got the category wrong lost their Clarity data and likely do not know it yet.
Why Clarity Is a Marketing Cookie, Not Analytics
The distinction comes from Microsoft’s own Terms of Service. Section 4.4(c)(iii) grants Microsoft the right to use data collected through Clarity for advertising purposes — including to improve Microsoft’s own ad products and services. That use goes beyond measuring your site’s performance. It is a commercial data use that benefits Microsoft’s advertising business.
Under GDPR, the consent category must reflect the actual purpose of the data processing — including third-party uses. Analytics consent covers tools used to measure and improve your site’s own performance. Marketing consent covers tools where data is used for advertising purposes, whether that is your advertising or the vendor’s.
Clarity falls in marketing because the data benefits Microsoft’s advertising business, not just your analytics dashboard.
The practical consequence: a visitor who accepts analytics cookies but rejects marketing cookies has not given valid consent for Clarity. If your banner has Clarity under analytics, you are collecting session recordings, heatmaps, and funnel data on visitors who, by their own consent choice, should be excluded. That is unlawful processing — and it is invisible to you until a regulator runs a network trace.
You may be interested in: Adding a Cookie Banner to WordPress Does Not Make You GDPR Compliant
What October 31, 2025 Changed
Before October 31, 2025, Microsoft Clarity ran in a consent-optional mode for many implementations. Session recordings collected regardless of banner status unless you had specifically configured the Clarity Consent API to gate collection.
From October 31, 2025, Microsoft enforced mandatory consent signal requirements for visitors from the EEA, UK, and Switzerland. Without a properly implemented Clarity Consent API, Clarity now treats every page load from those regions as a new session with no persistent data. Heatmaps stop accumulating. Session recordings are lost. Funnels break. Rage click data disappears.
The enforcement did not just create a compliance problem. It created a data loss problem. Stores that missed the deadline are running Clarity and seeing it in their dashboard — but collecting nothing useful from their EU and UK visitors.
Without the Consent API correctly implemented, every EEA visitor is treated as a brand new anonymous session on every page load. Your heatmaps show ghost traffic. Your funnels have no continuity. The tool is installed but functionally broken for a significant portion of your audience.
The Specific Problem: Consent API Wired to the Wrong Category
Many stores did implement the Clarity Consent API after the October 31 deadline — but wired it to their analytics consent signal. That means Clarity activates when a visitor accepts analytics cookies. It should activate when a visitor accepts marketing cookies.
If your CMP fires the Clarity Consent API on analytics acceptance, you have the right mechanism but the wrong trigger. Visitors who accept analytics but decline marketing are still having Clarity activate on their sessions. Their data is still being processed without valid consent for the actual purpose of that processing.
This is the miscategorisation problem in its most dangerous form: the technical implementation looks correct in your CMP dashboard, but the legal basis underneath it is wrong because the consent category does not match the data use disclosed in Microsoft’s ToS.
You may be interested in: Does Your WooCommerce Tracking Plugin Fire Pixels Before Consent Is Given?
How to Audit and Fix Your Clarity Setup
The audit takes five minutes. The fix takes fifteen. Here is the sequence.
Step 1: Check the current category
Open your CMP (CookieYes, Complianz, Cookiebot, or whatever you use) and find the Microsoft Clarity cookies. The primary Clarity cookie is _clck and _clsk. Check which category they are assigned to. If it says analytics, that is the problem.
Step 2: Reclassify to marketing
Move _clck, _clsk, and any other Clarity-associated cookies from the analytics category to the marketing category. Most CMPs allow you to edit cookie categorisation directly. If your CMP has a pre-built cookie database that auto-classifies Clarity as analytics, override it manually. The auto-classification is wrong.
Step 3: Implement or re-wire the Consent API
The Clarity Consent API call looks like this:
clarity("consent", true); // when marketing consent granted
clarity("consent", false); // when marketing consent denied or not yet givenThis call must fire in response to your visitor’s marketing consent decision — not analytics. If you previously had it wired to analytics consent, update the trigger. The call should fire after your CMP communicates the visitor’s choice, with the boolean reflecting marketing consent specifically.
Step 4: Verify with a network inspector
Load your store in a private browser. Reject all cookies. Open DevTools → Network and filter for clarity.ms. No requests should fire. Then reload and accept marketing cookies. Clarity requests should appear. If Clarity fires on rejection, the Consent API is not implemented or not wired correctly.
What This Means for Your WooCommerce Analytics Stack
The Clarity miscategorisation issue points to a broader pattern: consent category decisions are made at plugin install time, often auto-populated by CMP cookie databases, and rarely revisited. Cookie databases get it wrong. Vendors update their ToS and the category should change but nobody flags it. Your banner reflects a consent posture that has drifted from the actual data use.
For most WooCommerce stores, Clarity is the most visible example of this drift. But it is not the only one. Any tool that sends data to a vendor who uses it for advertising — and that description covers more tools than most store owners realise — belongs under marketing consent regardless of how the plugin markets itself.
The Transmute Engine™ approach addresses this at the architecture level: events are routed server-side, consent decisions are enforced at the data layer before anything leaves your infrastructure, and the purpose of each data flow is explicit in your pipeline configuration. That makes consent category audits straightforward because the data flow is documented rather than inferred from a vendor’s ToS footnote.
You may be interested in: Microsoft Clarity for WooCommerce: Free Heatmaps and Session Recording
Key Takeaways
- Microsoft Clarity is a marketing cookie, not analytics. Microsoft’s ToS Section 4.4(c)(iii) permits advertising use of Clarity data — that purpose requires marketing consent under GDPR.
- October 31, 2025 enforcement means stores without a correctly implemented Clarity Consent API are losing all session recording data for EEA, UK, and Switzerland visitors right now.
- The Consent API wired to analytics consent is still wrong. It must respond to marketing consent specifically — not the analytics consent signal.
- Audit takes five minutes: find
_clckand_clskin your CMP, check the category, move to marketing if wrong, re-wire the Consent API, verify with a network inspector. - Consent category drift is common. CMP auto-classification databases get it wrong. Review your full cookie list annually — especially when vendors update their Terms of Service.
clarity("consent", true) when a visitor accepts marketing cookies and clarity("consent", false) when they decline or before consent is given. The trigger must be tied to your CMP’s marketing consent signal — not analytics. Verify by loading your store with all cookies rejected and checking DevTools → Network for any clarity.ms requests. There should be none.”}]} –>
Yes — and it requires marketing consent specifically, not analytics consent. Microsoft’s Terms of Service permit use of Clarity data for advertising purposes (Section 4.4(c)(iii)), which means the data use goes beyond site analytics. Under GDPR, the consent category must reflect the actual purpose of processing, including third-party uses. Clarity belongs under marketing.
Most CMP cookie databases auto-classify Clarity as analytics because it presents as a behaviour analytics tool. But the legal category depends on the data use, not the product positioning. Because Microsoft uses Clarity data for advertising purposes under its ToS, it legally requires marketing consent. The auto-classification is wrong and must be manually overridden.
Your consent is invalid for visitors who accepted analytics but rejected marketing. Clarity is collecting their session data without a valid legal basis for the actual purpose of that processing. This is a GDPR Article 6 violation — the same type of consent miscategorisation that regulators identify during cookie banner audits using network inspection tools.
Fire clarity("consent", true) when a visitor accepts marketing cookies and clarity("consent", false) when they decline or before consent is given. The trigger must be tied to your CMP’s marketing consent signal — not analytics. Verify by loading your store with all cookies rejected and checking DevTools → Network for any clarity.ms requests. There should be none.