Session Replay
Date: 2026-08-16
Reconstructed playback of what someone did. It explains why faster than any dashboard and it is not evidence of how often — because you chose which sessions to watch, and you can’t watch enough of them to count.
What it is
Session replay records DOM mutations, interactions and scroll position, then reconstructs the session for playback. It isn’t video — it’s a serialised event stream replayed against a rebuilt page, which is why file sizes are manageable and why replays sometimes render imperfectly.
What it’s genuinely good at
- Explaining a known problem. Funnel says checkout step 2 loses 40%; replay shows people clicking a non-clickable element
- Finding what instrumentation missed. Rage clicks, dead clicks, repeated scrolling, form abandonment you didn’t measure
- Reproducing bugs. A support ticket plus its replay is worth an hour of guessing
- Rendering and device failures that never appear in aggregate data because they affect one browser
- Persuading people. Watching one person fail moves stakeholders in a way a chart doesn’t. Use this carefully — see below
What it cannot do
It is not quantitative. Three reasons, and they compound:
Sampling. Replay is almost always sampled, often heavily, for cost — Data Sampling.
Selection. You watch the sessions the tool surfaces or that you filter for. Filtering to “sessions that abandoned checkout” means you see only failures, and everything looks broken.
Volume. You can watch perhaps twenty sessions in an hour. Twenty is not a sample of anything — Sampling Error.
In plain terms: replay tells you a failure mode exists and what it looks like. It cannot tell you how common it is. Pair it with an aggregate that can — Funnel Analysis, Form Analytics.
The persuasion strength is also the risk: a vivid single session is more convincing than a correct statistic, and that asymmetry gets exploited, usually unintentionally, to justify a change nobody measured.
The privacy obligations
Replay captures more than any other analytics tool, so it carries more obligation.
- Mask all inputs by default, and verify rather than trusting the setting. Passwords, payment fields, addresses, dates of birth
- Mask by allowlist, not blocklist. Block-listing means the next field someone adds is captured
- Consent applies. It’s non-essential, so it needs consent — and arguably clearer disclosure than analytics, given what’s recorded — Consent Management, UK GDPR and PECR for Analytics
- It’s personal data. A replay is a record of one identifiable person’s behaviour, subject to access and erasure requests. Make sure you can find and delete one person’s replays
- Retention. Short. Replays age out of usefulness in weeks and remain a liability for as long as you keep them — Data Retention
- Check what leaks into the DOM. Masking covers inputs; an order confirmation page rendering a name and address in plain markup is captured as page content
Using it well
The discipline that separates useful replay from an afternoon lost:
- Start with a question, from aggregate data. “Why do mobile users abandon at delivery?” Never “let’s watch some sessions”
- Filter to the segment the aggregate identified
- Watch until you stop learning — usually five to ten sessions before the pattern repeats
- Write down the hypothesis, not the anecdote
- Go back to aggregate data to size it. If the pattern is real, something should be countable
- Then test it — Hypothesis Design
Step 5 is the one that gets skipped, and skipping it is how a vivid single session becomes a roadmap item.
Where it fits
Quantitative finds where; qualitative explains why. Replay is the cheapest qualitative method you have — no recruitment, no scheduling, real customers with real intent — and the weakest, because you can’t ask them anything.
For the question replay can’t answer, that’s Usability Testing. For where it can’t run at all, that’s Checkout Instrumentation Constraints.