What Is Session Replay? How It Works and When to Use It

Session replay is a way of recording one visitor’s activity on a website and playing it back afterwards, so you can watch the clicks, scrolls, page changes and pauses in order. It is not usually a video of the screen. It is a reconstruction built from logged page events, which is why it can show you exactly where someone got stuck.

How a session replay is captured

A recorder is a small script that runs in the visitor’s browser. When the page loads, it takes a snapshot of the page structure (the DOM). From then on it logs what changes: elements added or removed, text edited, scroll positions, pointer movement and clicks. Those events are sent to a server in chunks.

On playback, a viewer rebuilds the page from the snapshot and applies the events in sequence, with a scrub bar so you can jump around. The open source library rrweb popularised this approach, and many commercial tools build on the same idea. BusinessMCP’s session replay page describes an rrweb-based recorder, for example, with event markers for clicks, rage clicks, page changes and inputs, and a control that jumps to the first rage click.

Because the page is rebuilt rather than filmed, three things follow:

• Files are small. Events are text, not pixels.
• Masking happens before upload. A field can be replaced with asterisks in the browser, so the raw value never reaches the vendor.
• Replays can drift. If a page depends on content the recorder cannot see, such as cross-origin frames or some canvas elements, the playback may look incomplete.

What a replay shows

A good recording answers questions that numbers alone cannot. Analytics tells you that 40 percent of visitors leave the pricing page. A recording shows whether they scrolled past the table without noticing it, clicked a heading that looked like a button, or reached the end and left.

Typical things to look for:

1. Clicks on elements that do nothing (dead clicks).
2. Repeated rapid clicks on the same spot (rage clicks). The rage and dead click article explains how they are detected.
3. Forms abandoned halfway, and which field was last touched.
4. Content that visitors scroll past without stopping.
5. Layout problems that only appear on certain screen sizes.

Key takeaway: a recording is evidence about one visit. It becomes a finding only when you see the same pattern repeatedly or confirm it with a count.

What session replay cannot tell you

Replay has blind spots, and a few are worth stating plainly.

It shows behavior, not motivation. You can see someone hover over a price for eight seconds, but not whether they thought it was fair or confusing. It shows only the visitors who were recorded, which depends on sampling, consent and whether the script loaded. And it covers what the recorder can capture: BusinessMCP’s own page lists web only, no iOS or Android SDK, and no console log or network request capture inside replays, which is a limit when you are debugging an error rather than studying usability.

Question	Session replay	Aggregate analytics	Survey or interview
Where did this visitor get stuck?	Strong	Weak	Indirect
How many visitors are affected?	Weak (small sample)	Strong	Moderate
Why did they hesitate?	Suggestive	None	Strong
Is a fix working?	Supportive	Strong	Moderate

When session replay is worth using

It earns its place when you already suspect a problem but cannot see it. Common cases are a checkout or sign-up step with unexplained drop-off, a redesign that did not lift conversion, support tickets that say “the button doesn’t work”, and mobile layouts that were only tested in a desktop browser.

It is less useful when traffic is very low, because there is little to watch and little to compare, or when you have no one assigned to review recordings. A tool that records everything and is opened twice a quarter is an expense and a privacy liability with little return. If you are unsure how to review them efficiently, see how to analyze session recordings.

Replay also pairs naturally with heatmaps. A heatmap aggregates clicks and scroll depth over many visits, while a recording follows one. Session replay versus heatmaps covers when to reach for each.

Privacy basics before you switch it on

Recording visitors is processing personal data in many jurisdictions, so decide the rules before the script goes live.

• Mask by default. Form inputs, account pages and anything showing personal or payment data should be masked or excluded.
• Decide on consent. BusinessMCP’s page says that in gated consent modes the recorder waits for consent from your banner. Other tools behave differently, so check how yours does.
• Limit retention. Keep recordings only as long as you can justify. Plans differ here, as the data retention article explains.
• Reject bots. Headless browsers and automation tools clutter the data. BusinessMCP states that known bots are rejected at ingest and never stored.

The legal side is covered in session replay and GDPR. This is not legal advice, so confirm requirements with a privacy professional.

Choosing a first tool

If you want to try replay without a commitment, free options exist, and we list them in free session replay tools. If you want recordings tied to identified companies and heatmaps in one place, the BusinessMCP session replay product is one option, with recordings starting on the Growth plan at $79 per month according to its page. For feature-by-feature criteria, see our guide to session replay software.

Whatever you pick, start small: record a single high-value flow, watch a handful of sessions each week, write down what you see, and make one change at a time. The point of session replay is not the recordings. It is the fixes that follow.

A worked example: one checkout drop-off

Imagine a small online course seller whose analytics show 55 percent of people who reach the payment step never complete it. Numbers alone suggest ten explanations: price shock, a missing payment method, a slow page, a confusing coupon box, distrust. Session replay narrows them. Filtering to sessions that reached the payment step and did not convert, the analyst watches eight recordings on mobile. In five of them the visitor taps the coupon field, the keyboard covers the pay button, and the visitor scrolls up and down for several seconds before leaving.

That is a hypothesis, not a conclusion. The next step is to confirm it elsewhere, for example by checking whether the mobile completion rate is lower than desktop, and then to change one thing, such as moving the coupon field below the button. If the completion rate recovers over a few weeks, the recording did its job. If it does not, the hypothesis was wrong, and the team has lost little.

Notice what the recording did and did not do. It supplied a specific, testable idea that analytics could not. It did not prove anything, and it did not say how much revenue the fix would recover. That division of labour is the healthiest way to think about the tool.

Session replay in the wider analytics stack

Replay is one layer. A typical stack has aggregate web analytics for traffic and conversion, a funnel view for step drop-off, heatmaps for page-level patterns, replay for individual sessions, and surveys or interviews for motivation. Some products combine the first four on one script. BusinessMCP’s web analytics page describes a cookieless tracker, and its session replay page says the same single script powers recordings, which keeps page weight down compared with loading several separate tools.

Combining layers also reduces a subtle risk: reconciling numbers across vendors. When analytics, heatmaps and replay disagree about how many visitors a page had, trust erodes and reviews stall. A single source of counts is easier to reason about, though it ties you to one vendor’s strengths and gaps.

Terms you will meet

• Session: a visit, usually ended by a period of inactivity. Tools define the timeout differently, which is why session counts do not match across vendors.
• Sampling: recording only a share of visitors to control cost and volume.
• Masking: replacing sensitive content with placeholders before upload.
• DOM snapshot: the stored copy of the page structure used to rebuild a replay.
• Frustration signals: automatically flagged behaviors such as rage clicks, covered in rage clicks and dead clicks.
• Retention: how long recordings are kept, discussed in session replay data retention.

Knowing these makes vendor pages far easier to compare, because the same feature often goes by different names.