A Recording Sees More Than a Pageview Does
Analytics tools count things. Session recording tools watch. Hotjar and Microsoft Clarity replay a visitor's mouse movements, scrolls, clicks, and, unless you stop it, the text they type into forms. That's a different category of data collection, because a recording can pick up a name, an email, a message in a support box, or a health detail on a medical form. So the consent question for these tools reaches past the cookies they set. It covers the recording itself, which is personal data the moment it captures a real person doing real things.
Two rules apply at once. The ePrivacy rule (Article 5(3)) governs the cookies and identifiers these tools store on the device. The GDPR governs the recording as processing of personal data, and if a form contains health or financial information, it can pull you into the stricter special-category rules under Article 9. This is the concept behind our broader piece on session replay privacy risks. Here we get specific about the two tools most teams actually run.
Microsoft Clarity: Consent Became Mandatory in Europe
This one changed recently, and if your setup predates it you may be out of date. On 31 October 2025, Microsoft turned on mandatory cookie consent enforcement for page visits originating from the EEA, the UK, and Switzerland. Clarity's consent mode is now automatically enabled for visitors from those regions, which means Clarity will not place a cookie unless it receives a valid consent signal. No signal, no cookie, and features like session recordings, heatmaps, and funnel tracking may be limited or simply unavailable for that visitor.
Microsoft is clear that the site owner has to send the signal. It supports four ways to do it: the Clarity Consent API for a custom implementation, integrations with consent management platforms, third-party platforms that pass consent for you, and Google Consent Mode. Pick one and wire it up, because the enforcement is on Microsoft's side now. If you never send a signal, EU visitors quietly stop generating the data you installed Clarity to collect.
| Cookie | Purpose |
|---|---|
| _clck | Clarity's own first-party ID that persists a user across sessions |
| _clsk | Ties multiple page views in one session to a single recording |
| MUID | Microsoft user identifier shared across Microsoft domains, used for analytics and advertising |
| ANONCHK | Checks whether the MUID is passed to an ad cookie (returns no for Clarity) |
| SM / MR | Keep the MUID consistent across Microsoft domains and control its refresh |
"No PII in the Cookie" Is Not "No Personal Data"
Microsoft points out, correctly, that Clarity's cookies don't store names or emails. That doesn't take them out of scope. Under the GDPR, an identifier that lets you single out or recognize a device is personal data even when it holds no obvious PII, because it still picks one person out of the crowd. The MUID does exactly that across Microsoft properties. So the cookies need consent in the EU on the identifier grounds, separate from whatever the recording captures.
Hotjar: It Records the Instant It Loads
Hotjar's default behavior is the thing to plan around. Once the script runs, it starts recording. There is no polite pause while your banner is on screen. So the gate has to be the script load itself: don't put Hotjar on the page until the visitor accepts analytics, then inject it. If Hotjar loads first and you try to make the banner do the work afterward, you've already captured a session from someone who never agreed.
Hotjar does default to protecting form input. Keyboard entry into fields is suppressed unless you deliberately allow it, and text inputs are masked by default, so a well-behaved install won't record what someone types into a normal field. But defaults only cover normal fields. Custom components, content rendered into non-standard elements, or a value you echo back onto the page can still surface. Hotjar gives you suppression tags (the data-hj-suppress attribute) to force specific elements to be hidden from recordings. Use them on anything that shows personal data, and test with a real recording rather than trusting the default.
Masking Is Your Job, and It Fails Quietly
Both tools apply default masking, and both let it break silently. If a form component renders outside the standard input elements the tool recognizes, or you display a confirmation like "Thanks, Jane, we sent the results to [email protected]" as page text, that content can land in the recording even with masking on. The failure mode is invisible: you won't get an error, you'll get a recording with an email in it that you only discover during an audit or a complaint. On healthcare, financial, or any special-category form, treat masking as something to configure explicitly and verify, not a checkbox you trust. See healthcare cookie consent for the higher bar these fields carry.
Deploying either tool lawfully
Categorize it as analytics and gate the load
Neither tool is strictly necessary. Hold the script until the visitor accepts analytics. For Clarity, send the consent signal through its Consent API, a CMP, or Google Consent Mode so it knows it may place a cookie.
Verify no cookie is set before acceptance
Clear cookies, load the page, leave the banner alone, and check the Application tab. For Clarity look for _clck, _clsk, and MUID. For Hotjar look for the _hj cookies. None should exist yet.
Configure and test masking on every PII field
Don't rely on defaults for custom components. Add suppression to sensitive elements, then open a real recording and confirm the fields show as masked rather than as their actual values.
Honor opt-out and Global Privacy Control
A withdrawal or a GPC signal has to stop the recording. Hiding a banner isn't enough. Wire the same decision into the recorder's state. See our guide to Global Privacy Control.
Why Regulators Watch These Tools Closely
Session recording sits high on the risk list for a reason. It's the tool most likely to capture something you never intended to collect, and the least likely to be noticed doing it. A poorly masked recorder on a checkout or a patient intake form can accumulate special-category data with no lawful basis and no record of consent. The fix is not exotic: gate the load on consent, log the decision so you can show what the visitor agreed to, mask aggressively, and re-check masking whenever the form changes. Do that and the recordings stay a product insight instead of a liability.
Doing It With CookieBeam
CookieBeam blocks Hotjar and Clarity until the visitor accepts analytics, and for Clarity it passes the consent decision through so the tool switches into its consented mode rather than being cut off entirely. Its scanner detects both recorders, their cookies, and the outbound connections they open during an audit, so you can confirm nothing runs before acceptance instead of assuming the gate holds. Because these tools are the ones most prone to silent scope creep, the scan is worth repeating after any form or template change, which is where a masked field tends to quietly become an unmasked one.
Related Guides and Sources
Continue with session replay and heatmap privacy risks, healthcare cookie consent, and Global Privacy Control explained. Primary sources: Microsoft's Clarity cookie consent update, the Clarity cookies documentation, Hotjar's processing personal data guide, and the ePrivacy Directive Article 5(3).