Session replay privacy and GDPR: what each tool records, and what your privacy policy must name Session replay privacy and GDPR: what each tool records, and what your privacy policy must name

Why replay is caught even when it sets no cookie

Article 5(3) of Directive 2002/58/EC covers storing information, or gaining access to information already stored, in the terminal equipment of a user. Nothing in that sentence mentions cookies.

The EDPB closed the argument in Guidelines 2/2023 v2.0, adopted 7 October 2024:

¶33 — “Additional examples would include JavaScript code, where the accessing entity instructs the browser of the user to send asynchronous requests with the targeted information. Such access clearly falls within the scope of Article 5(3) ePD.”

That is a description of how every replay SDK works. ¶53 adds that being “produced locally does not preclude the application of Article 5(3) ePD”, and ¶12 removes the “it isn’t personal data” defence: “the notion of information includes both non-personal data and personal data.”

Two obligations, not one. The ePrivacy consent covers the read/write; processing the resulting personal data needs its own Article 6 basis on top (CNIL draft, ¶28).

The UK: your A/B tests probably don’t need consent. Your recordings do.

The ICO’s Guidance on the use of storage and access technologies was finalised 29 April 2026. The Data (Use and Access) Act gave the UK a statutory “statistical purposes” exception the EU does not have, and the ICO published a table of what falls inside it.

Read the column header carefully: the regulator hedges on one side and not the other. The ✔ side is “likely to meet the statistical purposes exception” — an indication, not a clearance. The ✗ side is flat: you must obtain consent.

A UK regulator, in finalised guidance, saying session recordings need consent — inside the document whose entire purpose is telling you which analytics don’t.

The conditions attached. Output must be aggregate and non-identifying; the ICO suggests daily aggregation, “or hourly” at large volumes. You must offer “a simple means of objecting, free of charge”, which it says can be a toggle in your existing consent UI defaulted on. The exception dies the moment you “make inferences or take decisions about people”, and it is never available for advertising. And for vendor selection: “your third party provider must be a processor, not a joint controller.”

So gate replay separately. Run analytics and experiments under the exception with an objection toggle, and put the consent wall in front of recording only. Gating the whole stack is more than the ICO asks for, and it costs you data you were entitled to.

France: the regulator wrote a document about this exact tool

On 25 February 2026 the CNIL opened a consultation on a projet de recommandation concernant les outils de rejeu de session. It closed 22 April 2026, and as of 26 July 2026 no final version has been adopted — the draft says of itself that it “n’est pas exhaustif et ne présente pas de caractère règlementaire.” Treat it as a draft, not as French law — and as the most specific published guidance any regulator has produced on this category.

• ¶19 — consent required, no exemption. The purposes “sont soumises au consentement préalable des utilisateurs”, because they “ne sont pas strictement nécessaires à la fourniture des services.”
• ¶14/¶15 — purposes fixed before you deploy. Three are named: error detection, UX improvement, customer support. ¶17 adds: prefer the lighter tool, and never use replay for ad retargeting.
• ¶36 — withdrawal must actually stop capture, not just hide the banner.
• ¶43 — masking should default to ON: “En cas d’absence de configuration, le masquage devrait par défaut s’appliquer à toutes les catégories envisagées.” ¶48 hard-blocks passwords and banking data.

Retention by purpose, not one number for the whole tool. Annexe 1 asks for “quelques heures après la fin de la session” for customer support, and “quelques mois” for UX and error work. One counter-intuitive point for your DPIA: for those two purposes the draft says there is no justification for linking a session to a user identifier at all.

The United States: split, and mostly about standing

The fight is about standing and consent, not about whether replay is inherently unlawful — and whether a case survives turns on what the plaintiff typed, not on what the tool is.

Two precedential decisions, both Third Circuit:

Contents versus characteristics is the line that decides how you configure a tool. What a visitor typed is contents. That they focused a field, struggled and abandoned it — without the value — sits closer to characteristics. That is the legal reason redaction defaults matter; it is not a promise that redaction is a defence.

The Third Circuit’s factual findings are quotable because a federal court made them. BPS “procures Session Replay Code … such as Microsoft, Quantum Metric, and Mouseflow”, and that code captures text typed into fields even where the user never submits, “in intervals just milliseconds apart.” That is a factual allegation the court accepted as pleaded, not a finding that any vendor broke the law.

A different exposure: CCPA/CPRA — opt-out handling, disclosure and vendor contracts, from the regulator’s own announcement pages:

CPPA enforcement head Michael Macko, announcing Todd Snyder: “Businesses should scrutinize their privacy management solutions … Using a consent management platform doesn’t get you off the hook for compliance.” That mirrors CNIL ¶32 — a contract that merely assigns the consent duty to the publisher is not enough.

One more reason masking is not a US defence. CIPA §638.51 pen-register claims are about routing and metadata, not content — redaction is a strong answer to a §631 contents claim and a weak one here. California SB 690, which would strip the private right of action for website conduct, was amended in the Assembly on 2 July 2026 and has not passed (leginfo.legislature.ca.gov, read 26 Jul 2026).

What each replay tool records before you configure anything

Every cell is from the vendor’s own documentation, read 26 July 2026. “Default” means out of the box, before you touch a setting.

Hotjar and Contentsquare are one company, and that changes the row. Hotjar Ltd. merged into the Contentsquare Group on 1 July 2025, and “Access to Contentsquare on insights.hotjar.com is no longer available to new customers” — we checked that half independently: hotjar.com/signup/ returns 404, hotjar.com/pricing/ 308-redirects to contentsquare.com/pricing. The row stays because the legacy tag still runs, but moving to the Contentsquare tag replaces your masking configuration rather than carrying it over: “By default, your Contentsquare account is set to mask all text and numbers across pages… This differs from Hotjar’s suppression settings.” If you are on Hotjar, your redaction review is due at migration, not after it.

Three of the strongest input defaults come from two companies — Contentsquare and its legacy Hotjar tag, plus Clarity, whose masking is the most tamper-proof because its own docs say it “can’t be customized.” LogRocket is the outlier, and one config change fixes it — but it is the default, and defaults are what Article 25 is about.

Rendered page text is everyone’s blind spot, including ours. Apart from Contentsquare’s account default, Clarity’s Balanced mode and Fullstory’s Private by Default, none of these tools masks displayed text out of the box — and on an order confirmation the sensitive data is printed on the page, not typed into it. Check that page first.

One axis this table does not score, and checklist item 1 ranks it above masking: consent tooling. Mtrix has none — no consent API, no CMP integration; you gate it by not loading the script. Clarity sits at the other end: a Consent API (clarity("consent", false) revokes), CMP integrations “such as CookieYes”, Google Consent Mode “coming soon”, IP geolocation to identify EEA/UK/Switzerland visitors, and a default that limits collection for them absent a signal — “Without proper consent, Clarity limits data collection in those regions to remain compliant with privacy laws” (Clarity FAQ, read 26 Jul 2026). Between those ends, read each vendor’s own consent docs rather than assuming parity: we verified Clarity’s and Mtrix’s, not the other four.

None of this carries over between vendors. A switch is a re-implementation of your masking rules — covered on our Contentsquare and Fullstory pages.

What Mtrix masks by default — and what it doesn’t

Stated from the shipped SDK rather than from a brochure.

Masked before anything leaves the browser. Inputs of type password and hidden, and any input whose name, id, autocomplete or placeholder matches a fixed sensitive-pattern list — password, card, credit, cc-, ccnum, cvv, cvc, csc, ssn, social, routing, account-number, bankaccount, token, auth, secret, apikey, pin, dob, date-of-birth — plus <textarea> and contenteditable elements whose name or id matches the same list. Detection runs on the visitor’s device and the value is replaced with bullets, so those values never reach Mtrix.

Not masked until you configure it. email, firstName, phone, address1, anything else outside that list, <select> values, and rendered page text. A visitor’s name, email and street address appear in a Mtrix replay in the clear unless you mask them. Same baseline as Fullstory and Mouseflow; narrower than Contentsquare, Clarity and the Hotjar tag.

Also captured: clipboard copy and paste, and console output — the SDK wraps the host page’s console.warn and console.error. Both are contents in the US sense. Put data-mtrix-block on anything that handles sensitive text.

How you configure it. All are inherited by child elements, so one attribute on a wrapper covers everything inside:

One trap: data-mtrix-unmask on a wrapper silently unmasks the password field inside it — use it on leaves, never on containers.

Consent gating: Mtrix has no consent API and no CMP integration. Gate it the way the law requires — do not inject the Mtrix script until your CMP signals consent, then call mtrix.init() from the consent callback. Initialising session recording with sessionRecording.tracking: false stops the recorder, but init() still writes the mtrix_user_id and mtrix_session_id cookies and stores ad click-IDs for 90 days — so it is not a lawful pre-consent state under Article 5(3). On withdrawal, call mtrix.stopRecording() and clear those cookies.

Capture rate is 100% by default, sampling opt-in — a completeness strength and a minimisation trade at once.

If you call setIdentify(), know what it does. It stores the email and phone you pass — raw, not hashed — in a JavaScript-readable cookie for 90 days, which means any other script on the page can read them, and attaches them to later events. For UX or error work that is exactly the identifier linkage the CNIL draft says has no justification.

Retention. Session recordings and error data are kept one month; analytics events are kept three years. The one-month replay window sits inside the CNIL draft’s few-months ceiling for UX and error work; the three-year event window is the one your DPIA should justify. Binding terms are in your DPA.

Mtrix is web only — no native iOS or Android SDK, so an app privacy review is out of scope here.

Two governance features do ship: location-based consent rules, and automated deletion scheduling. Both are live in the product.

No product is GDPR-compliant. A deployment is. Anyone selling you “GDPR-compliant session replay” is selling you a configuration you still have to make, and that includes Mtrix.

Your replay vendor is either a processor or a controller. Ask which.

This separates vendors more sharply than any feature list. The CNIL draft (¶10) says a provider that reuses session data “afin d’améliorer la solution fournie” becomes a controller for that reuse — and, citing Fashion ID, a joint controller for the read/write.

Ask three things, and get them in writing:

1. Are you a processor or a controller for this data?
2. Do you reuse our visitors’ sessions for your own purposes — product improvement, model training, advertising?
3. Can you delete one individual’s sessions, or only the whole project?

Strong defaults and strong governance are different axes, and the leaders differ on each. Microsoft Clarity has the strictest input masking on the table and answers question one against itself in its own FAQ: “Clarity is GDPR-compliant as a data controller,” and “Microsoft/Clarity has access to the data.” On question three: “You need to delete the entire project to delete user’s data.” Recordings are kept 30 days, but “Favorite recordings and randomly selected sample of recordings are retained for up to 9 months” (Clarity FAQ, doc updated 30 June 2026). LogRocket is the mirror image — the weakest input defaults on the table, and a privacy policy stating data “is transferred to and processed in the United States”, under the EU–U.S. Data Privacy Framework, to which it has “certified to the U.S. Department of Commerce”. If your DPIA requires EU residency, that is a sales conversation, not a setting.

None of that makes Clarity the wrong choice. It is genuinely free with no traffic limits and no sampling, and its input masking cannot be switched off. For a brand that wants replay at zero cost and can live with a co-controller it is the honest answer. It is a poor fit if you have to satisfy an erasure request without deleting your analytics.

Mtrix’s answer (from Mtrix’s own DPA, privacy policy and security page, read 26 Jul 2026). AWS is the sole infrastructure sub-processor — email, monitoring and support run in-house — and it hosts your data in the EU, with 30 days’ notice and a 30-day objection window before a sub-processor changes. Mtrix is established in Estonia and offers EU SCCs Modules Two and Three, the UK IDTA and the Swiss adaptation. It never sells personal data and never shares it for cross-context behavioural advertising, and sets no third-party cookies — identity travels in the request body. It does write four first-party cookies: a visitor ID for 30 days, a session ID for 60 minutes and two ad-match cookies, plus first-touch ad click IDs kept 90 days. All four are Article 5(3) storage, so they belong behind the same consent gate as the recorder. Payloads are AES-256-GCM encrypted in the browser; error and performance payloads are scrubbed for PII. Mtrix is SOC 2 Type II and ISO 27001 certified, with GDPR, CCPA/CPRA and HIPAA/HITECH compliance programmes.

The implementation checklist

Six things an operator can run this week.

Then budget for the data you will lose. Gating replay in the EU and UK means a meaningful share of your European sessions are never recorded. Plan your sample sizes around it. Then talk to counsel.

Mtrix runs session replay on the same script as analytics, experiments and error tracking. Credentials and payment fields are masked on the device; names, emails and addresses are not, until you mask them — the attributes are above and they take an afternoon. One sub-processor (AWS), hosting in the EU. Start your free month

FAQ