What is a session recording?

What can you learn from a session recording that a heatmap cannot show?

Heatmaps answer where. Recordings answer in what order, and after what.

Four things only a recording surfaces:

Sequence. A visitor who read pricing, went to the case studies, returned to pricing, then left, is telling a story about a specific unresolved objection. The heatmap shows three warm regions and no story.

Hesitation. Cursor hovering over a button for four seconds before clicking elsewhere. The heatmap logs the click that happened, never the click that almost happened.

Recovery attempts. Someone hitting an error, correcting a field, hitting the same error, then leaving. This is the most valuable thing in the archive and it is invisible in aggregate.

Context around a failure. A rage click tells you an element failed. The recording shows what the visitor was trying to accomplish and what they did next.

Recordings are for causality and heatmaps are for prevalence. Use the heatmap to pick the page, the recording to understand it.

How do you sample recordings so you are not wasting hours?

Watching random sessions is the most common way teams waste time on this tool. Random sampling on a normal site returns mostly bounces and mostly success, neither of which teaches anything.

Filter first. Useful filters, in rough order of yield:

1. Reached a key step, did not complete it. Hit the pricing page, no demo request. Started the form, no submit. This is the highest yield filter that exists.
2. Contains a rage click or a dead click. Pre-filtered frustration.
3. Contains a JavaScript error. Real defects with a reproduction attached.
4. Long duration with no conversion. High effort, no outcome, usually confusion rather than disinterest.
5. Specific traffic source. When paid conversion rates lag organic, watch the paid sessions.
6. Specific device or browser. When analytics shows one segment underperforming.

Filters that waste time: newest sessions, longest sessions overall, sessions from your own country because it is convenient.

How many recordings do you need to watch?

Fewer than people expect, provided they are filtered.

A filtered set reaches saturation quickly, meaning new recordings stop revealing new patterns. For a single well-defined question that tends to happen somewhere between 15 and 25 recordings, and watching 200 unfiltered sessions teaches less than watching 15 filtered ones.

Saturation is the stopping rule rather than any target count. When three consecutive recordings show you nothing you have not already written down, stop watching and start writing the hypothesis.

Two calibrations:

• One question at a time. "Why do people abandon this form" is a session. "Why is conversion down" is not a question a recording can answer.
• Take notes as you watch, timestamped. Retrospective recall of twenty sessions is unreliable. A running list of observations with timestamps is evidence you can show someone.

How do you turn recordings into a hypothesis?

Recordings produce observations. Observations are not hypotheses, and shipping straight from observation is how teams make changes that lose money without noticing.

The chain:

1. Observation. "Seven of 20 visitors scrolled past the pricing table, then scrolled back up to it before leaving."
2. Interpretation. "They could not find the number they were looking for on first pass."
3. Hypothesis. "Adding the starting price above the comparison table will reduce the back-scroll and increase demo requests."
4. Test. Run it as a structured A/B test with a predetermined sample size and primary metric.

Skipping step 4 is the common failure. A recording is a sample of humans, not a measurement of effect. Twenty visitors telling a consistent story is strong evidence about the problem and no evidence at all about whether your solution works.

That sequence is documented in full in building data-backed CRO hypotheses.

What are the practical limits?

Selection bias in what you watch. Filtering to failures means seeing only failures, and it becomes easy to conclude the site is broken for everyone. Watch a few successful sessions for calibration.

Confirmation bias in what you see. Ambiguous behavior gets read as supporting whatever you already believed. The mitigation is having someone else watch the same set and compare notes before discussing.

Masked fields hide the content of the problem. You see that someone struggled with a field, not what they typed. Correct for privacy reasons, and it limits diagnosis on validation issues.

Cursor is not gaze. A stationary cursor does not mean a stationary reader. Many people never move the mouse while reading.

Recordings do not scale to measurement. They cannot tell you how often something happens. That is what analytics and heatmaps are for. Use recordings for depth, then quantify prevalence elsewhere.

Which Webflow specifics change how you sample recordings?

Installation is the same snippet as any behavioral tool, in Site Settings, Custom Code, Head Code, published before it does anything. What changes on Webflow is the filtering.

Your highest-yield filter needs a conversion endpoint that Webflow does not give you by default. "Started the form, did not submit" depends on the tool knowing what submitting looks like, and Webflow's default success state swaps the form in place with no page load. Set a redirect to a confirmation URL in the form settings, or fire an event on the success element, before you build the filter. See event tracking.

Pool CMS items with a URL pattern filter. Every collection item is its own URL, which starves individual pages of sessions. A recording list filtered to a path fragment such as the collection slug pools the whole template, and because you watch recordings one at a time, this works even where a heatmap of the same template cannot be aggregated.

Exclude the .webflow.io staging domain. Every session on it is a colleague, and internal sessions look like unusually confident visitors.

Date-bound the sample after a redesign. Recordings keep the page as it was, so an archive spanning a rebuild mixes two different sites into one set of conclusions. Filter to the current version before you count anything.

Related terms

Session replay · Rage click · Dead click · Website heatmap · Form analytics

Deeper reading: Diagnosing why users drop off using session recordings. Service: Conversion Rate Optimization.

FAQ

Is a session recording the same as session replay?

In practice yes, and vendors use the terms interchangeably. Where a distinction is drawn, replay refers to how a visit is captured and rebuilt, recording refers to the resulting playback and the work of reviewing it.

Do you need consent to record sessions?

You need a lawful basis under GDPR, which is either consent or a documented legitimate interest assessment, plus default masking of personal data and a defined retention period. Session replay sets out the full configuration checklist.

How long should you keep recordings?

30 to 90 days covers most diagnostic work. Longer retention increases exposure without improving analysis, because a recording from eight months ago describes a site that no longer exists.

Should you watch recordings before or after looking at the numbers?

After. Analytics tells you which step loses people, and that number is what makes a filter worth building. Opening the recording list without a question first is how teams spend an afternoon watching successful sessions.