Session Replay is a powerful tool that can modernize your Digital Experience Monitoring (DEM) strategy. You can use it to capture and visually replay the complete digital experience of every user.
You can record all customer interactions with your web application and replay each click and action in a movie-like experience. Session Replay also makes it easy for your QA teams to reproduce production issues which can be used by your developers to bridge the gap between code and user experience.
Session Replay helps identify errors that should be fixed immediately and other problems such as malformed pages and infinite spinners.
Session Replay can also be used to identify and analyze areas of struggle in your application and improve its overall usability.
Uses for Session Replay
With Session Replay, you can drill down further into the details of detected errors:
- Understand the exact user actions that led to an error
- Understand the severity of the problem and its effect on user experience
- Observe the customer impact by replaying and viewing a session (in cases where the problem isn't obvious)
Developers can use Session Replay as a means to view, analyze, reproduce, and fix errors.
For the purpose of error drill-down, it isn't necessary to have all sessions recorded. You could use cost and traffic control to record only a subset of sessions. If the error to be analyzed is not too sporadic, it can be detected even if only 20% of sessions are recorded.
The default data retention time frame of 35 days is applied to these sessions.
Because Session Replay is the best way to demonstrate what the user actually did, it provides the means to resolve customer complaints. Use Session Replay to:
- See the exact journey of the customer on your application
- Identify the exact problem faced by the user
- Provide correct instructions
To resolve customer complaints, it’s ideal that all sessions be recorded. However, to save storage space, it's recommended that a lower retention time be set.
Session Replay can also be used to detect and analyze the following issues:
- The UX design is not intuitive enough
- The process flow is too complicated, and users tend to leave your application midway
- The app is slow, and the user clicks repeatedly to move on to the next screen
- The app isn't working as expected on all browsers
- The mobile web apps prompt the user to change the orientation of the phone, but the user doesn't understand the prompt
The default data retention time is applied to these sessions.
Session Replay is compatible with page-based applications, single-page applications, and applications that use IFrames. However, certain restrictions apply.
On average, around 100 KB of data is generated for every minute of a session. Over trials and early-adopter programs, we have found that an average session consumes around 500 KB of storage.
No. Session volume is dependent on a variety of factors including the size of the application HTML, the duration of the session, and the interactivity of the users with the application.
On average, session sizes vary from 100 KB to over 1 MB.
No. To record sessions, Session Replay monitors changes on the DOM tree of a web application. Every visual change of a web application has a corresponding change in the underlying DOM. Session Replay captures and recreates these changes. Because all of this is text-based data, small session sizes are achieved through compact representation and compression.
Because compression happens on the client side, the bandwidth consumption is the same as the storage consumption: around 100 KB per minute or 500 KB per session.
This is advantageous for recording sessions from users on mobile devices with limited internet data or with connections that have limited bandwidth.
Session Replay was designed to have low impact on the UI thread, which is the one that impacts the user experience. Most Session Replay tasks, including a very efficient algorithm to achieve compression, are executed by a worker thread that doesn't interfere with the user interface and runs in a background thread.
No. All masking rules are transmitted to the client. This ensures that confidential data never leaves the client's browser.