Session Replay: Smile, You're on Candid Camera

It is 11:40 pm, and Margot is filling in an online pharmacy form. The field says "Tell us about any conditions you are currently treated for". She types a line, looks at it, and deletes half. She types it again with softer words. Her cursor hovers over a drop-down, slides away, then comes back and picks an option. At the bottom there is a button marked "Continue". She never clicks it. She shuts the laptop and goes to bed, satisfied that nobody will ever know.

Three weeks later, on a Tuesday afternoon, a product manager at the pharmacy opens a dashboard called "Checkout friction". He clicks the play icon on one of four thousand recordings, and there is Margot's session. The cursor moves as if by a ghost. The words appear letter by letter, disappear, and reappear softer. The drop-down opens. The cursor hesitates, and the product manager leans forward like someone watching the final over of a cricket test. He has a biscuit in his other hand. He is not a bad person. He only wanted to know why people abandon the form on page three. Now he knows a great deal more than that, and so, in a data centre somewhere, does a company Margot has never heard of.

Put the biscuit down for a moment. This is not a story about a villain. The product manager, the pharmacy and even the vendor all believed they were doing ordinary product work. That is exactly the problem. Session replay is one of the most useful tools in a web team's kit, and it is also a tool that, by default, records things nobody meant to record.

This is not a hypothetical fear. In 2017, researchers at Princeton found seven replay providers on 482 of the top 50,000 websites, collecting keystrokes and page content "as if someone is looking over your shoulder". Text typed into forms was collected before the user submitted it. On one pharmacy site, the researchers found medical conditions and prescriptions sent to a replay vendor alongside the users' names. On a clothing store's account page, a full credit card number, expiry date and CVV went to a vendor letter by letter, as they were typed.

As of March 2026, the regulators have caught up. On 25 February, France's data protection authority, the CNIL, published a draft recommendation on session replay tools. In short: ask for consent, mask by default, record fewer sessions, delete them soon, and do not use them for retargeting. On 4 March, France's highest administrative court, the Conseil d'État, confirmed the CNIL's €40 million fine against Criteo. It rejected the ad-tech company's argument that its pseudonymous identifiers were not personal data. The two stories sit together more closely than they first appear.

So here is the plan. First, we open up a replay and look at what it really is. (Spoiler: it is not a video, and that changes everything about masking.) Then we read what the CNIL wants, setting by setting. Then Criteo explains why "we only use a random ID" will not get you off the hook. Finally, we follow one business owner as he configures a replay tool from scratch and writes down a reason for every setting.

Roll tape.

Part 1: It Is Not a Video

You already know what a screen recording is. You have shared your screen on a video call, and somebody on the other end watched a stream of pictures: your slides, your cursor, and, once, the notification from your group chat that you really wish you had muted. A screen recording is a camera pointed at the glass. It sees pixels, and only pixels.

Most people assume session replay works like that. The vendor's marketing encourages it, with play buttons, timelines and speed controls that look exactly like a video player. But a replay tool does not film the screen. It does something cleverer, and much more revealing.

The script, not the film

Think of a stage play. If you want to capture a performance, you can film it from the back row. Or you can write down the set, every prop and where it stands, and then note every change as it happens: the actor crosses to the window, the lamp goes off, the letter is opened. Give those notes to a troupe of understudies in another theatre, and they can perform the whole evening again, move for move.

Session replay takes the second approach. We have committed to the theatre now, so let's follow it all the way down.

The open-source library rrweb (the name stands for "record and replay the web") publishes its design notes, so we can look inside one. Most commercial tools do not publish their internals, so rrweb's notes are the clearest place to see the mechanism.

The set: a full snapshot. When recording starts, rrweb walks the page's Document Object Model (DOM), which is the browser's living tree of every element on the page, and serialises it. That means it turns the tree into structured text (JSON) that can be sent over a network, giving each node a unique ID. The notes are frank about the changes this needs. Scripts are swapped for harmless noscript placeholders, so the page's own code never runs in the replay. Relative links become absolute. External stylesheets are copied inline, so the replay looks right even if the original CSS is on a private server. And the value of each form field, which is not visible in the HTML source, is read and written into the snapshot as an attribute.

Read that last sentence again. The recorder does not wait for a form to be submitted. It reads the value of the field.

The stage directions: incremental snapshots. After the set is recorded, the recorder notes every change. rrweb uses a browser feature called MutationObserver, which tells a script whenever the page's tree changes: a node added, a node removed, an attribute or some text changed. It also listens for mouse movement, clicks, scrolling, window resizing and input. Mouse positions are noted at most once every 20 milliseconds and sent in batches at most every 500 milliseconds, which is why the ghost cursor in a replay moves so smoothly.¹ For form fields, rrweb listens to typing and also hooks the property setters, so it catches a value that a script fills in, not only a value a human types.

The performance: replay. On the vendor's dashboard, the player rebuilds the page from the snapshot inside an <iframe>, then applies each change at the right moment. What the product manager sees is not a film of Margot's screen. It is a working copy of the page, re-performed in his browser, from Margot's notes.

Where masking has to happen

This is the point where the mechanism matters for privacy. A screen recorder can only blur pixels after it has captured them. A replay recorder is reading the actual text of the page, so it can do something better: remove the sensitive parts before they are ever written into the notes.

That is what good masking is. The recorder swaps text for asterisks or blocks, or leaves an element out entirely, in the visitor's browser, before anything crosses the network. The vendors say this plainly. PostHog says its privacy controls run in the browser, so masked data "is never sent over the network". Microsoft Clarity says masked content is "never uploaded". Sentry masks and blocks "on the client, before it is sent to the server", and Sentry adds server-side scrubbing of patterns such as card numbers in captured network data.

The inverse is the uncomfortable part. Anything that is not masked in the browser has already left. You cannot un-send it by changing a setting next week. Clarity notes that masking changes apply to new recordings only and "can't be applied retroactively".

max_tokensPOST./v1/messages

What the recording contains that you forgot about

Most teams think about form fields when they think about masking. The Princeton study showed why that is not enough. The tools masked some inputs by type or by rules of thumb. FullStory, for example, redacted card fields only when they carried the attribute autocomplete="cc-number", so a card field without it went straight through. Some tools masked a password in a way that still told the vendor how long the password was.² And none of the seven tools appeared to mask displayed page content by default. The researchers called manual redaction of displayed content "a fundamentally insecure model", because every redesign can break a rule that someone wrote months ago.

Displayed content is the big one. Your "Hello, Margot" greeting, the delivery address on the order confirmation, the order history, the search box that shows what she searched for, the appointment page that shows which clinic she booked. None of these is a form field. All of them are text in the DOM, and a text node is exactly what the recorder copies.

So before we reach any law, we have the first principle of configuration. Masking is a decision about what text leaves the visitor's browser. If a tool's default is to send the whole page and ask you to list what to hide, you are running the model the Princeton researchers called insecure. If its default is to hide everything and ask you to list what is safe, you are starting from the right end.

Part 2: What the CNIL Wants From Your Replay Tool

stop_reasoneval:.pass

The CNIL's draft recommendation is twelve pages long, and it is unusually practical. It is written for two audiences: the vendors who build the tools, and the publishers who put them on their sites. It is not binding. The CNIL says so in paragraph 5, and the public consultation closes on 22 April 2026. But the lawyers at Clifford Chance expect it to become the CNIL's "enforcement benchmark", and that is how I would read it too. When a regulator writes down what good looks like, that becomes what it checks for.

It also reaches further than France. The draft applies to publishers and vendors in the EU, and to anyone who processes the personal data of people in the EU in the way Article 3 of the GDPR describes. If your shop in Hobart ships to Lyon, keep reading.

Two laws, two questions

The draft starts with a distinction that confuses a lot of teams. Two separate rules apply, and each asks a different question.

The first is the cookie rule: Article 82 of the French Data Protection Act, which implements Article 5(3) of the ePrivacy Directive. It asks: may you read or write anything on the visitor's device at all? Replay tools rely on trackers (cookies on the web, other identifiers in mobile apps), so this rule applies.

The second is the GDPR. It asks: may you process the personal data you collected that way? The CNIL is blunt about whether replay data is personal data. The tools "reconstruct individual browsing sessions", and they collect data that directly or indirectly identifies users "regardless of their configuration and settings". Masking reduces the risk. It does not turn a replay into anonymous statistics.

I covered the basics of consent in Consent Management: The What and Why. For replay, the short version is that you need a yes to the first question before you can even ask the second.

Why replay does not get the analytics exemption

In France, some audience-measurement tools can run without consent. The CNIL's developer guide lists the conditions: the purpose must be limited to audience measurement and A/B testing, the data must not be cross-checked with other processing, the tracker must be limited to one publisher, the IP address must be truncated, and trackers can last at most 13 months. The CNIL adds, a little drily, that most large analytics offerings do not qualify "regardless of their configuration".

Replay is a different kind of thing. The draft itself presents replay as an alternative to "more traditional measures (e.g. audience measurement or 'analytics' tools)". Paragraph 19 then settles the question: the read and write operations are "not strictly necessary for the provision of the services offered by publishers, as these services could be provided without them". So replay needs prior consent. Error fixing, UX work and customer support are all legitimate reasons to use it. None of them removes the need to ask.

Purposes come first, and they come before the tool

The draft recognises three purposes:

1. Detecting and understanding errors or technical problems.
2. Improving the user experience (UX): finding friction points such as rage clicks and misclicks.
3. Support and assistance with customer requests: replaying the session of a specific user who contacted you with a problem.

Paragraph 14 contains my favourite sentence in the document. The purposes must be defined before the tool is deployed. "They cannot be determined after the data has been collected, nor can they depend on what the data controller is able to view using the tool."

That sentence describes, precisely, the product manager with the biscuit. He opened the tool to see why people leave page three, and he ended up watching someone describe their medical conditions. Under the draft, "we'll see what we find" is not a purpose. You decide what the tool is for, then you configure it so that it can only see what that purpose needs.

The measures, purpose by purpose

The most useful part of the draft is its appendix. It gives each measure a short code and then lists, for each purpose, which measures to combine. The codes are worth learning, because you can put them straight into your configuration notes:

• Limiting sessions. L1: record a random sample. L2: record only when a defined trigger happens (or buffer everything and delete the recording soon if the trigger never fires). L3: analyse recordings and promptly delete the ones you do not need.
• Masking. M0: if nobody has configured anything, mask everything by default, including images, forms, text fields and fields filled with account information. Then the publisher chooses what masking means: M1, collected but unmasked only for a few authorised people after an internal approval; M2, collected but not made available to the publisher (for example, encrypted on the vendor's side), and any request for access must be justified; M3, not collected at all.
• Identifiers. I1: random session IDs that cannot link one visit to another or to an account, which may be short-lived. I2: a pseudonymous ID per user, such as a hash. I3: an ID limited to one domain.
• Security. S1: block passwords, banking details and other sensitive data from collection. S2: role-based access, reviewed over time.

Paragraph 40 says these measures are not mandatory, and you can use other measures if you can document how they meet the same obligations. But the burden is now on you to show your working.

page_viewtool_use

Look at the retention row, because it is the one teams will find hardest. For customer support, the draft recommends keeping a recording for "a few hours after the end of the session". For UX and error work, "a few months", to focus on the current version of the site. It also asks vendors to build their systems so that individual sessions can be deleted, for example when a support ticket closes. A tool that can only expire recordings in bulk after 90 days does not fit the support purpose at all.

Look also at the identifier row. For UX and for error detection, the appendix says there is no reason to link a session to a user ID. Only the support purpose, where you need to find one specific customer's session, justifies an identifier. So if your replay tool is quietly joined to your customer accounts "just in case", the draft says that should not be there.

Consent: what the banner has to say

The draft says consent can go through your consent management platform (CMP), and each purpose must be presented to the visitor on its own. It even suggests wording. For the support purpose, the example label says the publisher "uses trackers (user journey recording tools) to reproduce the session(s) of certain users who have encountered a problem while browsing". That is plain and honest, and I would use something close to it.

Three details are easy to miss:

• First layer, as good practice. Paragraph 24 encourages you to mention session replay on the first screen of the banner, not only in the detailed settings. It is good practice, not a rule. You decide based on how much tracking you do and how well you have minimised it. If you record a lot, put it on the first layer.
• One tick can cover two laws. Paragraph 29 says that if your legal basis for processing is also consent, you can collect both at once with "a single checkbox for each of the purposes".
• Withdrawal must really stop the recorder. Paragraph 35 says that after a user withdraws consent, reading and writing must stop. It suggests expiring the cookie with a Set-Cookie header dated in the past, or deleting non-httpOnly cookies with a script. It is not enough to stop showing the recordings. The recorder must stop recording.

If your consent set-up already uses Google's consent mode, the patterns from No Consent, No Conversions apply. The difference is that the CNIL draft offers replay no equivalent of a cookieless ping. No consent means no recording.

Who is responsible for what

The draft also sorts out the roles, and this is where vendor contracts get interesting. If the vendor provides the tool and does not reuse the data, it is your processor. If the vendor, with your agreement, uses the recordings for its own purposes, "e.g. to improve the solution provided", it becomes a separate controller for that use. It also becomes a joint controller with you for the reading and writing on your visitors' devices.

The consequence is in a box on proof of consent. When you are joint controllers, a clause that simply makes the publisher responsible for collecting valid consent on the vendor's behalf is not enough. The contract must say how consent is proven, who keeps the proof and how it is audited. Clifford Chance calls this "a point with real bite for vendor agreements and CMP set-ups". Go and read the "product improvement" clause in your replay vendor's terms. You may find you have a joint controller you did not know about.

utm_source=SELECT

And not for retargeting

Then there is the sentence that Clifford Chance singles out. In a box on minimisation, the draft says a session replay tool "should not be used for retargeting advertising purposes, given the existence of more privacy-friendly solutions (e.g. 'shopping basket' reminder cookies)".³

Clifford Chance summarises this as "never". The CNIL's own wording is "should not", and it sits in a list of minimisation advice, not in a list of absolute bans. In practice, I would treat it as "never". If you cannot explain to a regulator why you needed a full recording of someone's session to show them an advert for the shoes they left in the cart, you will not enjoy that meeting.

Why does the CNIL single out retargeting? Because retargeting is the point where replay data leaves the product team and joins the advertising machine: an identifier, a history of behaviour and a commercial motive. That is exactly the combination the Conseil d'État looked at on 4 March.

Part 3: Criteo and the Name Tag Problem

aria-labelgtm.js

Imagine a conference where nobody wears a name. Everybody gets a numbered badge instead: you are guest 4417. It feels anonymous. Now imagine that somebody follows guest 4417 all day and writes down everything. 4417 arrived from the airport shuttle at 8:12, took two muffins, sat in the talk on Tasmanian apple exports, asked a question about cider tax, bought the speaker's book with a card and went home in the taxi booked for room 312. By lunchtime, the number is no longer protecting anybody. Guest 4417 is the one person in the building who matches all of that.

That is the whole of the Criteo argument, and it is the idea that turns a session replay into personal data.

What the court decided

Criteo is a French ad-tech company that places cookies on partner websites to show targeted adverts. noyb, the privacy group, describes its business as "behavioral retargeting". noyb and Privacy International complained about Criteo in December 2018. On 15 June 2023, the CNIL fined Criteo €40 million for breaches of Articles 7, 12, 13, 15, 17 and 26 of the GDPR: consent, transparency, access, erasure and the joint controller agreement. Criteo appealed. On 4 March 2026, the Conseil d'État rejected the appeal and confirmed the fine.⁴

Criteo's main argument was that it did not process personal data at all. Each person got a pseudonymous identifier linked to the IP address of their device. Criteo said it had no key to turn that identifier back into a person.

The court was not persuaded, and its reasoning is worth following step by step, because every step applies to a replay tool.

First, the test. Under the GDPR, pseudonymised data is still personal data. The court said that data can only count as anonymous if the risk of identification is, in noyb's English summary, "insignificant, such identification being impracticable in practice", for example because it would need a disproportionate effort in time, cost and labour.

Second, what was attached to the ID. The number came with company. The court listed the IP address, the location linked to it, the device identifier, the partners' own identifiers for the same people, and a great deal of browsing activity: sites visited, purchases made, adverts seen and adverts that led to a purchase. Because the whole point of the processing was to fit adverts to each person's habits, a very large amount of sometimes very precise information could be gathered and cross-referenced for a given identifier.

Third, the admission. Criteo had told the CNIL that identifying some people would not be technically impossible. So, for Criteo, at least some of the many people concerned were identifiable without a disproportionate effort. Criteo could not escape by saying it had no interest in identifying anyone.

The scale made it worse. The court noted more than 370 million user identifiers in the EU, 50 million of them in France, and a business model built on placing cookies. The fine was half the maximum available, and the court found no error in setting it at that level.

A replay is guest 4417 with a camera

Now put a session replay next to that list.

A replay tool also gives each visitor an identifier. Microsoft is refreshingly direct about it: "Clarity's cookies store a unique pseudonymous ID". Its _clck cookie keeps the Clarity user ID for a site, and _clsk joins page views into one recording. Attached to that ID is not a summary but the page itself: every page viewed, every click, every scroll, the text on the screen and, unless masked, what the visitor typed. If the greeting says "Hello, Margot", the replay says it too.

In the conference, the number stopped protecting anybody once enough behaviour was attached to it. A replay attaches more behaviour to one ID than almost any other tool on your site. So the Criteo test is not a close call for replay. The honest starting position is that recordings are personal data, and the CNIL draft says as much in paragraph 7. Masking, sampling and short retention are the ways you reduce the risk. They are not a way to argue that the risk does not exist.

Two more parts of the decision are worth knowing about.

Hashing is not a disguise. The CNIL's measure I2 suggests a pseudonymous user ID created "using hash functions, for example". That is a good measure for support, where you need to find one person's session. Understand what it is, though. A hash of an email address is a consistent number for the same person. It is pseudonymisation, and Criteo shows exactly how far pseudonymisation goes: as far as the pile of data attached to it. The same logic is why browser fingerprinting counts as tracking even though no name is involved.

Erasure means erasure. The court also upheld the finding that, when people asked Criteo to erase their data, it stopped showing them personalised adverts but kept their identifiers and kept using the linked data to improve its algorithms. Swap "improve its algorithms" for "improve the solution provided" and you have the vendor reuse clause the CNIL draft warns about. If a visitor asks you to delete their data, their recordings must go, from your workspace and from any copy the vendor keeps for itself. Paragraph 47 of the draft asks vendors to support deletion of individual sessions for exactly this reason.

One piece of context, as of March 2026. noyb links the ruling to the European Commission's "Digital Omnibus" proposal, which it says would narrow the definition of personal data by making it depend on the circumstances of each controller.⁵ That is a proposal, not the law. Today, the Conseil d'État's test applies, and your replay tool fails it for the same reason Criteo did: there is too much behaviour attached to the number.

Part 4: Oskar Configures a Replay Tool

Let's make this concrete. Oskar runs a small online shop from Hobart that sells Huon pine chopping boards. About a third of his orders come from France, where, it turns out, people have strong opinions about bread boards. Checkout conversions have dropped since he changed payment providers, and a friend has told him to "just put Hotjar on it". Oskar has read the CNIL draft (well, this article about it), and he wants a set-up he can defend.

Here is what he does, in order. Each step gives the setting and the reason. The reason is the part a regulator will ask about.

Step 1: Write the purposes down first

Before he installs anything, Oskar writes two purposes in his records of processing:

1. Error detection: "Find and fix errors in the checkout after the payment provider change."
2. Customer support: "Replay the session of a customer who contacts us about a failed order, with their agreement."

He considers UX improvement and decides against it for now. He does not have the traffic to learn much from random sessions, and every purpose he adds brings its own settings and its own consent choice. That decision is the first minimisation measure, and it cost him nothing.

Justification: draft paragraphs 13 and 14. Purposes are fixed before deployment and cannot depend on what the tool lets him see.

Step 2: Gate the recorder on consent

Oskar adds two replay purposes to his CMP, each with its own switch and the CNIL's suggested wording. Because replay is a large part of his tracking, he also mentions it on the first layer of the banner.

Then he makes sure the recorder does not start until the right switch is on. How this works depends on the tool:

• In PostHog, he sets disable_session_recording: true in the initial configuration. He calls posthog.startSessionRecording() only after the CMP reports consent, and stopSessionRecording() if consent is withdrawn.
• In Microsoft Clarity, consent mode is on by default for visitors from the EEA, the UK and Switzerland, and Microsoft began enforcing consent signals for those visitors on 31 October 2025. Microsoft's own test checks the console for analytics_storage: "DENIED", and checks that no _clck or _clsk cookie appears after a decline. Note that the same test expects Clarity's /collect calls to keep running. Microsoft's check is about cookies. The CNIL draft is about recording. My recommendation is to load the Clarity script only after the replay consent is given, and not rely on the cookie switch alone.
• For any tool, he tests withdrawal. He accepts, browses, then withdraws, and checks in the browser's developer tools that recording requests stop and the tool's cookies are expired or deleted.

Justification: paragraph 19 (consent), paragraphs 23 and 24 (information), paragraph 35 (effective withdrawal).

Step 3: Mask everything, then unmask with care

Oskar starts from "mask everything" and unmasks only what his purposes need. Each tool starts from a different place, which is the part most teams miss:

• Sentry already starts there. It masks all text and blocks all media by default (maskAllText and blockAllMedia are both true). Sentry also tells its users to test masking before production, and to test again after changing UI frameworks.
• Microsoft Clarity defaults to Balanced mode, which masks only what it classifies as sensitive: numbers and email addresses. A customer's name and delivery address in plain text are neither. Oskar switches to Strict. Inputs and drop-downs are masked in every mode, which is good, and Clarity does not mask content inside stylesheets, so he checks that nothing personal lives in CSS.⁶
• PostHog masks inputs by default but, in its words, "General text is not masked by default". Oskar sets maskTextSelector: "*" to mask all text, and adds the ph-no-capture class to the order summary and address blocks so they are replaced by a blank block of the same size.
• rrweb, if a developer builds their own recorder, masks only password inputs by default: maskAllInputs is false and maskInputOptions is { password: true }. The .rr-block and .rr-mask classes do the rest.

Then he looks for the traps. A "show password" button often changes the field's type from password to text, which PostHog warns can reveal the password to a rule that checks the type. So he masks by ID as well as by type. Card fields sit inside the payment provider's own frame, which his recorder cannot see into, and he confirms that in a test recording rather than assuming it.

Finally, he decides what masking means for each purpose. For error detection, masked text is collected in masked form only, and no one can unmask it (close to M3). For support, he allows a controlled unmask: one person can request it, a second person approves it, and only after the customer agrees on the phone (M1).

Justification: paragraph 43 (M0 by default, then M1 to M3), paragraph 48 (S1, block passwords and banking data), and Appendix 1 for the choices per purpose.

Step 4: Record fewer sessions

Oskar does not record everyone. For error detection, he uses a trigger:

• In Sentry, he sets replaysSessionSampleRate to 0 and replaysOnErrorSampleRate to 1.0. Sentry then buffers the session and keeps a recording only when an error happens, with up to a minute of events before it.
• In PostHog, he sets an event trigger on exceptions, plus a URL trigger on the checkout. The client keeps a short buffer in memory and sends it only when a trigger matches.

This is the CNIL's L2, and it fits error detection almost perfectly: buffer briefly, keep only if something goes wrong.

For the support purpose, he uses a trigger too: a "Having trouble? Let us see what happened" link on the order-failed page that starts recording for that customer only.

If he ever adds the UX purpose, he will use random sampling (L1). PostHog's sampling is worth understanding because it is so simple. When a session starts, PostHog runs the session ID through a hash function to get a number between 0 and 1, and records the session if the number is below the sample rate. The same ID always gives the same number, so a session is either recorded from start to finish or not at all. (PostHog's own advice is to start at 100% and reduce it. For a privacy-first set-up, I would start low and increase it only if the sample is too small to learn anything.)

Justification: paragraph 42 (L1 to L3), Appendix 1.

Step 5: Keep identifiers apart

For error detection, Oskar does not link recordings to customer accounts. He does not call the tool's "identify" function, and the session ID is random (I1). For support, he needs to find one customer's session, so the support trigger attaches the order number, which is his own pseudonymous reference and limited to his domain (I2 and I3).

He also checks that the replay tool is not shared with the ad stack. No replay-based segment goes into an advertising audience, and no replay ID is passed to an ad pixel. That is the retargeting box, and the Criteo pile of data, in one rule.

Justification: paragraph 44 and Appendix 1 (no user ID for errors or UX), and the retargeting box after paragraph 17.

Step 6: Delete soon, and delete one at a time

For error detection, Oskar sets retention to the shortest value his plan allows. PostHog, for example, lets you configure replay retention, with limits from 30 days on the free plan to five years on enterprise plans. Short is the goal, and "a few months" is the CNIL's outer edge for this purpose, not a target. He also notes that PostHog says deletion after expiry is not immediate.

Support is harder. The CNIL wants "a few hours after the end of the session". Most plan-level retention settings do not go that low, so Oskar adds a manual step: when a support ticket closes, the agent deletes that one recording. He checks that the tool can delete a single session, and asks the vendor in writing how long deleted recordings stay in its backups.

Justification: paragraphs 45 to 47, and Appendix 1.

Step 7: Decide who can watch

In Clarity, only project administrators can change masking. Oskar applies the same idea everywhere: two people can see recordings, one person can change settings, and he reviews the list when someone leaves. He writes the unmask approval process for support into a one-page procedure.

Justification: paragraph 48 (S2).

Step 8: Test it like a visitor

Last, Oskar does what most teams skip. He places an order with fake details (a made-up name, a test card, a note that says "I have a rare condition") and then watches his own recording as his colleagues would see it. If he can read anything he did not intend to collect, the configuration is wrong, whatever the settings page says.

This is the same discipline I argued for in Are You Really Tracking That?: check that the instrument measures what you think it measures. With replay, check that it does not capture what you think it does not capture.

Oskar's settings register

At the end, Oskar has a short table he can give to a regulator, a customer or his future self:

It took an afternoon. It will take a lot less time than answering a complaint.

Final Thoughts

Go back to Margot at 11:40 pm, typing and deleting her line about her health, and to the product manager with his biscuit three weeks later. Under the set-up Oskar built, that scene does not happen. The recorder would not have started without her yes. If she had said yes, the text she typed would have left her browser as a row of asterisks. The session would have been kept only if the form threw an error, and deleted within months, or within hours if it was a support case. And nobody would have used it to sell her anything.

The one idea to take away is this. A session replay is not a video of the screen. It is a copy of the page, attached to an ID. Everything the CNIL asks for follows from that. The copy must be masked before it leaves the browser. The ID makes it personal data, as the Conseil d'État held for Criteo. So each setting needs a purpose, and each purpose needs a reason you can write down.

Your next step is small. Open your replay tool's settings page, and for each setting, write the purpose it serves beside it. If a setting has no purpose, change it. If the tool has no purpose, remove it. And if you have views on the draft, the CNIL consultation is open until 22 April 2026.

Now, if you'll excuse me, I am going to make a cup of tea. I will watch the kettle myself.

Notes

1. Because mouse positions are sent in batches, each one arrives a little late. rrweb records a small negative time difference with each batch so that the replay puts the cursor back where it was at the right moment, which is a lot of care to take over a cursor. ↩

2. The Princeton researchers found that the masking used by UserReplay and Smartlook leaked the length of the user's password. UserReplay, for example, replaced typed input with masking text of the same length. That hides the password but tells anyone watching how many characters it has. ↩

3. The draft does not say which consent rules apply to a "shopping basket" reminder cookie. It is still a tracker, so check it against Article 82 on its own terms. It is less intrusive than a full recording, which is the point the CNIL is making. ↩

4. The decision is published in French. Quoted phrases from it here are noyb's English wording. The rest is my paraphrase of paragraphs 10 to 22 of the decision, so check the original before you rely on a detail. ↩

5. As of March 2026, the Digital Omnibus is a proposal from the European Commission. noyb argues it would narrow what counts as personal data. It has not changed the GDPR, and the Conseil d'État applied the current definition. ↩

6. Clarity uses different symbols for masked content: one for letters, another for digits, and a third for Strict mode or explicit masking. If each symbol stands in for one character, a masked recording can still suggest how long each piece of text is. That is useful for layout bugs, and a reminder that masking is not the same as deleting. ↩