Session Replay GDPR Consent: The Rules for EU Stores

Key Takeaways

Session replay tools record the visitor's complete browsing path — mouse movements, clicks, scrolling and keystrokes — which the CNIL's draft recommendation treats as tracker read/write operations under Article 5(3) of the ePrivacy Directive, requiring prior consent.
The audience-measurement exemption does not rescue them. The CNIL grants that exemption only to trackers whose purpose is strictly limited to audience measurement alone and which produce anonymous statistics only — and on our reading, a recording of one identifiable person's session is neither.
Microsoft Clarity has enforced consent-signal requirements for EEA, UK and Swiss visitors since 31 October 2025, and its own documentation says Clarity "waits for a valid consent signal before setting any cookies" in those regions.
Clarity's default masking mode, Balanced, classifies only numbers and email addresses as sensitive content. Free-text fields — order notes, return reasons, complaint boxes — are not covered by that default.
The CNIL's draft recommendation of February 2026 asks for retention limited to a few hours after the session ends for customer-support use, and a few months for UX work. It remains a draft; no final version has been adopted.

Introduction

The heatmap looked harmless when the growth team installed it. Then someone opened a recording of a checkout that failed, watched the cursor hover over the card field, and realised they were watching a named customer type — in a tool nobody had put in the record of processing, behind a cookie banner that never mentioned it.

Session replay sits in an awkward spot. It is treated internally as analytics, sold as user experience research, and legally it is neither. This guide sets out why these tools need consent, why the analytics exemption that rescues some measurement tools does not extend to them, what has to be masked, how long recordings may be kept, and how to make the consent signal actually stop the recorder.

This is informational content, not legal advice.

Yes, in the EU and UK. Session replay scripts read and write information on the visitor's device, which brings them inside Article 5(3) of the ePrivacy Directive — the rule that requires prior consent for storing or accessing information on terminal equipment. Neither of the two statutory exemptions covers them.

The CNIL puts the reasoning plainly in its draft recommendation. Session replay involves trackers performing read/write operations governed by Article 82 of the French Data Protection Act, which transposes Article 5(3). Those operations, in the CNIL's words, "n'ont pas pour finalité exclusive de permettre ou faciliter la communication par voie électronique" and "ne sont pas strictement nécessaires à la fourniture des services proposés par les éditeurs, puisque ces derniers pourraient les fournir sans elles" — they do not exist solely to carry a communication, and they are not strictly necessary to provide the service, since the publisher could provide it without them.

That second limb is the one merchants underestimate. The test is not whether the tool is useful to you. The ICO says the same thing in its PECR guidance, and says it in terms that leave no room: "cookies that are helpful or convenient but not essential, or that are only essential for your own purposes, will still require consent."

The obligation attaches to the script, not to the cookie. The EDPB's Guidelines 2/2023 on the Technical Scope of Art. 5(3) of the ePrivacy Directive, Version 2.0, adopted on 7 October 2024, place JavaScript-driven access squarely inside Article 5(3) at paragraph 33. At paragraph 53 the Board adds that information produced locally in client-side code and then "sent back over the network to a server" is still a "gaining of access to information already stored" — "the fact that this information is being produced locally does not preclude the application of Article 5(3) ePD."

Session replay is that paragraph's textbook case: the script builds a picture of the session in the browser and ships it out. We have walked through the same analysis for Klaviyo's onsite tracking script and for Shopify's web pixels, so we will not re-derive it here — the point is that relabelling the recorder's cookie as strictly necessary changes nothing, because the reasoning never turned on the cookie.

Why the Audience-Measurement Exemption Does Not Cover Session Replay

Because the exemption is defined by what the tool produces, not by what it is called. The CNIL exempts audience-measurement trackers only where their purpose is strictly limited to audience measurement alone, they operate for the publisher's exclusive account, and they produce anonymous statistics only. A replay of one person's session is none of those things.

In the CNIL's own words, such trackers must be used "pour une finalité strictement limitée à la seule mesure de l'audience", "pour le compte exclusif de l'éditeur", and must serve "à produire des données statistiques anonymes uniquement". The misconception is an understandable one: many teams file session replay next to their analytics tool in the same "performance" cookie category, then inherit the exemption reasoning that came with it.

What the exemption actually requires

The CNIL's conditions, from its guidance page of 4 July 2025, are cumulative:

Requirement	What it means in practice
Purpose strictly limited to audience measurement	Performance measurement, navigation-problem detection, technical or ergonomic optimisation, server-capacity estimation, content analysis — and nothing else
Exclusive account of the publisher	The vendor may not use the data for its own purposes
Anonymous statistics only	Output is aggregate, not per-person
No cross-referencing	Data may not be combined with other processing, and non-anonymous data may not be transmitted to third parties
No cross-site tracking	No global following of a person across different sites or apps

Even where a tracker does qualify, the CNIL recommends a lifespan capped at 13 months without automatic renewal, retention of the collected data for a maximum of 25 months, and informing users the trackers are deployed — exemption from consent is not exemption from transparency.

Where session replay fails the test

Our reading, and it is a reading rather than a CNIL holding: session replay fails the very first condition, so the rest never comes into play. The output is a viewable reconstruction of an individual session, not an anonymous statistic. The CNIL's own framing supports the direction of travel — its draft describes these tools as being used "en remplacement de mesures plus classiques (par exemple, les outils de mesure d'audience ou « analytics »)", a replacement for classic audience-measurement tools rather than an instance of them — but the draft does not itself state that cross-reference, and we are not going to put words in the regulator's mouth. The practical consequence is the same either way: the general two-limb test quoted above already fails session replay on its own terms.

What the CNIL's Draft Recommendation Asks You to Mask

Masking by default, across every field type, unless you have deliberately configured otherwise. The CNIL's draft asks providers to supply a masking tool covering images, forms, text fields and dynamically filled fields such as account information, and says that absent any configuration, masking should apply by default to all of those categories.

The draft's wording is "les images, les formulaires, les champs de textes et les champs dynamiquement remplis (par exemple contenant des informations de compte)" — the control is labelled M0.

A word on status, because it matters. This recommendation is a draft. The CNIL's public consultation ran from 25 February 2026 to 22 April 2026 and is closed, but no final version has been adopted as of August 2026 — the CNIL's own page still says it will examine the contributions and adopt a final version. Treat what follows as the direction a regulator has signalled, not as a rule you can be fined under today.

The masking ladder

What makes the draft genuinely useful is that it grades the consequence of masking, rather than treating it as a single switch:

Control	What happens to the data
M1	Collected, with unmasking available only to a limited set of authorised users behind an internal approval process
M2	Collected by the tool but never made available to the publisher — for example, encrypted under the provider's key; access requests must be reasoned
M3	Not collected at all

Our recommendation: use M3 for credentials and payment fields, not M1. An unmasking workflow is a permanent governance obligation — a role list to review, an approval trail to keep, a leaver to remember. Data you never collected needs none of that. The trade-off is real and worth naming: you lose the ability to watch back exactly what a specific customer typed into a card field when their payment failed. In our view that diagnostic is not worth a standing pathway to a customer's payment data.

The draft treats that category separately as a security measure in any case. Control S1 asks that the publisher be able to block collection of "tout mot de passe, information bancaire, ou autre donnée soumise à des conditions particulières de collecte et de stockage" — any password, banking information, or other data subject to special collection and storage conditions.

Identifiers, and why they decide how bad a breach is

The draft also grades identifiers: I1, a randomly generated session identifier designed to prevent linking a user's separate sessions or linking them to an account, optionally short-lived so long sessions fragment; I2, a per-user pseudonymous identifier built with hash functions that does not directly identify; I3, an identifier scoped to a single domain to limit cross-domain matching.

Say you run a 40-SKU skincare brand selling into Germany and France, with a returns form that asks customers why they sent something back. Under I1, a recording is one anonymous session with a friction point. Under a persistent account-linked identifier, the same recording is an identified customer's medical explanation for a return — and Article 9(1) GDPR prohibits processing data concerning health absent an Article 9(2) condition. The script did not change. The identifier did.

How Long You May Keep Session Recordings

Weeks, not years — and the CNIL's draft ties the period to the purpose rather than setting one number. For customer support it recommends retention limited to a few hours after the session ends; for UX improvement, a few months, so the data stays limited to problems on the current version of the site.

The draft's wording is "durée de conservation limitée à quelques heures après la fin de la session" for support, and "durée de conservation de quelques mois" for UX work, with the period documented and justified against how often those situations actually arise.

The draft also asks providers to build for deletion of individual sessions — both for retention that depends on user actions and, in any event, to honour erasure requests. If your vendor can only purge in bulk, a single Article 17 request becomes a problem you cannot solve without deleting everyone's data.

Two collection-limitation controls do more for you than any retention setting: L2, record but delete promptly where no predefined trigger event occurred, and L3, analyse recordings and promptly delete those the purpose did not need — the draft's example is deleting a session once it is established the user hit no navigation difficulty. Our position: run replay on a trigger, not on every visitor. The volume you never record is volume you never have to secure, justify, mask, or delete. The cost is that you cannot study a session you did not capture — a genuine loss for exploratory research, a small one for the failed-checkout debugging most stores actually use these tools for.

For comparison, Microsoft's own documentation puts Clarity's retention at 30 days from the time of recording, with favourited recordings and a randomly selected sample kept for up to 9 months.

Does Session Replay Trigger a DPIA?

Often, yes — but note first that the CNIL's draft does not say so. An exhaustive text search of the draft returns no mention of a DPIA or Article 35. The analysis below is ours, built on the Article 29 Working Party's criteria and the ICO's guidance.

WP248 rev.01 lists nine criteria for processing likely to result in high risk, and states that in most cases processing meeting two of them requires a DPIA. Session replay on a checkout flow reaches two comfortably. Criterion 3, systematic monitoring, is met on the Working Party's own definition of "systematic" — "occurring according to a system; pre-arranged, organised or methodical". Criterion 1, evaluation or scoring, expressly contemplates "a company building behavioural or marketing profiles based on usage or navigation on its website".

The ICO reaches the same door from a different direction, noting that where cookie data is not anonymous "you may need to carry out a data protection impact assessment (DPIA)". Worth knowing: the ICO's cookie guidance never mentions session recording, replay or heatmaps by name, and the ICO says on that page that it is currently consulting on a revised version of its guidance on storage and access technologies. Until that lands, the conservative read is that the general rules apply unchanged, because nothing in them carves out this tool category. Our guide to when a DPIA is required walks the criteria in full.

This is where most stores that get the law right still get the implementation wrong. A banner that records a refusal but never passes it to the recorder is worse than no banner, because it manufactures evidence that you asked.

Microsoft has removed some of that risk for one tool. Clarity's Consent Mode "is enabled by default for all users originating from the European Economic Area (EEA), United Kingdom (UK), and Switzerland (CH)", and since 31 October 2025 Clarity has enforced consent-signal requirements for visits from those regions. Once enabled, Microsoft's documentation says, "Clarity waits for a valid consent signal before setting any cookies."

Merchants have been working the wiring out in public for a while. On the Shopify Community in September 2025, one asked whether Shopify's built-in cookie banner was enough — "Do I need to adjust this code so Clarity receives the correct consent signals?" — and the replies disagreed with each other. The verification step settles it, and it is the same regardless of platform:

Load your store in a fresh private window from an EU IP address.
Refuse everything on the banner.
Open the network tab and confirm no requests go to your replay vendor's collection endpoint.
Repeat with consent granted, and confirm the requests appear — a gate that never opens is also broken.
Record the date, the tool version and the result. That record is part of your accountability evidence that consent actually governs the recorder.

On Shopify, the gate runs through the Customer Privacy API, which we cover in the web pixels guide. On WooCommerce the picture is messier: the consent signal comes from whichever plugin you installed, and a WordPress.org thread from early 2025 ended with the plugin author confirming that site owners must call the consent API themselves. Assume nothing is wired until you have watched the network tab.

Default masking deserves the same scepticism. Clarity offers three modes — Strict (entire content masked), Balanced (the default, masking only what Microsoft classifies as sensitive: "numbers and email addresses") and Relaxed (nothing masked, though input boxes and drop-downs stay masked in all three and cannot be customised). Balanced is the wrong default for a store. It does not cover free-text, and free-text is where customers write the things you least want recorded. Hotjar, for its part, states that it "suppresses user field input by default".

What Your Record of Processing Must Say

Article 30(1) GDPR requires the record to carry the purposes, the categories of data subjects and personal data, the categories of recipients, any third-country transfers, envisaged erasure time limits, and a general description of the Article 32(1) security measures. Session replay touches every one of those columns, and it is routinely missing from the register entirely — it arrives through a marketing or growth team rather than through procurement, so it never reaches whoever maintains the record.

A defensible entry names the purpose narrowly (UX friction diagnosis, or support, not "analytics"), lists the masking configuration and identifier scheme as the security measures, and states the retention period the purpose actually justifies. The CNIL's draft would also bar quietly repurposing what you collected: data gathered under consent "ne peuvent être réutilisées pour une autre finalité qu'à la condition que l'utilisateur ait donné son consentement à cette nouvelle finalité", unless it has first been anonymised. Our record of processing walkthrough covers how to build the register itself.

Common Mistakes

Filing replay under "performance" or "analytics" in the banner. This is the worst of them, because it produces a consent record that says the visitor agreed to something they were never shown. Give replay its own purpose, described in plain words.

Assuming vendor defaults are compliance settings. They are product settings, tuned for usefulness. Balanced masking, indefinite identifier scope and record-everything capture are defensible product choices and poor compliance ones. Relying on the tool's "GDPR compliant" badge is the same error one step removed: a tool can be configurable in a compliant way and configured by you in a non-compliant way, and the obligation sits with the publisher.

Never testing refusal. Testing that the tool records after acceptance proves the tool works. Testing that it stops after refusal proves the gate works, and only one of those is the compliance question.

Leaving replay out of the register. If your record of processing lives in a spreadsheet that has never met your growth team's tooling budget, it is not a record of processing.

How PrivacyForge Helps

Session replay is a consent problem, a data-mapping problem and a retention problem at the same time, which is why it slips through teams that handle each of those separately.

PrivacyForge's consent management gives replay its own purpose rather than burying it in a performance bucket, and keeps the timestamped proof that a given visitor accepted or refused it. The data-mapping module carries an Article 30 entry with the masking configuration and identifier scheme recorded as security measures, and retention policies let you set the period per purpose, in line with the split the CNIL's draft proposes, rather than accepting a vendor default. Compliance scoring surfaces the gap most stores discover late: a tracker running in production that no record of processing mentions.

If you are starting from scratch, our complete guide to GDPR compliance and our cookie consent best practices cover the foundations this article builds on.

Frequently Asked Questions

Yes, in the EU and UK. Session replay scripts read and write information on the visitor's device, engaging Article 5(3) of the ePrivacy Directive. The CNIL's draft recommendation reasons that these operations are not solely for carrying a communication and are not strictly necessary to provide the publisher's service, since the publisher could provide that service without them. Consent must therefore be obtained before the recorder starts.

No, on our reading. The CNIL grants that exemption only where the tracker's purpose is strictly limited to audience measurement alone, it operates for the exclusive account of the publisher, and it produces anonymous statistics only. A replayable recording of one person's session is not an anonymous statistic, so the first condition fails and the remaining ones never arise.

Clarity ships consent handling for EEA, UK and Swiss visitors, but its masking default is not tuned for a store. Microsoft's documentation states Consent Mode is enabled by default for those regions and Clarity "waits for a valid consent signal before setting any cookies". However, the default Balanced masking mode masks only "numbers and email addresses", leaving free-text fields such as order notes visible.

Tie the period to the purpose. The CNIL's draft recommendation proposes retention limited to a few hours after the session ends for customer support, and a few months for UX improvement, so the data stays relevant to the current version of the site. Microsoft retains Clarity recordings for 30 days, with favourited and randomly sampled recordings kept up to 9 months.

Does session replay require a DPIA?

Often. The CNIL's draft does not address DPIAs at all, but WP248 rev.01 states that processing meeting two of its nine high-risk criteria generally requires one. Session replay on a checkout flow typically meets criterion 3, systematic monitoring, and criterion 1, evaluation or scoring — which expressly covers building behavioural profiles from navigation on a website.

Conclusion

The vendor consensus that session replay "needs consent" is correct and not very useful, because it stops exactly where the decisions start: which fields you never collect, which identifier you attach, which trigger starts the recorder, and how quickly the recording goes away. The CNIL's draft lays those out as a graded set of controls rather than a warning, which is what makes it worth reading before it is final.

Do the three highest-risk things first: give replay its own consent purpose, block collection of credentials and payment data outright rather than masking them behind an unmasking workflow, and test refusal in a private window before you trust the gate. Then put the tool in your record of processing, where it should have been from the day it was installed.

Start a free PrivacyForge trial to map your tracking tools, gate them on real consent, and keep the evidence.

Sources

#consent management #cookie consent #ePrivacy #analytics #data mapping

Session Replay GDPR Consent: The Rules for EU Stores

Key Takeaways

Introduction

Do Session Replay Tools Need Consent Under GDPR?

Why the script is in scope before it sets a cookie