What is session replay? A practical guide

Session replay is a reconstruction of a website or app visit, built from events the page emitted (clicks, scrolls, DOM changes) rather than from a camera or a screen-recording file. In practice, a small script on the site sends those events to a server, and a player in a dashboard plays them back so a product, UX, or support team can see what happened.

That is the definition we use on the glossary page and the session replay feature page. Microsoft Clarity describes its recordings in the same family of terms: a reconstruction of page information and actions, not a video of the user. If you arrived here by searching "what is session replay," that is the idea to hold onto.

What is session replay, in plain language?

It is a way to re-watch a single visit to your site, the way the page appeared to that visitor, without sitting next to them. You can see where they clicked, how far they scrolled, which page they opened next, and whether the interface actually responded.

It will not tell you how many people converted this week. That is analytics. It also is not a user interview, and it is not a marketing video. What it can tell you is why one person stopped at the shipping form, or whether a JavaScript error appeared right after they clicked "Place order." Screenshots and aggregate charts leave that gap open.

Think of a flight recorder for the page, not a webcam. The recorder stores a stream of changes. The player rebuilds the page and applies those changes in order. You can pause and speed up. In Replayly you can also skip inactivity and jump to markers such as rage clicks or console errors.

How does session replay work technically?

The browser captures a stream of DOM events, sends them in batches to an ingest endpoint, and a player rebuilds the visit later. Our tracker uses rrweb. At runtime it loads config for sampling, allowed domains, block selectors, and consent mode, then posts gzipped event batches. Size caps, rate limits, plan quotas, and origin checks sit in front of storage so a busy site cannot overwhelm a workspace.

Because the recording is an event stream, privacy rules can run before data leaves the browser. Input values can be masked. CSS selectors can hide a live card preview or a support widget so it is never captured. A raw video file cannot easily "un-type" a password after the fact, which is a big reason modern web replay tools work this way instead of screen-capturing the tab.

In Replayly you install one script tag with a project id, or you load the same snippet through Google Tag Manager. After you deploy it, the project page has a Verify installation step. Events go to /api/ingest on the same origin.

What gets recorded in a session, and what should never be?

A session typically records the structure of the page the visitor saw and the actions they took: clicks, taps, scrolls, mouse movement, and DOM updates as the page changes. It may also collect technical context that helps you filter later, such as device, browser, or the fact that a console error fired. Replayly can mark those moments and, on Starter and above, filter sessions by rage clicks, dead clicks, and console errors.

Input values should never appear as plaintext. Passwords, addresses, and payment fields do not belong in a replay a teammate can open next week. We mask input values by default on new projects, and we respect Do Not Track unless you explicitly opt out with dnt=0 on a test snippet. On Starter and above you can wait for window.replayly('consent'), mask all visible text, and block CSS selectors. The install guide also documents the rr-block and rr-mask classes.

Keep a few other things out of scope too. Pages you are not allowed to record. Traffic from children (Clarity, for example, says it should not be used on sites targeting users under 18; read each vendor's terms). Any field your policy treats as sensitive even if a default mask might miss it, such as a one-time code rendered as ordinary text. Confirm masking with a test form on staging before the snippet goes to production. The GDPR session recording checklist is a practical list for that work. It is not legal advice.

How is a heatmap different from session replay?

A heatmap summarizes many visits. Replay shows one visit, in order. A click heatmap shows where people clicked on a page. A scroll heatmap shows how far they typically reached. That is useful once you already suspect a pattern: almost nobody reaches the pricing table, or people keep clicking a heading that is not a link.

Replay answers a different question: what did this person do next? If a heatmap shows a cluster of clicks on a dead control, you still want a replay to see whether they left, tried another path, or sat there and clicked again. Our heatmaps are generated from the same recordings, on the Pro and Business plans only. They are not on Free or Starter, and they are not a second tracking script. The privacy defaults you set for replay also shape what can appear in a heatmap.

If you only need a free heatmap, Microsoft Clarity includes them on its free product. That is a fair reason to stay there. If you want replay first and heatmaps later, our plan split matches that sequence.

Why do privacy defaults matter for session replay?

A missed toggle should not leak a password or a home address into a recording. Session replay is sharp in the wrong direction too: it can reconstruct a form a visitor thought was private. The safer design is to start strict and relax only what you have a reason to relax.

We documented that position on product facts and in Privacy defaults, not privacy settings: input masking and Do Not Track are on from the first snippet. When you review another vendor (Clarity, Hotjar, PostHog, whoever), read their current masking and cookie documentation. Do not assume the defaults match. Clarity's official docs, for example, also mask input boxes in every mode. The difference between products is often DNT, consent, hosting, and plan structure, not whether a mask exists at all.

If you use a hosted Replayly workspace, we process session data to provide the service. Your team still has to decide a lawful basis, use consent mode where it is required, keep masking on, and set retention that matches your policy. Retention is 7 days on Free, 30 on Starter, 90 on Pro, and 365 on Business. Shorter is usually easier to defend than longer. Again, this is product documentation, not legal advice. Read the privacy policy as well.

How can you try session replay with Replayly?

Create a workspace, add a project, and paste the snippet on a staging site first. The Free plan includes 1,000 sessions per month, 7-day retention, and one project. It samples visits after the monthly limit. Paid plans block new recordings once the quota is reached.

A short path that avoids most surprises:

1. Create a project and copy the snippet from the install guide.
2. Add it to a staging page that includes a form. A contact form or a dummy checkout is enough.
3. Submit test data, then open the replay and confirm the input values are masked.
4. Turn on consent mode and block selectors on Starter if your production site will need them.
5. Only then install on production, and use Verify installation.
6. On Starter, filter for rage clicks or console errors when you have a bug report. Add heatmaps on Pro if you need page-level patterns.

Replayly is a Microsoft Clarity-style tool. It is not a free-unlimited Clarity clone, and it is not a survey or analytics suite. If you are comparing vendors, start with Best Microsoft Clarity alternatives in 2026 or Replayly vs Microsoft Clarity. For a one-page definition you can cite, use the glossary and the fact sheet.

The tool is at its best when it answers a specific question about a real visit. It is at its worst when it is treated as a camera pointed at every form.

Sources

• Replayly glossary: session replay, feature page, facts, and privacy controls, checked 13 November 2026.
• Clarity recordings overview, used only to confirm that the event-stream model is also how a major free tool describes recordings, checked 13 November 2026.