How to Cleanly Mask PII (Personally Identifiable Information) in Clarity Without Losing Context

What PII Actually Leaks in Clarity (Without Custom Masking)

Open any Clarity session recording from a form-heavy page. By default, what visitors type is already hidden:

• Email addresses typed into form fields — masked (input boxes are masked in every mode)
• Phone numbers typed into fields — masked
• Full names typed into "Name" fields — masked
• Addresses typed into shipping forms — masked
• Date of birth on demographic forms — masked, whether typed or picked from a drop-down menu
• SSN or government ID on identity verification forms — masked when typed into an input box
• Credit card numbers — masked when typed into an input box, whatever its autocomplete attribute

This is not an attack on Clarity — the same issue exists with Hotjar, FullStory, LogRocket, and every session recording tool. What the default Balanced mode leaves readable is ordinary page text: it treats only numbers and email addresses as sensitive, so a name or street address your page shows back to the visitor is recorded unless you mask that element.

Privacy implications:

• GDPR: EU users have right to data minimization. Storing their email/name/phone in session recordings without explicit consent and a documented purpose is a violation.
• CCPA: California residents have right to deletion. PII in session recordings must be deletable when requested.
• HIPAA: Healthcare information (including names, emails, dates of birth) in session recordings is PHI. Unmasked PHI in a third-party tool is a HIPAA violation.
• Financial regulations: Account numbers, SSNs, and certain types of client data captured by financial services are subject to specific protection requirements (GLBA, PCI-DSS).

The 5 Data Categories That Need Different Treatment

Category 1: Hard identifiers (mask fully)

SSN, government ID numbers, credit card numbers, bank account numbers, medical record numbers. These should be COMPLETELY masked — not even character count should be visible. Treatment: data-clarity-mask="True" on the input, OR ideally the value never reaches the DOM (server-side rendering, secure iframes from payment processors).

Category 2: Contact info (mask content, keep field shape)

Email addresses, phone numbers. Mask the actual value (user typed something), but preserve the fact that they typed in the field, character count, and timing. Treatment: data-clarity-mask="True" applied to the input. Clarity will show that something was typed (visible cursor, character timing) but not what.

Category 3: Names & addresses (mask content, keep field shape)

First name, last name, full address, city, postal code. Same treatment as contact info — mask the content, preserve the interaction patterns. Treatment: data-clarity-mask="True".

Category 4: Selections & clicks (capture normally)

Dropdown selections, radio button choices, checkbox toggles, button clicks. These almost never contain PII (they’re predefined options). Capturing them is high-value for CRO analysis, with one limit: Clarity masks drop-down menus in every mode, so do not count on reading the selected option in a recording. Treatment: no extra masking.

Category 5: UI/navigation (capture normally)

Page transitions, scroll behavior, layout interactions, hover patterns. Zero PII risk; high CRO value. Treatment: no masking.

The principle: mask CONTENT in PII-bearing fields, preserve everything else. You still see the user typing in the email field (which tells you they engaged with it), how long they took, whether they corrected typos, whether they rage-clicked elsewhere after. You just don’t see the actual email address.

Implementation: The Selective Masking Setup

Method 1: HTML attribute on specific fields

The simplest approach: add data-clarity-mask="True" directly to PII-bearing input elements.

<!-- Mask the value but preserve interaction patterns -->
<input type="email" name="email" data-clarity-mask="True">
<input type="tel" name="phone" data-clarity-mask="True">
<input type="text" name="full_name" data-clarity-mask="True">
<input type="text" name="street_address" data-clarity-mask="True">

<!-- Don't mask selections or buttons -->
<select name="industry">...</select>  <!-- No mask needed -->
<input type="radio" name="company_size" value="50_to_200">  <!-- No mask -->

<!-- Mask the WHOLE container if it might contain PII -->
<div data-clarity-mask="True">
  <p>Account number: {{ user.account_number }}</p>
</div>

Method 2: CSS class-based masking

For sites where you control templates centrally, use a CSS class approach:

<!-- Define a single class for all PII inputs -->
<style>
  .pii-field { /* visual styles */ }
</style>

<script>
  // Auto-apply data-clarity-mask to all .pii-field elements
  document.querySelectorAll('.pii-field').forEach(el => {
    el.setAttribute('data-clarity-mask', 'True');
  });
</script>

<!-- Then in templates -->
<input type="email" class="pii-field" name="email">

Method 3: Server-side defensive defaults

Most robust approach for regulated industries: render any field type that COULD contain PII with masking enabled by default, then explicitly opt-out for non-PII fields. Reverses the failure mode — new fields are private by default, not exposed by default.

{# Base form template — masks by default #}
<input type="{{ field.type }}" name="{{ field.name }}"
       {% if field.type != 'submit' and field.type != 'checkbox' %}
         data-clarity-mask="True"
       {% endif %}>

{# Specific opt-out for non-PII text inputs #}
{% block special_dropdown %}
  <select name="industry">
    {# No mask — industries are predefined options #}
  </select>
{% endblock %}

Tracking Behavior Without Capturing PII

The trick to preserving CRO value while masking PII: track INTERACTIONS, not VALUES. Examples:

• Email field interaction: Track "user typed 12 characters in email field" via custom event, not the actual email. Tells you they engaged; doesn’t leak the address.
• Form completion timing: Track "user spent 47 seconds on form" via duration tracking. Reveals friction without exposing data.
• Field validation failures: Track "email field failed validation 3 times" via error event count. Reveals UX issues without storing the wrong-formatted emails.
• Field correction patterns: Track "user deleted and retyped name field" as a behavior signal. Indicates hesitation or typo-correction without storing the text.
• Tab/focus patterns: Track which fields users focus, in what order, with what dwell time. Reveals form flow issues without capturing entered data.

These behavioral signals provide 80–90% of the CRO insight value of raw text capture, with zero PII risk. The remaining 10–20% (actual text users type) is rarely worth the privacy/legal exposure.

Each row keeps the behavior and drops the value. Record counts, timings and yes/no flags, and neither a recording nor a tag ever holds personal data.

Validation: Auditing for PII Leaks Monthly

Configuration is not enough. New form fields, marketing campaigns, and code deploys can introduce PII leaks without anyone noticing. Set up a monthly validation routine:

1. Sample 20 random sessions from the past 30 days.
2. For each session, look for visible text in form fields. Should be all masked dots/asterisks. If you can read an email or name, that’s a leak.
3. Check key forms specifically: demo request, contact, newsletter signup, checkout, account creation. New forms are highest-risk because they may not have been added to the masking config.
4. Look at custom tags: ensure no tag values contain PII (e.g., last_email: "joe@example.com" is a violation; email_was_provided: "yes" is fine).
5. Log findings in a tracker. Each violation gets a ticket. Each ticket has a fix deployed within 7 days. Document fixed-vs-found rate as a privacy KPI.

HIPAA-Specific Considerations

For Dallas healthcare clients, HIPAA imposes stricter requirements than GDPR. Key additions:

• BAA required: HHS says a tracking vendor must have a signed BAA before any PHI is disclosed to it, and that a vendor’s promise to remove or mask the PHI is not enough. Microsoft describes Clarity as a free service with no paid version, so get written confirmation that a BAA is available before using it on pages that handle patient information; without one, keep Clarity off those pages.
• Mask broader categories: Beyond standard PII, HIPAA-relevant PHI includes any combination of identifiable + health information. Pages discussing specific conditions, treatments, or medication should mask interactive elements that could reveal patient identity.
• No recording of patient portals: Even with masking, patient portal pages typically should not be recorded at all. Use page-level exclusion in Clarity to skip these URLs.
• Document your config: HIPAA audits will ask. Maintain a "Clarity masking configuration" document showing what’s masked, what isn’t, and why each decision was made.

The full setup pattern for healthcare lives in our Clarity setup guide for Dallas healthcare practices.

Worked Example: Taking a Dallas Healthcare Practice to HIPAA-Compliant Analytics

Consider a Dallas-based multi-location medical practice that needs to deploy Clarity in a HIPAA-compliant way. Suppose the existing setup is Clarity installed with default config, no element masking and no BAA, with recordings kept for Clarity’s standard 30 days — and the compliance officer has flagged this as a critical violation.

A migration plan:

• Day 1: Disable all existing recordings, mark for deletion at 30-day retention boundary
• Week 1: Get written confirmation from Microsoft on whether a BAA is available for Clarity (it is a free service with no paid tier); if not, keep it off every page that handles patient information
• Week 2: Implement selective masking using Method 2 (CSS class-based) across all forms
• Week 3: Exclude patient portal URLs from recording entirely
• Week 4: Set up custom tags for behavioral signals (form abandonment, validation errors, completion timing)
• Week 5: Validate with 30-session audit; document compliance config

5 Common PII Masking Mistakes

• 1. Masking everything aggressively. Hides legitimate CRO insights. Selective masking is better — PII content hidden, interaction patterns visible.
• 2. Forgetting new forms. New marketing campaigns add new forms. Each new form needs to be added to the masking config. Build this into deploy checklists.
• 3. Using "type=password" hack for non-passwords. Some teams set sensitive fields as type="password" believing only password fields are masked. Clarity already masks every input box. This breaks autofill, accessibility, and mobile keyboard hints. Use proper data-clarity-mask attribute instead.
• 4. Capturing PII in custom tags. Custom tags are searchable in Clarity dashboard. Never set tags with actual email/phone/name values — use behavioral counts instead.
• 5. Never validating. Configuration drift happens. Monthly validation audits catch leaks before they become incidents. Make this a recurring calendar event.

For Dallas businesses with regulated-industry exposure (healthcare, finance, legal) or significant EU traffic, the selective masking framework is non-negotiable. For everyone else, it’s still strongly recommended — CCPA expansions and state-level privacy laws (Texas Data Privacy Act, etc.) are making strict PII protection a default expectation, not an edge case. Implement this once, validate monthly, and your behavioral analytics stays both legal and useful.

Frequently Asked Questions