Session Recordings: How to Find a Problem Worth Investigating
Choose session recordings with a sampling plan, separate observation from interpretation, keep useful notes, and handle Clarity masking and consent correctly.
8 min readBranislav Mateas
Copy post as Markdown
On this page
A session recording shows one visit in detail. That makes it persuasive and risky. One tense replay can become a redesign request before anyone knows how often the behaviour occurs, or whether successful visitors did the same thing.
A useful review has a narrower goal: find a pattern that differs between groups and can be counted outside the sample. This article uses Microsoft Clarity because its behaviour is documented, but the method fits other replay tools. The e-shop and all its numbers are hypothetical, and the filter combinations were not run for this article.
Start with a measured gap
Do not open the session list first. Start from a number, such as a drop between two steps or a rise in one JavaScript error. A GA4 funnel with a device breakdown is one way to find it. Then write a question a replay can help with. "Why do people leave?" is too broad. "What happens on the shipping page just before mobile visitors leave?" is workable.
Here is the gap over 28 days, rebuilt with Clarity filters so that later counts share one source:
At the desktop rate, mobile would lose 2,800 × 0.20 = 560 visits. The gap is 980 − 560 = 420 visits. If a gap of that size would not change a decision, stop here.
Check masking and consent before the first replay
Masking comes first because it only works forward. Clarity's masking page says setting changes affect new recordings, can take up to an hour, and can't be applied retroactively. The FAQ adds that specific recordings can't be deleted, and that deleting one user's data means deleting the entire project.
The same masking page sets these rules:
Balanced is the default mode. It masks numbers and email addresses.
Strict masks all content. Relaxed masks none, apart from input boxes and dropdowns.
Input boxes and dropdowns are masked in every mode.
data-clarity-mask="True" and data-clarity-unmask="true" both override the website settings.
Content inside style sheets and style tags is not masked.
The FAQ also says Clarity suppresses all client content by default, which does not match the Balanced default, so read the mode in Settings instead of assuming it. An inference from the Balanced definition: a customer name printed in an order summary may stay visible unless that element is masked. Complete a test checkout with fake details, then replay it and inspect summaries, error messages and account pages. Also check page URLs. The FAQ says URL parameter masking is requested through support and doesn't cover referrer or clicked URLs.
Consent changes what a session means. Since October 31, 2025, Clarity has enforced consent signals for visits from the EEA, UK and Switzerland. When analytics storage is denied, the tag still loads and collects cookieless data. The Consent API page says each page view then gets a unique ID. Reporting changes follow: every page view is a new session, page count is 1, every page is both entry and exit, multi-step funnels show full drop-off, and quick backs are 0.
So a one-page replay ending on the shipping page may not show a visitor leaving. It may only show where a cookieless session was cut. Two inferences follow:
Setting Session page count to at least 2 should leave mainly consented sessions. It also removes consented one-page visits, and people who consent may behave differently from those who don't.
The reporting table lists more recordings without consent, not none. Declining cookies therefore may not remove a visitor from replay. Clarity's pages describe product behaviour, not legal conclusions, so the site's privacy owner should review that setup.
Fix the groups, the quota and the date range first. Every group below also uses Visited URL for the shipping page and Session page count of at least 2.
Group
Added filters
Replays
Question it answers
Mobile leavers
Device Mobile, Exit URL shipping
12
What happens before leaving?
Mobile continuers
Device Mobile, Visited URL payment
6
Does it also happen to people who continue?
Desktop leavers
Device PC, Exit URL shipping
6
Is it specific to mobile?
That is 24 replays. It is a working budget, not a statistical sample size, so it can't produce a reliable rate.
Then apply four rules:
Keep the range inside one release, so two versions of the page don't mix.
Take the same number per week, such as 3 mobile leavers from each of 4 weeks. The session list sorts by most recent by default, so one busy day could fill the quota.
Don't sort by clicks or duration for this sample. Those sorts surface extreme visits, which can help when hunting a bug but say little about a typical one.
Write down skip reasons in advance, such as internal testing. "Looks boring" is not a reason.
Clarity can't filter by watched state, so keep the list of replays yourself.
Write what happened, then what it might mean
An observation is something a second reviewer could confirm at the same timestamp. Keep it apart from the explanation.
Observation
Tempting interpretation
Evidence that could test it
Tapped Continue 3 times in 4 seconds, no visible change
Button is broken
Reproduce on the same device and browser
Tapped the shipping price text, flagged as dead click
Expected it to be selectable
Task test on that layout
Page hidden for 2 minutes, then session ended
Went to compare prices
Survey or support questions
Validation message appeared after input
Typed a wrong postcode
Validation error event by message
Clarity's flags need the same care. Its definition of dead clicks names broken elements, high latency requests and misleading UX as possible causes. The flag tells you where to look. It doesn't choose among them.
The replay has limits too. Clarity reconstructs sessions from HTML and user actions, so it isn't video. The player documentation says recordings can look broken when CSS, fonts or images can't be located, and that third-party iframes and canvas elements aren't captured. A broken layout in replay is therefore a reason to check the live page, not a finding. Inference: a problem inside a hosted payment iframe won't be visible at all.
Use the full replay for the sample. Highlights filter out less significant clicks, and generated summaries can be wrong. Microsoft warns that its generative models can misinterpret or produce incorrect information. A summary can help triage, but each claim needs checking against the timeline.
Keep notes another reviewer can check
One line per observation is enough. Assign the code after the observation, and keep a small code list.
Recording: [Clarity link]
Group: mobile leaver | Week: 2 | Release: 4.12
Time: 00:48
Observed: tapped Continue 3 times, no visible change for 5 s, left at 01:02
Clarity flag: rage click, dead click
Replay limits: page rendered normally, no iframe in this area
Code: continue-no-response
Possible explanation (unverified): slow request or disabled button
Next check: reproduce on same device and browser
Do not copy names, addresses or other visitor details into notes. Link to the recording instead, and remember what the link depends on. Clarity keeps recordings for 30 days. Favorites last up to 9 months, and adding a note in the player automatically makes a recording a favorite. So an in-tool note also extends retention. Keep it for recordings that need it. Labels work for codes, but they are limited to 5 per recording and 50 characters, can't be edited, and last up to 90 days. The written note has to stand on its own after the replay expires.
Decide whether the pattern earns an investigation
After 24 replays, the code tally looks like this:
Group
Replays with continue-no-response
Mobile leavers
7 of 12
Mobile continuers
1 of 6
Desktop leavers
0 of 6
The sample was built to include leavers, so 7 of 12 is not a rate. It only justifies a count. Filter all 2,800 mobile visits by Dead clicks and Clicked text "Continue", and spot-check some matches, because both filters match sessions and may not prove the dead click hit that button.
Mobile visits
Visits
Left
Share left
With the pattern
690
414
60.0%
Without it
2,110
566
26.8%
Total
2,800
980
35.0%
At the lower rate, the first row would lose about 690 × 0.268 = 185 visits. The difference is 414 − 185 = 229, just over half of the 420-visit gap. That sizes the investigation. It doesn't forecast a gain, because visitors struggling for other reasons may also tap more.
Use these conditions for the decision:
Result
Action
Pattern is more frequent in the target group, and the count is large enough to matter
Investigate causes, starting with reproduction
Reproducible defect
Open a bug with steps, device and timestamps
Not reproducible, but the count is large
Add measurement, such as a request failure event, and review again
Also common among people who continue
Treat it as normal friction unless other evidence appears
Seen only in a few memorable replays
Record it and stop
In this example, the first condition holds. The next step is a phone, the same browser and a slowed network, not a redesign. Reproduction separates a defect from a slow response or a misleading control, which the recordings could not do alone.
