What should you check before enabling session replay?
Before switching on recording, decide which pages belong in it, what information must stay out, when capture may begin, and who gets access. Then check whether the installation actually behaves that way. A masked replay is encouraging, but you also need to know what left the browser to produce it.
These decisions don't end at installation. Your site will change, and so will the places private information appears. Keep technical verification alongside the assessment of your legal obligations, notices, and consent requirements. Passing a checklist doesn't establish compliance, and there's no single consent rule this article can supply for every site.
Begin with the question, then limit the capture
What are you trying to learn? If the question is why people miss a public booking link, you can start with that journey. You don't need to record an entire customer account to investigate it. Choose the smallest set of pages and interactions that can answer the question.
Create an explicit list of excluded areas. Depending on the product, that may include account settings, private messages, payment pages, health information, internal tools, and documents uploaded by customers. Check shared layouts and tags so an exclusion is enforced across every route that uses them.
W3C's privacy principles emphasize purpose, data minimization, and transparency. They are web-design principles, not a declaration that a particular implementation satisfies the law. W3C Privacy Principles.
Name the person responsible for this scope, and make it easy for anyone on the team to report something unexpected. Otherwise, a tag someone added for one investigation can become a permanent part of the site without anyone deciding it should be.
Follow the information beyond the input
You've masked the name field. Good. What happens after someone submits it? Their name might appear in a greeting, an email might be repeated in an error, or an identifier might enter the URL. The information can move even though the field stays protected.
Review the data surfaces your tool can collect:
| Surface | Synthetic example to test | Decision to verify |
|---|---|---|
| Form controls | A distinctive invented name | Value is excluded or masked as intended |
| Rendered page text | A private-account greeting | Private region never reaches capture |
| URL path and query | An invented account token | Sensitive parts are removed or route excluded |
| Click labels and attributes | A button containing an email | Interaction metadata does not leak it |
| Images and documents | A synthetic personal document | Private media stays outside recording |
| Custom events | A message copied into a property | Properties follow an explicit allowed schema |
Contentsquare's personal-data documentation identifies surfaces beyond inputs, including URLs, clicked text, and custom attributes. Audit the whole collection path rather than assuming form masking covers them. Contentsquare personal-data handling.
Use unmistakable, invented markers for these checks. You want something you can recognize in the results without creating a real exposure just to test for one.
Test masking where collection happens
Ask where the masking happens. Before anything leaves the browser? After the service receives it? Only when a teammate opens the replay? A setting called “private” doesn't settle that question. Find the implementation evidence and check the requests.
In a controlled test environment, place synthetic markers in each relevant surface. Trigger the initial page load, dynamic updates, validation errors, route changes, and the success state. Inspect decoded collection payloads using the vendor's supported tooling where necessary, then inspect the resulting recording.
Some collection formats are difficult to inspect. If that's the case, record the limitation and ask the vendor for technical evidence. A blurred field in playback can't tell you whether the original value was sent somewhere first.
Test masking changes as new collection behavior. Clarity's documentation, for example, says masking prevents upload of masked content and that changing masking settings does not retroactively change older recordings. Clarity masking documentation.
If an earlier recording contains something it shouldn't, deal with that recording separately. Correcting the selector may protect the next visit while leaving the old data exactly where it was.
Exercise every consent transition
Take the consent policy you've approved and describe what the site should do before a choice, after acceptance, after refusal, and after withdrawal. Include applicable browser privacy signals and any regional behavior you've implemented. Each state needs an expected result you can test.
Use the consent interface a visitor actually sees. Calling a developer function is helpful, but it won't reveal every problem with how the controls are connected. The preference shown on the page and the behavior of a separately installed tag can disagree.
Verify both immediate behavior and subsequent navigation. Does refusal persist on reload? Does withdrawal stop new capture? Can queued data still leave the browser? Does a client-side route change accidentally restart the tracker? What happens if the consent service is slow or unavailable?
Be precise about what withdrawal does. Stopping future collection and deleting existing data are separate operations, potentially with separate procedures. Your support team needs that distinction before it answers a visitor's question.
Use multiple test profiles. A clean browser, a returning browser with an old preference, and a browser changing its preference can follow different code paths.
Give recordings the same care as other customer data
Who can open these recordings? Include employees and contractors, but also shared links, API tokens, integrations, and coding agents. Access granted for a particular task should be limited to that task and removed when it ends.
Test access boundaries using separate test accounts. A viewer should not gain administrative controls merely by opening a different URL. A token for one project should not retrieve another project's recordings. An expired or revoked share link should stop working.
Choose retention around the review workflow and your requirements. Then look for copies: exported files, support attachments, and data passed to another system. The original recording can expire while a downloaded copy remains in someone's folder.
Practice deletion with synthetic data. Record the systems checked, what disappeared, and any documented backup or retention exceptions. If the team says it can delete a recording, someone should have followed that process successfully before a customer needs it.
Treat page changes as changes to collection
The privacy settings may be unchanged while the page behaves differently. A redesign moves private text outside its masked container. A reusable component adds customer details to a public route. A tag-manager edit starts capture earlier. Each can change what gets collected without anyone touching the recording settings.
Keep privacy verification close to those changes. Use stable selectors or explicit private-region attributes where the tool supports them. Avoid relying on generated class names that change with a build. Make the safe default clear when a new component has not yet been classified.
Repeat the synthetic-marker checks after meaningful routing, form, authentication, or layout changes. Include content inserted after load and transitions into excluded areas. Record the tested release so a past pass does not become an indefinite guarantee.
Make sure someone can stop capture without having to rediscover how it was installed. They need to know which switch stops new collection, how to check that it worked, and who will investigate data already stored.
Keep a release record someone can use
Keep enough evidence that another person could understand what passed and what remains uncertain. For each release, record:
- Allowed pages and excluded page groups, with an owner.
- Approved consent behavior and the states tested.
- Synthetic markers, collection surfaces, and observed results.
- Masking settings and the release used for verification.
- Viewer, administrator, token, and sharing-access checks.
- Retention, deletion, and export handling.
- Known inspection limits and the person accepting them.
- The disable procedure and the next review trigger.
Keep real visitor information out of this record, and restrict access to test evidence where appropriate. When the site changes again, the team should be able to repeat these checks, spot a difference, and know who can act on it.