What is Session Replay?

Session replay (session recording) is a technique in which a script embedded in a website or app captures the sequence of user interactions and page states during a visit, and reconstructs them as a playable recording. Unlike a screen-capture video, most replay tools record DOM changes and input events rather than pixels, then re-render them, which is why replays can be masked, searched, and filtered. Replay is behavioral analytics at the level of the individual session, and its value is the same as observation's everywhere: it shows what people did, in sequence, with the hesitations and dead ends that funnels and heatmaps average away. Its limit is observation's limit too: it shows behavior, never intent.

What It Is Good For

Diagnosing a funnel drop. Analytics says 40% abandon at step three; a dozen replays of those abandonments show the validation error nobody logged, the modal that covers the button on small screens, the field people fill and then delete.

Reproducing bugs and edge cases. A support ticket that "doesn't make sense" often makes complete sense once you watch the session that generated it.

Seeing real users on real data. Replays show the product in the wild: the browser extension that breaks the layout, the copy-paste from a spreadsheet, the twelve tabs, none of which appear in a clean prototype test.

Prioritizing research. Patterns across replays (rage clicks, repeated back-and-forth, form abandonment) tell you where a study should look.

Replay and Research Recordings

Session replay and the recorded sessions of a usability study look alike and differ fundamentally. A study recording (a Ballpark session, say) captures a recruited participant who consented to be recorded, completing defined tasks, often narrating their thinking on camera: rich in intent, limited to the tasks and the sample. A replay captures an anonymous real user doing whatever they came to do, silently: rich in reality, empty of reasons, and collected under a consent that is general rather than specific. The two are complementary. Replay locates and sizes problems in production; study recordings explain them and test fixes, with the participant's voice attached. The loop from a replay pattern to a quick recorded study of that flow is one of the fastest diagnostic cycles available.

The Privacy Discipline

1. Mask by default.
Form inputs, personal data, and anything sensitive should be masked at capture, not at playback; passwords, payment fields, and health or financial content must never be recorded at all. Regulators in several jurisdictions have treated unmasked replay of sensitive data as a serious breach.

2. Disclose and obtain consent appropriately.
Replay is personal data processing; where consent rules apply (cookie and tracking regimes), replay runs only after consent, and the privacy notice must say plainly that sessions are recorded. "It's in the policy" is the floor, not the standard; the respect-for-persons principle applies to users as much as to participants.

3. Limit access and retention.
Replays are watched by few people, for stated purposes, and deleted on a schedule. A library of recordings of identifiable users is a liability with a play button.

4. Sample, don't hoard.
Recording a sample of sessions, or sessions matching a diagnostic condition (an error, an abandonment), serves the purpose with far less data than recording everything.

5. Never identify for curiosity.
Linking replays to named accounts is sometimes necessary for support; doing it to watch a specific person is surveillance.

The Bottom Line

Session replay lets teams watch real users in real sessions, and it is the fastest way to turn a mysterious metric into a visible problem. It shows behavior, not intent, so pair it with consented, narrated study recordings for the why. And because it observes people who didn't sign up to be observed, run it under strict discipline: mask at capture, disclose and consent properly, restrict access, retain briefly, sample rather than hoard. The insight is real; so is the obligation.