The one-sentence definition
Session replay is the practice of capturing every interaction a user has with your web app — including the underlying DOM, network requests, console output, and behavioural signals — and reconstructing the session so a teammate can watch it play back as if they were the user.
Session replay vs screen recording — the structural difference
They sound similar but they are not the same thing. Screen recording (Loom, QuickTime, OBS) captures pixels — a video file. Session replay captures structure — the actual DOM nodes, event timeline, and network data — and reconstructs it on demand. A video can be watched. A session replay can be inspected: you can open browser dev tools inside it, hover any element, see network calls, replay console errors, and diff one session against another.
Why DOM-based replay matters for engineers
A screen video can show you that a button was misaligned, but it cannot tell you what CSS rule caused it, what state the component was in, or what the network response looked like at the moment of failure. DOM-based replay carries the full context — engineers debug from it the way they would from a live page, not by squinting at a video.
Why it matters for marketers and PMs
Heatmap-only tools aggregate clicks across sessions but cannot show you the individual journey. Session replay lets a PM watch the exact moment a real user abandoned checkout and see what they saw — the form-validation error, the slow API response, the third-party widget that crashed.
What gets captured (and what doesn't)
A modern session replay tool captures dozens of signal types. The basic stack:
- Initial DOM snapshot + every subsequent mutation (MutationObserver).
- Mouse position, clicks, scrolls, hovers, focus changes.
- Keyboard input (masked for PII — passwords, credit cards, etc.).
- Network requests: fetch, XMLHttpRequest, WebSocket, Server-Sent Events, sendBeacon.
- Console output: log, info, warn, error, debug — with stack traces.
- Web Vitals: LCP, INP, CLS, TTFB, long-task durations.
- CSS rule changes, viewport resizes, page-visibility transitions.
- Optional: webcam, microphone, screen frames (for support/demo recording use cases).
Who uses session replay
Session replay started as a marketing tool (heatmaps, funnel debugging) and grew into an engineering and customer-experience tool over the past decade.
Engineers
Debug "can't reproduce" bugs. Diff staging vs production. Generate end-to-end tests from real flows. Capture intermittent errors that QA never hits.
Product managers
Understand why users drop off a funnel — not just the conversion-rate delta. Watch the actual session that explains the metric.
QA & testing teams
Reproduce reported bugs in one click. Convert manual test flows into automated end-to-end specs.
Customer support
Pull up the exact session a customer is describing. Reply with the fix, not "could you describe the steps?"
Marketing & growth
Watch real visitors flow through your acquisition funnel. Validate that analytics tags fire correctly on every relevant page.
Privacy + compliance — the hard part
Recording everything means you have a duty of care for PII. Good session-replay tools mask sensitive data before it leaves the browser: passwords by default, credit-card numbers detected via Luhn validation, email/phone/SSN via regex, free-form PII (names embedded in chat) via on-device LLMs. Look for tools that scrub at capture time, not server-side after the fact.
What changed in 2026
AI made the leap from optional to essential. The 2026 generation of session-replay tools (Relyv included) treat the recorded session as input to AI workflows: AI-drafted bug tickets, root-cause summaries, auto-generated end-to-end tests, intent classification (what was the user trying to do?), and live patches that fix bugs without a redeploy. Sessions are no longer just for humans to watch — they're a substrate for automation.