What is session replay, and when should you use it?
Session replay lets you revisit a recorded website visit: its pages, clicks, taps, and scrolling. Use it to follow an interaction. Someone tried to book. Did the button work? Did an error appear? Could they continue? Replay can help answer those questions. It can't tell you what they were thinking.
The other tools still have a job. Analytics helps you find where the numbers changed. Heatmaps show patterns across visits to a page. Recordings let you follow an individual attempt. Buying all three doesn't make the decision for you; knowing what you're trying to fix does.
How session replay reconstructs a visit
Web replay can reconstruct a page from its document structure, called the DOM, and recorded events instead of storing ordinary screen video. Clarity uses this approach and keeps masked input content out of its recordings, as its FAQ explains. Other tools have their own capture methods and settings.
Try your own setup with test data. Can you follow the interaction? Are the things you've excluded actually excluded? A masked field won't tell you what someone typed, and missing content in a reconstruction doesn't prove it was missing from the real page. Check both before trusting the playback.
What are you trying to find out?
“Understand our users” sounds reasonable, but when would you be finished? Give yourself a question with an answer that could change what you do next. Otherwise, it's easy to collect more information without getting any closer to a decision.
| Your question | Start with | What to seek next |
|---|---|---|
| Did booking completion change? | Analytics | Comparable traffic, event definitions, and page versions |
| Where does the booking journey lose visits? | Funnel | The first meaningful divergence between steps |
| Is the booking link being used? | Click heatmap | Visits with a click, plus the total eligible visits |
| Do visitors reach the pricing explanation? | Scroll heatmap | Reach for the relevant layout and device |
| Why does clicking sometimes fail? | Session recording | Page response, errors, and reproducible conditions |
| Did our change cause an improvement? | Experiment or carefully qualified comparison | A defined outcome and competing explanations |
A funnel also has rules. In Google Analytics, an open funnel allows entry at any step; a closed funnel requires entry at the first. That choice changes who is counted, so compare definitions before comparing totals. See Google's funnel documentation.
Start where the numbers change
Imagine a bicycle repair shop that takes workshop bookings online. The shop and figures in this example are illustrative.
During one reporting period, 600 tracked visits reach the service page, 120 of those visits start a booking, and 48 of those starting visits finish it. Each stage is counted once per visit, within the same visit. Booking completion is 48 out of 120 starts, or 40%. Completion from the service page is 48 out of 600 visits, or 8%.
So, is conversion 40% or 8%? Both are correct. One measures completion after a start; the other measures completion from the service page. If the team just calls either one “conversion,” you can spend a meeting disagreeing about numbers that aren't in conflict.
Now mobile completion falls while desktop stays similar. Okay, there's somewhere to focus. Did the traffic change? Did the completion event stop firing? Is the form broken on a small screen? The rate points you toward the investigation; it hasn't done the investigation for you.
Check that events arrive before rewriting the offer. You don't want to redesign a perfectly working booking flow because its completion event went missing.
Find out what's happening on the page
Click maps aggregate interactions with page elements. Scroll maps summarize how far recorded page views reached. Those are the underlying behaviors described in Microsoft Clarity's heatmap overview.
The repair shop's mobile map shows plenty of clicks on a service card and fewer on the booking link below it. It's tempting to make the whole card clickable immediately. But what's happening inside it? Visitors may expect a booking link. They may also be using an accordion exactly as intended. Watch before choosing the fix.
Be careful about how much you put into the picture. A price appearing on screen doesn't mean someone read it. A photograph receiving a click doesn't mean they liked it. Keep the observation separate from the story you're building around it.
Keep the page version, device class, and relevant state together. Open the accordion, and the booking button may move. Change the mobile layout, and the same position can contain something else entirely. You need a map of the page those visits actually encountered.
Follow an actual attempt
Open a mobile visit where booking didn't finish, and start before the attempt. Then watch a successful visit under similar conditions. The difference between them can be much more useful than watching another failure.
In the repair-shop scenario, a visitor selects a date, taps Continue, and stays on the same screen. The visitor scrolls upward. An error beside an earlier field becomes visible. A successful visit supplies that field before continuing.
Now you have something specific to check: does the form make the missing field easy to find, and does focus move appropriately? You don't need to decide whether the visitor was angry or confused to investigate that behavior.
Reproduce the missing-field behavior on the actual site before deciding what to fix. Check whether it happens consistently, whether it depends on the visitor's previous actions, and whether the current page version still behaves that way.
Make sure the counts belong together
Two tools on the same site can count different visits. Consent, filters, blocked requests, sampling, and definitions all matter. Before combining their results, check what each one actually includes. Being installed on the same page isn't enough.
Write a small evidence note before joining the findings:
Decision: Should we change mobile booking validation? Page and version: /book, booking-v4 Population: Mobile visits that started this form Outcome: Completed booking in the same visit Analytics finding: Starts and completions, with counts Replay finding: Observable sequence, with recording links Coverage limits: Which visits or page states are missing? Next check: Reproduce the error and inspect focus behavior
If ten reviewed recordings contain a problem, you've found it in ten reviewed recordings. To say how common it is across the site, you need a compatible count of eligible visits. Dividing by a total from a different analytics population won't give you that answer.
Try an investigation before buying another tool
A small team can start with reliable page and outcome measurement, then add replay when the numbers raise questions it can't answer. A team with complicated interfaces may need replay much sooner. For a publisher, navigation and section reach may be the immediate gap. Start with the work you're having trouble doing.
Before buying another tool, try a real investigation with it. Can you filter the right page version? Find a recording associated with a failed attempt? Share the exact moment with a teammate? Distinguish an unresponsive control from an intentionally inactive one?
Check the privacy settings during the trial, too. Can you investigate the problem while keeping sensitive content out? The most detailed recording isn't automatically the most useful one, especially if it includes information your team shouldn't be collecting.
Finish with a change someone can verify
“Mobile engagement needs improvement” leaves the repair shop with plenty of work and very little direction. “The missing-field message appears above the visitor's position after Continue, without a clear way to find it” gives someone a problem they can reproduce.
The team can reproduce that behavior, improve the message and focus handling, and test the revised interaction. It can then check whether booking completion changes for comparable mobile visits, while watching for new errors elsewhere.
You can verify that the message now works. Whether that change caused extra bookings is a separate question. Keep both in the report: what you fixed, and what happened afterward. The next person making a decision needs to know how much each finding can support.