What session replay actually records

Every vendor describes this the same way: watch a video of your visitor using your site. It's a good pitch. It's also wrong: there is no video.

Nothing is filmed, no screen is captured, and what gets stored looks nothing like a recording. Knowing what it actually stores tells you where the risk is.

It is a set of instructions

When a replay starts, the recorder takes one snapshot of the page structure — the HTML, the styles, the shape of everything. After that it stops looking at the page as a whole and just writes down what changes. A div appeared here. The mouse moved there. This text got longer. Someone scrolled 400 pixels.

Playing it back means rebuilding the page from that snapshot and replaying the changes in order, at the original speed. What you watch is a reconstruction running in your own browser.

That editability is the whole reason masking can work at all. You can't redact a pixel after the fact without blurring it, but you can decide not to write down what someone typed. The decision happens at the moment of recording, in the visitor's browser, before anything leaves the machine.

Or it doesn't, and the typing goes to a server where somebody redacts it later. Both are sold as masking. They are not remotely the same thing, and it's the first question worth asking any vendor.

Three things it is brilliant at

I'll be honest about the ratio here. Most recordings are boring. Someone arrives, reads, leaves, and you've learned nothing you couldn't have got from a scroll map. Replay earns its keep in a small number of situations.

A form people abandon. Your analytics says 60% of people drop out of step two. Replay shows you that the postcode field rejects a valid postcode with no visible error message. That's a fifteen-minute fix nobody would have found by staring at a funnel chart.

A bug you can't reproduce. Support says the page "doesn't work" on some phones. You've tried three devices and it's fine on all of them. A recording of the broken session, with the console errors attached, usually ends the argument in a minute.

Rage clicks. Someone hammering the same button four times in two seconds. You can spot these in aggregate from a heatmap, but watching one happen tells you what they expected the button to do, which is the part you actually need.

All three start with a question. Switching replay on and browsing recordings hoping to notice something is how most teams use it, and it's how most teams quietly stop using it after three weeks.

What else ends up in there

The marketing leaves this next part out.

The recorder watches the page for changes. It doesn't know which changes are sensitive — it has no idea what your site is for. Unless it's been told otherwise, everything that appears on screen becomes part of the recording, including things that were never on screen when you tested it.

Default masking handles ordinary form inputs. Password fields, text boxes, the obvious ones. What it can't do is recognise that the div you built to display a customer's saved address is sensitive, because to a recorder that's just a div with some text in it.

So there is a job on your side: go through every page that shows anything about a person and mark it, then keep doing that for pages you ship later. Worth knowing before you switch replay on rather than after — and it gets quick once the first pass is done.

Four rules that keep it tidy

Four rules, in the order they matter.

• Redact in the browser, not on the server. If the typing reaches someone else's server before being removed, it was collected — whatever happens next. Ask where the redaction happens and don't accept a vague answer.
• Record less. Sample a few percent, or switch it on only for the pages you have a question about. Nobody has ever regretted holding fewer recordings.
• Delete on a schedule. Pick a retention period you can defend and enforce it automatically. Thirty days is plenty for most questions.
• Write the impact assessment. It's a formality right up until you're writing it, and then it's the thing that reminds you about the confirmation page you forgot about.

The legal side is its own subject and I won't compress it here. Replay sits in a different category from pageview counting, and the reasoning behind that is written up properly elsewhere. One thing carries the rest of it: a recording of one person is personal data.

How ours is set up

Masking happens in the browser, before anything is sent. Inputs are redacted at the point of capture, so the text never reaches us in the first place — we couldn't show it to you if you asked.

It's off until you turn it on. There's a hook to gate it behind consent, and it doesn't record until you call it. Recordings sit on the same retention clock as everything else.

It's an add-on at from $19 a month on any plan, priced by your rung, which is a deliberate choice. Replay is the one feature here that carries real privacy weight, and bundling it into a tier would mean switching it on for people who never asked for it. The product page has the detail, including what the recorder cannot capture at all. If you want the lighter-weight thing first, a heatmap answers a lot of the same questions with none of the weight.

The short version

1. It's not a video. It's a snapshot plus a list of changes, replayed in your browser.
2. That's why masking can work at all — and why where it happens decides everything.
3. Reach for it when you have a question. Browsing recordings hoping to spot something is how teams abandon it.
4. It will record your confirmation pages and your custom components unless you mark them — and keep marking them as you ship new ones.
5. Record less, keep it for less time, and write the assessment before you start rather than after someone asks.