The Privacy-First Approach to Session Recording

Session replay tools have a complicated relationship with privacy. The same capability that makes them powerful for debugging — recording what users actually do in your application — is exactly what raises legitimate questions about consent, data minimisation, and the potential for capturing sensitive information you didn't intend to capture.

This tension is real, but it's manageable. The key is to approach session recording with privacy as a design constraint rather than an afterthought — choosing the right recording model, configuring masking carefully, and understanding the regulatory context your application operates in.

Why Privacy Matters More in Session Recording Than Most Analytics

Most web analytics — page views, click events, funnel metrics — capture aggregate, anonymised data. Session replay is different: it captures individual, identifiable sessions in high fidelity. If a user's name is visible on their dashboard, it appears in the replay. If a form field contains personal data, it may be captured unless you explicitly mask it.

This isn't a reason to avoid session replay. It is a reason to be deliberate about how you configure it. A session replay tool with thoughtful defaults and clear masking controls is privacy-respecting. One that records everything by default and requires manual effort to protect sensitive data is a liability.

The Regulatory Context

If your users are in the EU, GDPR applies to session recordings as personal data processing. The key requirements are:

Lawful basis. You need a legal basis for recording. For always-on session replay tools, this is typically legitimate interests or explicit consent. For on-demand recording triggered by a support request, the legal basis is stronger — the user is actively seeking your assistance, which can constitute consent or legitimate interests in a much cleaner way.
Data minimisation. GDPR Article 5(1)(c) requires that you collect only the data that is "adequate, relevant and limited to what is necessary." This principle argues directly against recording everything by default — and in favour of on-demand recording and aggressive masking of fields you don't need.
Storage limitation. You shouldn't retain personal data longer than necessary for the purpose it was collected. Session replays should have defined retention periods, and data beyond those periods should be deleted automatically.
Transparency. Users should be informed that their session may be recorded. This is typically covered in your privacy policy, but for always-on recording you may need a more prominent disclosure.

Under CCPA (California), session recording data that identifies individual consumers is subject to disclosure and opt-out requirements. The specific obligations depend on whether the data is considered "sold" — which support-oriented session capture generally is not — but transparency about data collection practices still applies.

This is not legal advice. The specifics of your obligations depend on your jurisdiction, your user base, and the nature of your application. Review your implementation with legal counsel.

Sensitive Data Categories to Mask

Regardless of your regulatory obligations, there is a set of data categories that should never appear in a session replay. These include:

Passwords. Any input[type="password"] field should be masked by default. A session replay tool that captures password field input is a significant security vulnerability.
Payment card data. Card numbers, CVVs, and expiry dates entered in payment forms should be fully masked. If you're using a third-party payment provider like Stripe, payment fields are typically in an iframe from the provider's domain and won't be captured by your SDK — but verify this explicitly.
Government ID numbers. Social security numbers, national insurance numbers, passport numbers, and similar government-issued identifiers.
Health and medical information. Particularly important for healthcare applications, where additional regulations like HIPAA (US) or similar apply.
Authentication tokens. HTTP headers containing Bearer tokens, API keys, or session cookies should be redacted from network request logs.
Private messages and personal communications. If your application includes messaging features, the content of private messages is particularly sensitive.

Technical Approaches to Masking

Modern session replay tools offer several mechanisms for excluding sensitive data from recordings:

Input type masking

All input[type="password"] fields should be masked by default — most good tools do this automatically. Some tools also allow you to configure masking for other input types (such as type="email" or type="tel") if your application collects particularly sensitive data in those fields.

CSS class and attribute masking

Most session replay SDKs support a masking attribute or class that, when applied to an element, causes its content to be replaced with placeholder characters in the recording. Clairvio uses data-clairvio-mask. Add it to any element containing data you don't want recorded:

<span data-clairvio-mask>{user.creditCardLast4}</span>

This approach puts masking control in the hands of the developer closest to the data, which is the right place for it.

Element blocking

For elements that should be entirely absent from the recording — not just masked, but not present at all — blocking is more appropriate than masking. Blocked elements appear as empty rectangles in the replay. This is appropriate for elements like profile photos, sensitive charts, or any component whose presence in the replay could itself be revealing.

Network request filtering

Request and response bodies in network logs should be filtered to remove authentication headers (Authorization, Cookie, X-API-Key) and any response fields that contain personal data you don't need for debugging. A good practice is to log only the fields you anticipate needing (status code, error codes, relevant IDs) rather than complete request and response bodies.

On-Demand Recording as a Privacy Advantage

The recording model you choose has profound implications for your privacy posture, and it's worth being explicit about this.

Always-on recording captures every user's every session continuously. From a privacy standpoint, this requires a strong legal basis, broad disclosure in your privacy policy, and potentially explicit consent depending on jurisdiction. The data minimisation principle is structurally difficult to satisfy when you're recording everything by default — you're collecting data from users who never had any issues and never needed support.

On-demand recording only captures sessions when a user has specifically sought support and has been sent a magic link. This changes the consent picture significantly:

The user is aware that help requires sharing their session — the magic link makes this explicit by design.
You're only collecting session data from users who need it, which directly satisfies the data minimisation principle.
The retention obligation is limited: you only need to keep sessions long enough to resolve the support case, rather than retaining a continuous recording of all users.
Users who never need support are never recorded.

This doesn't mean on-demand recording is automatically exempt from privacy obligations — it still processes personal data and those obligations still apply. But the model is inherently more aligned with privacy principles than always-on recording, and it makes compliance meaningfully simpler.

Data Retention and Deletion

Session replays should have defined retention periods, and data beyond those periods should be automatically deleted. The appropriate retention period depends on your use case: for support debugging, sessions are typically no longer needed once the case is resolved. A retention window of 30 to 90 days is reasonable for most support contexts.

When users exercise their right to erasure (under GDPR) or deletion (under CCPA), session replays associated with that user should be included in the deletion scope. Build this into your data deletion processes from the start, rather than retrofitting it later.

Building Trust Through Transparency

Beyond the technical and regulatory dimensions, there's a trust dimension. Users who learn that their sessions were recorded without their knowledge — even if technically legal — often feel surveilled. That trust damage can be worse than the privacy violation itself.

Transparency is both the ethical and the practical choice. If you use always-on recording, be explicit about it in your privacy policy and consider an in-app disclosure. If you use on-demand recording via magic links, the mechanism is inherently transparent — the user knows they activated diagnostic recording because they clicked the link.

Privacy-first session recording isn't about not recording — it's about recording deliberately, masking what needs to be masked, retaining what you need and no more, and being clear with users about what you do. Done well, it strengthens rather than undermines the relationship between your product and the people who use it.