Practical framework / 5 MIN READ
Prove what a replay tool can see before recording customers
Test suppression on dynamic pages with synthetic content and a clear stop rule.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
Session replay can reveal usability problems while also exposing page content that ordinary event analytics never collects. A safe acceptance review defines the permitted surfaces and proves suppression before real sessions are captured.
What you will leave with: Create a replay capture boundary, synthetic masking fixture and incident response route.
Use this when
- A team wants to install session replay on checkout or account pages.
- A page redesign introduces personalized content into recorded screens.
This lesson does not authorize recording users, collecting credentials or using replay as employee surveillance.
Define the diagnostic purpose and boundary
Name the usability question and the minimum interaction evidence needed. Consider whether a moderated test or aggregate event measure would answer it with less exposure. List pages, components and states proposed for capture, including account details, support messages and dynamically rendered content.
Get the necessary privacy, consent and security approvals before collection. Exclude sensitive surfaces unless an explicitly approved, safe design exists. Never collect passwords, payment credentials, authentication tokens or private health and financial details merely to understand a failed interaction. The diagnostic benefit does not remove those boundaries.
Understand suppression before relying on it
Contentsquare’s guidance for insights.hotjar.com describes suppression before transmission and warns that later setting changes do not retroactively suppress collected sessions. This makes pre-capture verification essential. Check the exact platform and current limitations rather than relying on another product’s masking assumptions.
Inventory visible text, images, attributes, URLs and content inserted after initial page load. An input field can be masked while the submitted value reappears in a confirmation message. A default rule that recognizes one pattern does not prove all sensitive content is protected.
Build a synthetic exposure test
Use harmless distinctive placeholders in every relevant location: form input, validation error, confirmation text, profile panel and dynamic content. Run an approved test capture and inspect both the replay and permitted transmission evidence. Expected suppression should hold before data leaves the browser where the design requires it.
Test route changes, expanded panels and alternate layouts. Keep the fixture non-sensitive; do not type real secrets to see whether masking works. If a placeholder leaks, treat that as a failed boundary and correct or exclude the affected surface before real capture begins.
Limit access and prepare for a leak
Agree who may view recordings, how long they remain and what uses are prohibited. Restrict sharing and exports, and avoid putting identifiable recordings into broadly accessible campaign decks. Capture should remain tied to its approved diagnostic purpose.
If unintended information is collected, stop the affected capture through the authorized incident process, preserve only necessary sanitized evidence and involve privacy/security owners. Do not assume deleting a local screenshot removes all provider copies. Re-test after site changes and review whether the tool is still needed once the question is answered.
Make the reasoning concrete.
A hypothetical account page masks a test address in the input field but repeats the harmless placeholder in an unmasked confirmation banner. The replay therefore exposes content the team believed was protected.
Trust input masking
Opening: Approve capture because the form field is hidden.
Hypothesis: One surface is protected.
Risk: The same information appears elsewhere on the page.
Test the whole state
Opening: Check the confirmation banner and dynamic components with synthetic placeholders.
Hypothesis: The leak is found before real customer capture.
Risk: Future component changes require renewed review.
Exclude or correctly suppress the affected surface and repeat the approved test. Do not collect real customer details as proof that the fix works.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Purpose
Which usability question needs replay?
Boundary
Which pages and content types may be captured?
Fixture
Where could a harmless placeholder reappear?
Controls
Who can view, export and retain recordings?
Incident
What stops capture and routes an unintended exposure?
Watch for the wrong conclusion.
- Assuming masked inputs mean the whole page is safe.
- Testing with real passwords or payment details.
- Believing new suppression repairs old recordings.
- Sharing recordings beyond the approved purpose.
Your next action
Create a synthetic replay fixture covering input, error and confirmation states before requesting real-session capture.
Sources & scope
Frameworks, worksheets and hypothetical examples are original editorial synthesis. Linked primary sources support only the stated concepts. Source checking is not an independent audit of effectiveness. No named human author or reviewer is claimed.
- Contentsquare: How to suppress collected data, insights.hotjar.com →Primary technical documentation · Supports: Documents pre-transmission content suppression and that changed suppression settings are not retroactive. Platform-specific masking limitations require checking; this is not a blanket assurance of safe capture.