What is session replay?
Session replay reconstructs a visitor's session as a playable recording of what happened on screen. It is not a video: the tracker records DOM mutations, mouse movement, scrolling and input events, and the player replays them in a sandboxed page, which is why the files are small enough to store at scale.
It is a reconstruction, not a recording
The common assumption is that replay captures video of someone's screen. It does not, and the difference explains most of the properties people find surprising.
The tracker takes one snapshot of the DOM when the page loads, then records the changes to it: nodes added and removed, attributes changed, text updated, plus mouse positions, scroll offsets, clicks and input events, each with a timestamp. Playback rebuilds the page from the snapshot and applies the changes in order.
That has consequences worth knowing. The recording is a few hundred kilobytes rather than tens of megabytes, so it can be kept and searched at scale. It is text, so it can be masked before it ever leaves the browser. And it can break: a page depending on a canvas, a video element or a cross-origin iframe will replay imperfectly, because the tracker never had access to those pixels in the first place.
What replay is good at
Replay is the tool you reach for when the numbers have already told you where the problem is and cannot tell you why.
- A funnel step with unusual drop-off: watch ten sessions that died there and the cause is normally obvious.
- A bug that only one customer can reproduce: replay their session instead of asking them to describe it.
- Rage clicks and dead clicks: repeated hits on something that is not actually a control.
- A form nobody completes: see which field they stop on and how long they hesitate.
It is bad at the opposite job. Watching sessions to find out what is wrong, with no hypothesis, is one of the least efficient activities in analytics. Aggregate first, replay second.
Live demo
See it on real data. The live demo is a fully populated dashboard on demo traffic, with no signup and no card.
Open the live demoThe privacy obligations are real
Mask input by default
Passwords, card numbers, addresses and message bodies must never be captured. Default-deny masking, where fields are hidden unless allowed, is the only safe posture.
Mask in the browser, not on the server
If sensitive text reaches the analytics server before being removed, it was collected. Masking has to happen before the payload is sent.
Set a short retention period
Replays are among the most sensitive data any analytics tool holds. Keep them for weeks, not years, and delete on request.
Consent is a separate question
Recording a session is processing personal data in most readings, regardless of whether a cookie is involved. Disclose it in your privacy policy and take advice on whether you need consent for it.
Session replay in mrkr
mrkr records sessions using DOM mutation capture, with input masking applied in the browser before anything is transmitted. Replays are stored with a retention window tied to your plan and can be deleted individually.
Replay is opt-in per site rather than on by default, because it is a genuinely different privacy posture from cookieless pageview counting and should be a deliberate decision rather than an inherited one.
The practical shortcut is the link between aggregate and individual: a funnel step or an exit page leads directly to the sessions behind it, so replay is used to answer a question you already have rather than as something to browse.
FAQ
Is session replay legal under GDPR?
It is lawful with the right basis and safeguards, and it is a higher-risk processing activity than aggregate analytics. In practice that means masking all input in the browser, keeping recordings for a short and stated period, disclosing it in your privacy policy, and taking advice on whether consent is required for your case.
Does session replay record passwords?
It must not, and any correctly configured tool masks password and payment fields before the data leaves the browser. Verify this yourself rather than trusting the setting: record a test session on a form and confirm the values never appear in the payload.
Does session replay slow down my site?
A well-implemented recorder adds a small script and batches its payloads, so the impact is minor for most pages. Very large or highly dynamic DOMs generate more mutations and cost more, which is one reason to record a sample of sessions rather than all of them.
Start with one line of HTML.Your first visitors show up within a minute.