How to Analyze Session Recordings: A Filter-First Playbook
Stop watching recordings at random. A filter-first playbook for shops: start with a question, the filters that matter, a note template and a routine.
By Joost BakkerPublished 13 min read

On this page
Why random watching wastes time
A session recording (also called session replay) is a reconstruction of one visit: pages, mouse movements, taps, scrolling, clicks. It's one of the most convincing research tools there is. Seeing a real visitor tap "Add to cart" four times without result changes minds in a meeting faster than any chart.
It's also the easiest way to waste an afternoon. Most visits are short and uneventful: someone lands, looks, leaves. Watch 30 random recordings and you'll see 25 of those, two confusing ones and maybe one useful one. You'll remember the most dramatic visit, not the most common problem.
The fix is simple: decide what you're looking for before you press play.
Start with a question
Good questions are specific about who, where and what:
| Weak | Strong |
|---|---|
| "Let's see how people use the site." | "Why do mobile visitors leave product pages without adding to cart?" |
| "Check the checkout." | "What happens in visits that reach the cart but don't order?" |
| "Look at the new homepage." | "Do new visitors find the category tiles on the new homepage on mobile?" |
Where do good questions come from?
- Analytics: a page or step with a high drop-off.
- Heatmaps: a spot with rage clicks or dead clicks. See how to analyze heatmaps.
- Surveys: a theme in the answers ("couldn't find delivery info"). See 80 on-site survey questions.
- Customer service: a complaint that keeps coming back.
- A change you made: "Did the new size selector work?"
The filters that matter
Every recording tool has filters. These are the ones that answer shop questions:
| Filter | Use it to | Example |
|---|---|---|
| Page visited | Focus on one page type | Product pages only |
| Device | Separate mobile from desktop | Mobile only: different layout, different problems |
| Ordered / didn't order | Compare buyers and non-buyers | Non-buyers who reached the cart |
| Rage clicks | Find frustration | Several fast clicks on one spot |
| Dead clicks | Find things that look clickable but aren't | A tap after which nothing changes |
| JavaScript errors | Find bugs | Visits with an error on the product page |
| Clicked element | Follow up on a heatmap | Visits that clicked "Size chart" |
| Visit length | Skip bounces | Longer than 30 seconds |
| Traffic source | Check campaign landing pages | Paid social visitors on the landing page |
| New vs returning | Find first-visit confusion | New visitors only |
Combine two or three. "Mobile + product page + rage clicks + no order" usually gives you a short list of very informative visits.
Sort by frustration or length, not by date, if your tool allows it. The newest visits aren't the most useful.
Start from the heatmap. If a heatmap shows rage clicks on one element, open the recordings of visitors who clicked exactly that element. Many tools link the two; in Varly, Recordings next to an element in the heatmap list does this (watch session recordings).
How many to watch
There's no magic number. A practical rule:
- Watch 5 recordings that match your filter.
- Write down each problem you see (template below).
- Watch 5 more. If they show the same problems, you've found the pattern. If they show new ones, keep going in batches of 5.
- Stop when a batch adds nothing new. Researchers call this "saturation".
For most questions that's 5–15 recordings, or 30–60 minutes. If you're at 20 and every visit shows something different, your filter is probably too broad. Narrow it.
Speed up. Skip idle moments and watch at 2× or faster; slow down when something happens. Most players mark rage clicks, errors and page changes on the timeline, so you can jump straight there.
One recording is an anecdote. Before you change something, check how common it is: how many visits in the filtered list show the same rage-click spot or error? The heatmap or error report answers that in a minute.
The math: why 5–15 recordings only works after filtering
If a problem shows up in 30% of the recordings in your list, 9 recordings give you a 95% chance of seeing it at least once. If it shows up in 2%, you need 149. That's the whole case for filtering, in two numbers.
The formula is the one usability researchers have used since Nielsen and Landauer's 1993 model of problem discovery (Nielsen Norman Group): if a problem appears in a share p of visits, the chance that n recordings show it at least once is 1 − (1 − p)^n. Seeing it once doesn't make a pattern, so the last column asks for at least two sightings (binomial distribution).
| Share of recordings in your list that show the problem | Recordings for an 80% chance to see it once | …for a 95% chance | Recordings for a 95% chance to see it twice |
|---|---|---|---|
| 2% | 80 | 149 | 236 |
| 5% | 32 | 59 | 93 |
| 10% | 16 | 29 | 46 |
| 20% | 8 | 14 | 22 |
| 30% | 5 | 9 | 14 |
| 50% | 3 | 5 | 8 |
Computed by us on 7 November 2026 in Python, assuming each recording is an independent visit and the problem is visible whenever it happens.
What this means in practice:
- Filtering raises p. Hypothetical example: a size-selector bug hits 1 in 50 mobile product page visits (2%). Watching random mobile product page visits, you'd need about 149 recordings to be 95% sure of catching it once. Filter to visits with rage clicks on the size selector, where say 4 in 10 show the bug, and 6 recordings are enough.
- The "stop when a batch adds nothing" rule has a blind spot. Ten recordings give you an 80% chance of having seen any problem that's in 15% of your list. A problem in 2% of visits will usually stay hidden: 10 recordings catch it only 18% of the time. For rare problems, count instead of watch: error reports and rage-click counts cover every visit.
- The same problem in 4 of 5 filtered recordings is a strong signal. It isn't a fluke of the sample. Check its scale in the heatmap, then act.
What to note (template)
Write notes in a fixed format, in a shared sheet. It turns watching into data your team can sort and count.
| # | Link + time | Device | Page | What the visitor tried | What went wrong | Type | Severity |
|---|---|---|---|---|---|---|---|
| 1 | link @ 01:42 | Mobile | Product | Choose size M | Tap on "M" did nothing; tapped 4×, then left | Bug | High |
| 2 | link @ 00:35 | Mobile | Product | Find delivery time | Scrolled up and down twice, opened returns tab instead | Findability | Medium |
| 3 | link @ 02:10 | Desktop | Cart | Apply discount | Opened new tab (likely searching for a code), came back, left | Distraction | Medium |
Types keep it countable: Bug, Findability (can't find info), Comprehension (doesn't understand), Trust (hesitates around price, payment, returns), Distraction (leaves the flow), Performance (slow, jumpy page).
Severity: High = blocks the purchase; Medium = slows it down or causes doubt; Low = cosmetic.
Rules for good notes:
- Describe what you see, not what you guess. "Scrolled up and down twice" is a fact. "Visitor was confused about price" is a guess.
- Add a timestamp link so a colleague can check in 10 seconds.
- One row per problem, not per visit.
12 patterns to look for in shop recordings
These are common patterns in ecommerce recordings. Use them as a checklist of what to watch for, not as findings about your shop.
- The repeated tap. Several taps on the same button: unresponsive element, slow update or an invisible error.
- Tapping things that aren't links. Product images, badges, prices, swatches. Visitors expect them to do something.
- Up-and-down scrolling. The visitor is looking for something. Note where they stop.
- Opening every info tab. Delivery, returns, sizes. The information is needed before buying; consider showing it without a click.
- Size chart back-and-forth. Opening, closing, picking a size, opening again. Size uncertainty.
- Zoom attempts on mobile. Pinching on product images or small text. Images too small or zoom broken.
- The disappearing form. A keyboard covering the field or button on mobile; a page that jumps when the keyboard opens.
- Leaving at the shipping cost. The visitor sees the total in the cart and leaves. Common, and a hint to show shipping earlier.
- The coupon hunt. Clicking the discount field, then leaving the tab. Often comes back, sometimes doesn't.
- Filter frustration. Applying filters, getting zero results, removing them again.
- Pop-up whack-a-mole. Closing a newsletter pop-up, then a chat bubble, then a cookie banner, before seeing the product.
- Layout shifts. The visitor taps a button just as the page moves, and hits something else. Often caused by late-loading banners, reviews or scripts.
Turning notes into ideas
After a session of watching:
- Sort your notes by type and count them. "Size selector didn't respond: 6 of 12 mobile recordings" is a finding. One dramatic visit isn't.
- Check scale elsewhere. How many visits had rage clicks on that element this month? What share of mobile product page views is that?
- Fix bugs straight away. Bugs aren't test ideas. Hand them to your developer with the recording links.
- Turn the rest into hypotheses. "Because 4 of 10 mobile visitors searched for delivery information and the delivery tab is the most clicked tab, we believe showing the delivery date under the add-to-cart button will increase add-to-cart rate." Use a template: A/B test hypothesis template.
- Prioritize with your usual framework: how to prioritize A/B test ideas.
Can AI help? Yes, with the summarizing. Many tools now summarize a recording in a few lines (what the visitor tried, where it went wrong). That's useful for triage: read 20 summaries, watch the 5 that matter. Always watch before you act, because AI summaries can over-interpret. More in AI for conversion optimization.
Privacy: masking and what you should never record
Recordings show individual visits, so privacy matters more here than anywhere in CRO.
- Consent first. In the EU, recordings need the visitor's consent. See GDPR and CRO.
- Mask in the browser. Text should be hidden on the visitor's device, before anything is sent. Form fields must always be masked.
- Never record checkout and payment pages, or account pages with addresses and order history.
- Test it. Make a test visit with a fake name and address, watch your own recording, and check that you can't read them.
- Keep recordings for weeks, not years. Keep the few you need for a report; let the rest expire.
- Share links, not downloads. A link only works for people with access; a downloaded video travels.
Masking also affects your analysis: if all text is masked, you'll see that someone tapped a button but not which button label. Most tools let you unmask safe elements such as product titles and prices.
A 45-minute weekly routine
Do this every week, ideally on the same day.
| Minutes | Step |
|---|---|
| 0–5 | Pick this week's question (from last week's analytics, heatmaps, surveys or a change you made) |
| 5–10 | Set the filters: page type, device, frustration and/or order status |
| 10–35 | Watch in batches of 5 at 2× speed; note problems in the template |
| 35–40 | Count your notes by type; check the scale of the top problem in heatmaps or error reports |
| 40–45 | Hand bugs to development; write 1–2 hypotheses for the backlog; save the best recordings as favorites for your report |
Rotate the question: product pages on mobile one week, cart the next, a campaign landing page after a launch. In a quarter you've covered your main page types with real evidence.
FAQ
What's the difference between a rage click and a dead click? A rage click is several fast clicks on the same spot (frustration). A dead click is a click after which nothing on the page changes (something looked clickable but wasn't, or didn't respond).
Should I record all visits or a sample? For small shops, all consenting visits gives you enough to filter. Busy shops can record a share (10–50%). France's CNIL, in its final recommendation on session replay (adopted October 8, 2026, published November 5, 2026), asks for one of two things when you use recordings to improve the user experience: random sampling, or deleting recordings you don't need soon after you've reviewed them.
Can I watch one specific customer's visit? Only if your setup and privacy policy allow it, for a clear purpose like support. For CRO you look at patterns across visitors, not at individuals.
How long should I keep recordings? Long enough to analyze and report: weeks to a few months. Keep a few as favorites for reports; let the rest expire.
Do recordings slow down my site? The recording script adds some JavaScript. Good tools load it only for visits that are recorded. See our script weight study.
Varly's recordings come with filters for frustration, orders and clicked elements, notes at a timestamp and AI summaries. Request access.
Related: How to analyze heatmaps · GDPR and CRO · How to prioritize A/B test ideas · A/B test hypothesis template · AI for conversion optimization

