What is session replay? A practical guide to website recordings

How does session replay work?

Many web replay tools record a representation of the page and a timestamped stream of changes and interactions. A player rebuilds that page and applies the events in order. The result looks like a video, but the underlying recording can be event data rather than a screen capture.

TraceUX uses this DOM-event approach with rrweb. The DOM is the browser’s structure for a page: its elements, text, and attributes. Recording changes to that structure helps reconstruct what happened as the visitor moved through the site.

Reconstruction has limits. Missing styles or assets, blocked content, and unsupported embedded elements can make a replay differ from the original experience. Verify a test session on your own site before treating every visual detail as evidence.

What can you learn from a recording?

A recording is useful when you have a specific question. If visitors leave an onboarding form, watch whether they encounter validation errors, search for an explanation, or reach a step they cannot complete. Each observation suggests a different follow-up.

Repeated clicks may mean a control feels unresponsive. They can also reflect ordinary behavior. A cursor movement does not prove where someone looked, and a long pause does not prove confusion. Describe the visible action first, then test the interpretation.

• Navigation: can the visitor find the next step without looping between pages?
• Forms: does an error explain what needs to change and preserve the visitor’s progress?
• Mobile layouts: does a sticky banner cover a control or useful content?
• Technical failures: does the session stop progressing around a browser error?

Session replay vs. website analytics

Analytics helps estimate the size of a problem across visitors. Replay provides detail about individual journeys. Feedback adds what people say they were trying to do. These are complementary sources of evidence, and none gives a complete explanation on its own.

For example, analytics may show fewer successful signups on mobile. A recording might reveal the keyboard covering a submit button. A support message may explain that the visitor thought the form had frozen. Reproduce the issue before choosing a fix.

What should you check before recording?

Decide which pages you need to investigate and which content should be excluded. Test masking with dummy data on account pages, confirmation screens, and error states. Private information can appear in page text and logs as well as form fields.

In TraceUX, form inputs are masked by default, and additional masking and blocking markers let you control page content. You also operate the server and choose retention. Those controls require deliberate configuration; running your own server does not automatically make every captured value appropriate to store.

A simple first session replay review

Start with one task, such as creating an account. Record your own successful attempt and one attempt with a validation error. Check that the replay renders correctly and private content is hidden. Then review a focused group of real journeys for that same task.

Write down the page, timestamp, observed action, and next question. A useful finding sounds like “the error appeared below the visible area after submit,” rather than “users dislike the form.” Make a small change, verify the interaction, and compare completion data after release.