What Clarity Actually Records

The Clarity SDK (loaded from www.clarity.ms/tag/{project_id}) initializes a global clarity object and identifies visitors with a Microsoft-owned cookie called _clck, alongside a session cookie _clsk. From that moment, the script captures a dense behavioral stream:

• Mouse and touch input — every movement, click, tap, scroll, and gesture is recorded with timestamp and coordinates.
• Form interactions — focus, blur, and input events on every form field, plus the text of non-sensitive fields if masking is not configured.
• DOM snapshots — periodic full snapshots of the page DOM so the session replay can reconstruct the exact visual state at any moment.
• Custom events — any events the application explicitly emits via clarity("event", "name") calls.
• Performance and error data — JavaScript errors, network failures, and core web vitals timings.
• Identifier data — the Clarity-owned cookie plus IP-derived geolocation and user-agent fingerprinting.

The combination — particularly the DOM snapshots and form-field capture — makes Clarity functionally equivalent to a video recording of the visitor's session. The regulatory classification under the GDPR is straightforward: this is processing of personal data, the cookies are non-essential, the data crosses borders to Microsoft's US infrastructure, and the lawful basis required is consent. The CNIL's 2024 guidance on session recording is unambiguous on this point and explicitly names tools in Clarity's category.

The Sensitive-Data Risk

Session recording tools have a specific privacy hazard that other analytics tools do not: they can capture sensitive personal data accidentally. A user typing a credit card number, a health condition, a religious affiliation, or a national identifier into any form field is recorded by Clarity if the field is not explicitly masked. Under the GDPR this is processing of Article 9 sensitive personal data, which requires explicit opt-in consent and is rarely covered by a general marketing-consent decision.

Clarity supports a content-masking configuration that hides specific fields from recording, but the default behavior captures everything. The audit-defensible approach is to mask aggressively — assume every form field is sensitive until proven otherwise — and to document the masking decisions explicitly.

Native Clarity Privacy Controls

Microsoft has invested in Clarity's privacy controls over the past two years. The platform now exposes several primitives that a CMP integration can leverage.

The mask attribute

Adding data-clarity-mask="true" to a DOM element hides its content from the session recording. Adding data-clarity-unmask="true" to a child element overrides the mask for that subtree. The right default for any form field that could contain personal data is to mask, then explicitly unmask where it is safe.

The consent API

Clarity exposes a clarity("consent") call that, when invoked, signals that consent has been granted and the SDK should proceed. Without this call, the SDK can be configured to stop after initial load. This is the right primitive for CMP integration on the activation side.

IP masking and identifier handling

The Clarity project settings expose options for IP truncation and identifier masking. Enabling these is a defense-in-depth measure on top of CMP gating; it does not substitute for consent.

Sensitive content auto-masking

Recent Clarity releases attempt to auto-detect sensitive fields (credit card patterns, password fields, fields named "ssn" or similar) and mask them by default. The detection is heuristic and incomplete; do not rely on it as the only line of defense.

Step-by-Step CMP Integration

The reliable architecture is to defer the Clarity SDK entirely until consent is granted, then activate it explicitly via the consent API.

1. Remove the default tag from the document head

The Clarity installation snippet is a single inline script that initializes the SDK on page load. Replace it with a placeholder script element whose type is text/plain and whose data-category is analytics or marketing depending on how your CMP categorizes session-recording tools.

2. Decide on category mapping

Session recording is a contested category. The CNIL has treated it variously as analytics (when the data is used for internal UX research) and as marketing (when the data feeds personalization decisions or external sharing). The conservative mapping is marketing; the audit-defensible position requires you to be specific about how the recordings are actually used.

3. Configure aggressive masking before activation

Add data-clarity-mask="true" to every form element, every input field, every container that could hold personal data. The default policy is mask-by-default with explicit unmask exceptions for elements known to be safe (page titles, navigation labels, public content blocks).

4. Activate Clarity from the consent callback

When the CMP fires the relevant category-accepted event, rewrite the placeholder script tag and call clarity("consent") to grant the SDK permission to proceed. Queued events that were buffered during the pre-consent period will then flush.

5. Handle revocation explicitly

If the user revokes consent, the Clarity SDK does not have a clean "stop recording" call equivalent to the activation API. The practical pattern is to call clarity("consent", false) if supported in your SDK version, and to additionally clear the Clarity cookies on the client side. For complete deletion of historical recordings, use the Clarity admin UI's data-deletion workflow or the deletion API.

Common Pitfalls

Four integration mistakes account for the majority of audit findings on Clarity deployments.

Installing Clarity "just to see what visitors do"

The most common pattern: a product manager installs Clarity to research a UX problem, never enables consent gating, never configures masking, and forgets about the script. The recording surface keeps accumulating. The remediation is to either remove Clarity entirely or to bring it under the same consent architecture as every other tracker.

Trusting auto-masking

Clarity's heuristic sensitive-field detection catches obvious cases but misses domain-specific ones — a healthcare site's "symptoms" textarea, a finance site's "account number" field with an idiosyncratic name. Mask explicitly; do not rely on detection.

Treating session recording as analytics

The CNIL has been explicit that the session-recording category is closer to marketing than to first-party analytics from a consent perspective. Gating Clarity under analytics-only consent is defensible only if the recordings are used exclusively for internal UX research and never shared outside the organization.

Forgetting custom event payloads

Application code that calls clarity("event", "name", customProperties) can leak personal data into the Clarity stream through the customProperties payload. Audit every call site and avoid passing user identifiers, email addresses, or any personal data in event properties.

Audit Checklist

Six concrete questions to answer for any Clarity deployment touching EU, UK, Brazilian, or California traffic.

• Does Clarity wait for consent? Open the page in a private window and confirm no clarity.ms requests fire before the banner is accepted.
• Is masking aggressive? Confirm every form field and every container with potentially personal content has data-clarity-mask applied.
• Is the category mapping documented? Confirm there is a written record of whether Clarity is gated under analytics or marketing, with the reasoning.
• Is the consent API wired? Confirm the CMP callback calls clarity("consent") on grant and the equivalent on revocation.
• Are custom events audited? Confirm clarity("event", ...) calls do not pass identifying or sensitive data in their property payloads.
• Is deletion automated? Confirm DSAR requests trigger Clarity's deletion workflow, not a manual support ticket.

Where Clarity Fits in a Consent-First Stack

Session recording is the highest-information-density behavioral tracking surface in common deployment, and Clarity is the tool that has democratized it most aggressively. The free pricing tier and frictionless installation make it the path of least resistance for any team that wants visibility into UX behavior. That same friction-free installation is what makes Clarity the most commonly misconfigured analytics tool in 2026 audits. The right architecture treats Clarity like every other identifying tracker: gate it behind explicit consent, mask form fields aggressively by default, document the category mapping, and wire the consent API so the SDK's own primitives enforce what the CMP recorded. Done correctly, the UX research value the tool was bought for is preserved while the regulatory exposure drops to a fraction of what a default install carries.