You can configure monitoring consumption and data privacy settings for Session Replay. The following sections describe all possible configuration options:
Dynatrace has introduced several Session Replay configuration settings that you should use to protect your customers' personal information. Before enabling Session Replay and proceeding with the privacy configuration settings explained on this page, ensure that your organization has taken all other necessary steps to protect your customers' data.
The ability to replay recorded user sessions, with or without playback masking settings, is permission controlled. The Replay sessions with masking and Replay sessions without masking permissions are available at the environment and management-zone level.
After you enable Session Replay, all user sessions analyzed with RUM are also recorded with Session Replay. However, you might want to limit the number of sessions recorded with Session Replay to reduce the volume of data that this feature generates. To do that, configure the cost and traffic control setting.
To limit the number of sessions recorded with Session Replay
To determine the actual percentage of user sessions recorded with Session Replay, you should consider the cost and traffic control for RUM setting defined for your application, which is the overall percentage of user sessions to be analyzed with RUM.
Use the following formula to calculate the actual percentage of sessions recorded with Session Replay:
Actual percentage of sessions recorded with SR = cost and traffic control for RUM × cost and traffic control for Session Replay
When you have several applications and a user switches from one application to another, Dynatrace creates only one user session, with all the user activity recorded in the context of that session. Such a session is attributed to all the applications that the user visited.
To determine whether a multi-application session should be recorded with Session Replay, Dynatrace uses the cost and traffic control configuration of the application that the user entered first.
For example, suppose that the cost and traffic for Session Replay is set to 1%
for application A and 100%
for application B. When the user first enters application A and then switches to application B, Dynatrace uses the 1%
value to determine whether to record the session with Session Replay. This might result in a smaller or greater percentage of sessions recorded with Session Replay compared to the configured values of the cost and traffic control setting.
Session Replay opt-in mode gives you the freedom to decide which parts of a user session must be recorded and when recording is permitted to begin. For example, you may choose to record user sessions in the following cases:
This mechanism enables you to implement end-user permission for session recording.
When you enable Session Replay opt-in mode for your web application, recording of the active user session begins only after you invoke the enableSessionReplay(ignoreCostControl: boolean)
method on the dtrum
global object. The dtrum
global object is available following auto-injection of the RUM JavaScript.
This command starts session recording. Session Replay remains active, and recording begins automatically on all subsequent pages visited during the same session or until dtrum.disableSessionReplay()
is called.
The dtrum.enableSessionReplay(ignoreCostControl: boolean)
method includes the ignoreCostControl
parameter, which you can use to record certain user sessions by disregarding the value in the Cost and traffic control section of your application settings.
If Real User Monitoring opt-in mode is enabled, Real User Monitoring must be enabled before you can enable Session Replay, for example:
dtrum.enable();
dtrum.enableSessionReplay(true);
Consider the following scenario. As an application owner, you want to record all user sessions that include Page 2 through Page 5 of your application. Session activities involving Page 1 or Page 6 of your application are to be excluded from recording. The following diagram illustrates where the dtrum.enableSessionReplay(ignoreCostControl: boolean)
and dtrum.disableSessionReplay()
methods are required in the sequence.
In such cases, you can display a consent banner to enable session recording when the user lands on Page 2 (see the callout at the bottom of the following image). When the user selects Accept to allow session recording, the application responds by invoking the dtrum.enableSessionReplay(ignoreCostControl: boolean)
method and recording the session.
You can use a cookie in your application to record user content history within the browser. The content of this cookie is checked during each session to determine if the consent banner must be displayed. For example, if the cookie that stores the consent is named sessionReplayConsent
, the application flow would be something like this:
sessionReplayConsent
cookie.true
, the dtrum.enableSessionReplay(ignoreCostControl: boolean)
call is invoked.false
, the consent banner is displayed.dtrum.enableSessionReplay(ignoreCostControl: boolean)
call is invoked.sessionReplayConsent
cookie.With this cookie, Session Replay continues to remain active until Page 5 of the application.
Once the user leaves Page 5, you can use the dtrum.disableSessionReplay()
method to stop recording the session. Then, you must remove the cookie that has been used to store the consent.
You can use the JavaScript methods used for enabling and disabling Session Replay without displaying a banner to obtain consent. For example, if you wish to record a session each time any user logs in, you can use the dtrum.enableSessionReplay(ignoreCostControl: boolean)
method to start recording and the dtrum.disableSessionReplay()
method to stop recording following successful logout. This gives you complete control over the start and stop of Session Replay.
Session Replay opt-in mode is disabled by default.
To enable Session Replay opt-in mode
With these configuration settings, Session Replay is inactive in your end users' browsers, and sessions are not recorded until the dtrum.enableSessionReplay(ignoreCostControl: boolean)
method is called from the application.
If you choose not to Enable opt-in mode for Session Replay, all user sessions are recorded from the beginning until dtrum.disableSessionReplay()
is called from the application.
URL exclusion is applicable to pages and views. If you want to exclude a page from Session Replay recording, define the regular expression that should be used to match against the specific page URL. You can configure rules for individual webpages, entire websites, and single-page applications.
To exclude pages from recording
Go to Web.
Select the application that you want to configure.
In the upper-right corner of the application overview page, select More (…) > Edit.
From the application settings, select General settings > Data privacy > Session Replay.
Under URL exclusion, select Add exclusion rule.
Enter a regular expression that matches the page URL, and then select Add rule.
Session Replay records every user interaction. Therefore, protecting confidential user data by masking is of utmost importance. Masking settings give you options to protect confidential user data when recording and playing back sessions. You can specify separate masking rules for recording sessions and, additionally, for playing back captured sessions, enabling you to apply layers of masking controlled by user permissions.
Session Replay implements masking functionality that ensures that private user information is either not captured at the time of recording or masked at the time of session playback.
The masking option masks only alphanumeric characters; format characters such as periods, commas, and colons are not masked. Therefore, when user sessions are played back, you can still validate the format of the content without viewing the actual information.
As an example, consider an email address field on a typical web form. The user enters their email address, as shown below:
Session Replay masks this data and displays asterisks in place of the nonnumeric characters:
The masked data—displayed in the replayed session as asterisks (*****
) for nonnumeric input or as zeros (0000
) for numeric input—either never leaves the client browser (masked at recording) or is captured but masked during playback. Note that playing back captured sessions is permission controlled.
Session Replay provides two options for configuring content masking.
data-dtrum-mask
attribute The data-dtrum-mask
attribute requires a change in the application code and is secure by design. It allows you to consider the elements that can contain confidential information at the design and implementation stages. The recorder automatically detects and masks the content (text, input values, and attributes values) and interactions (cursor movements and scrolls) in the node that contains the attribute as well as its descendants.
The application code must be modified to incorporate the data-dtrum-mask
attribute.
The page for configuring Session Replay settings in Dynatrace allows a more customized approach. You can change the configuration to suit your session-recording requirements. Also, there's no need to change the application code if you go with this option.
This settings page also provides masking options that you can use to hide interactions with specific elements that might inadvertently reveal confidential end-user information. For example, consider a list that provides multiple options for responding to a form question about the user's religion or gender. Even with the text masked, others would still be able to deduce the end user's response by seeing the selected option.
To configure Session Replay masking
Session Replay predefined masking options are available for both recording and playback:
You can define masking rules for session recording and session playback.
Playback masking rules are meant to provide an additional layer of masking over recording masking rules. Playback masking settings cannot be less restrictive than recording masking settings.
You can use user permissions to decide whether to allow session playback with or without playback masking rules in effect.
The following predefined masking options can be used to restrict capturing and playing back personal and confidential end-user data:
Mask user input is the default masking option starting with Dynatrace version 1.262. Previously, the default option was Mask all.
The Mask all, Mask user input, and Allow list options do not hide user interactions with elements. With the Block list option, you can decide if you want to hide user interactions with masked elements.
With Dynatrace Session Replay, stylesheets are captured and stored during user session recording. You don't have to keep your CSS files at a publicly accessible location, mark the resources as modified, or give permissions to a process that can access the protected stylesheets. It's an entirely automated process that ensures that resources are captured and made available for future replay.
Resource capture for Session Replay is enabled by default.
To enable and configure resource capture
Go to Web.
Select the application that you want to configure.
In the upper-right corner of the application overview page, select More (…) > Edit.
From the application settings, select Capturing > Resource capture for Session Replay.
Turn on Enable resource capture.
optional To avoid capturing resources for certain pages, select Add exclusion rule, enter a regular expression, and then select Add rule.
The exclusion rules are processed as follows.
If a resource hasn't been captured or is unavailable in the Dynatrace resource storage, this resource is retrieved from the original source.
Images and fonts aren't captured. During session playback, they're retrieved from the original location, so certain restrictions apply. To enhance Session Replay playback, use the Session Replay browser extension. To get started, see What does the Session Replay browser extension do and how do I install it?.
Dynatrace doesn't capture a resource that is bigger than 3 MB.
The default retention time for captured resources is 35 days.
Dynatrace captures resources for up to 0.1% of user sessions recorded with Session Replay. This is usually enough to properly replay user sessions, as a resource captured for one session is reused for all other sessions. However, capturing all resources for a low-traffic application might take some time.
See the formula and example below to calculate the number of user sessions for which Dynatrace captures resources.
Sessions with captured resources = Total sessions × RUM cost and traffic control × SR cost and traffic control × 0.1%
In our example, resources are captured for 50 user sessions (1,000,000 × 50% × 10% × 0.1% = 50).
Use the Replay sessions with masking and Replay sessions without masking permissions to control who has access to session recordings. For more details, see Manage user groups and permissions.
The ability to view and play back user sessions is further protected by management zones. If a user session traverses applications within different management zones, Dynatrace users with Session Replay permissions may only view those parts of the session associated with applications in the management zones that they have access to. For details, check Management zones.
Around 100 kB of data is generated for every minute of a session and around 500 kB of storage is consumed by a fully recorded session.
No. Session volume depends on a variety of factors, including the application size, session duration, and users' interactivity with the application.
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 in 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 takes place 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 a low impact on the UI thread, which impacts user experience. Most Session Replay tasks, including an efficient compression algorithm, are executed by a worker thread that runs in the background and doesn't interfere with the user interface.
Recording masking rules are transmitted to the client. This ensures that confidential data does not leave the client browser by default. Masking settings for recording as well as playback are configurable.
The Session Replay browser extension allows proxy loading of resources when replaying a session. You can use the extension to enhance Session Replay playback, for example in the following cases:
The extension can be installed from the Chrome Web Store: Session Replay browser extension
Privacy must be built into applications by design, implemented from the beginning when an application is created. Any feature that involves the processing of private data or non-functional requirements as relevant dimensions should be evaluated for data privacy risk early on. Dynatrace recommends that user-confidential elements and input fields be flagged. For instance, if Session Replay detects an HTML attribute, such as data-dtrum-mask
, it automatically masks its data.
We recommend that you start with the Mask all option and then gradually tweak your settings if you think some of the blocked elements can be safely allowed for display.
If you do record some sensitive user data or your application contains sensitive label text, you can use more restrictive playback masking rules to limit what's displayed at the time of playback. And you can use user permissions to determine which users can replay sessions with or without playback masking rules applied.
Following any accidental display of confidential data, once you configure the masking rules correctly, Session Replay applies the latest masking configuration to all recorded sessions, including those that were recorded before the correct masking rules were implemented. Updated masking rules are applied at the time of playback, and users who have permission to replay sessions are not able to view masked user data. Note that playback masking rules are ignored for those users who have permission to replay sessions without masking.
Use the Block list approach and remove all the predefined rules.
Mask all is the best masking option for testing Session Replay with no risk of exposing confidential user data. This option is also handy when using Session Replay for troubleshooting and you want to see how the user interacts with the controls of your application.
On the user session details page, the Session Replay timeline shows both Real User Monitoring (RUM) and Session Replay events.
When you replay a user session, you might notice that even though the timeline shows all the user actions and events, the Session Replay player skips some of the events and jumps to the end of the session. If you're not seeing the Session Replay data corresponding to all the events on the timeline, this is usually because there is no Session Replay data available for this part of the session.
The following are the most common reasons for partially missing Session Replay data.