What session replay should never record

Useful because it is detailed, risky for the same reason

Session replay reconstructs a visit: page changes, scrolling, clicks and, unless prevented, what a visitor typed. That detail is why a replay can show the confusing shipping step that a conversion chart only hints at. It is also why the French data protection authority, CNIL, opened a public consultation on a draft recommendation for replay tools in February 2026, covering data minimisation, information for visitors and consent.

Defaults are not enough

Widely used open-source recorders do not mask everything by default. rrweb, for example, masks password fields by default, while masking all inputs and masking page text are options the site has to turn on. A safe setup inverts that: mask every input, never capture payment or account fields, and block areas that show addresses, order details or messages.

If page text has to be visible to understand a layout problem, enable it deliberately for that site and keep inputs masked anyway. Losing a little context is cheaper than storing what a customer typed.

Record less, keep it shorter, use it for one purpose

Most questions do not need every visit. Sampling a share of sessions, or recording around a specific event, answers them with less data. Set a short retention period and delete recordings automatically when it ends.

Keep replay tied to the purpose visitors were told about, such as finding usability problems. Do not reuse recordings for advertising audiences or to identify individuals. A replay is evidence for a design decision, not a profile of a person.