A support message says that the save button “sometimes does nothing”. The error log is empty, and a researcher cannot reproduce the problem. A session replay may show the missing context: a validation message appears above the visible part of the page while the person repeatedly presses Save below it.
Session replay reconstructs a recorded visit from captured interactions and interface states. Many web implementations record page structure, changes and events rather than a conventional video of the entire screen. What can be seen depends on the tool, the capture settings and the parts of the experience it supports.
Watch for the sequence around a problem
Replay is useful for investigating a defined event, such as a form error or an abandoned step. Start with a relevant group of sessions and inspect what happened before and after it. Record the observed behaviour separately from the explanation you propose.
Repeated clicking, for example, may suggest that an element is unresponsive, but it does not directly measure frustration. A pause might mean uncertainty, an interruption or that the person has moved to another application. Microsoft’s session-recording documentation provides an example of how replay tools present captured interactions; the labels and signals still require interpretation.
Avoid selecting only the most dramatic recordings. If you need to describe how common a problem is, define the eligible sessions and a defensible review or event-counting method. A compelling clip can demonstrate that something happened without establishing its prevalence.
Understand what the reconstruction leaves out
A replay is not necessarily a faithful recording of everything the person saw. Unsupported elements, masking, network conditions or reconstruction differences can create gaps. It generally does not reveal activity outside the captured site, and it cannot tell you what someone intended merely by showing where they clicked.
A recording from a recruited usability test has a different context: a participant is working through a study with defined arrangements, and may explain their thinking. Replay usually follows naturally occurring visits without that research conversation. Pairing the methods can help test an explanation first suggested by production behaviour.
Design collection around the investigation
Before enabling capture, identify what the study needs and which content should be excluded. Test masking on realistic pages, including error states and dynamically inserted content, rather than assuming a default configuration covers every sensitive element. Microsoft’s masking documentation illustrates why configuration matters and notes that changes affect new recordings rather than retroactively repairing old ones.
Arrange appropriate disclosure, permissions, access limits and retention with the people responsible for the site’s privacy requirements. Masking alone should not be treated as proof that a session is anonymous; the remaining events or account links may still identify someone.
A focused collection of relevant recordings is usually easier to analyse and govern than an indiscriminate archive. Once the suspected problem is understood, test the proposed fix and check the affected outcome, instead of treating the discovery of a vivid replay as the end of the work.