Cookies and client-side storage for RUM and Session Replay
- Latest Dynatrace
- Reference
Both RUM Classic and RUM on the latest Dynatrace rely on HTTP headers, cookies, web storage, and IndexedDB. The headers used are listed in Infrastructure pass-through requirements for RUM. This page describes the cookies, web storage, and IndexedDB entries used.
Cookies, web storage, and IndexedDB are used for the following purposes:
- Aggregation of user sessions
- Identification of recurring users
- Persisting the state of RUM features like cost and traffic control
- Correlation of user actions with their server-side traces in RUM Classic
- Keeping the Session Replay recording consistent across pages
- Caching Session Replay resource capture data to avoid redundant uploads
The data stored in cookies, web storage, and IndexedDB contains no personal or sensitive data. It consists of random IDs, timestamps, boolean flags, configuration, hashes, and cached resources.
Cookies
The following table provides an overview of the cookies used in RUM, RUM Classic, and Session Replay. These are all first-party cookies.
The <environmentID> suffix used in the cookie names is explained in Suffix for cookie names and web storage keys.
The v4 cookie format mentioned in the table consists of key-value pairs, for example v_4_srv_7_sn_4D3133F359A76AB05AAF39691696858A. Don't filter for any of these keys, because they may change.
| Cookie | Structure | Expires | Max size | Purpose |
|---|---|---|---|---|
| v4 cookie format | Session | No set limitation, but usually less than 100 B | Tracks a visit across multiple requests. |
| <serverID>$<randomValue>_<currentMillis> | Session | 58 B | Required for routing RUM beacons; includes session ID for user session aggregation. |
| <URL-encoded action name> | Session | Max number of characters in the URL | Serves as an intermediate storage for page-spanning actions. This cookie is used to save user action names, such as |
| The string | Deleted after a few milliseconds; no expiry date set | Length of the string | Used to determine the top-level domain. |
| <visitorID> | Session, or permanent if user tracking is turned on | 45 B | Contains the visitor ID to correlate sessions. |
| <timestamp>|<timestamp> | Session | 27 B | Stores the session timeout. |
| <viewID> | Session | 20 B | If Session Replay is enabled, |
| v4 cookie format | Session | 81 B | If Session Replay is enabled, stores the required values to keep the recording consistent across pages. |
The dtsrVID cookie exists from RUM JavaScript version 1.325+ to RUM JavaScript version 1.333.
The optional dtSR cookie is available from RUM JavaScript version 1.335+.
Cookies on upgraded environments
Once an environment has been upgraded to Latest Dynatrace, RUM sets the additional first-party cookies described in the table below. To identify and resolve any compatibility issues with your infrastructure before upgrading the environment, you can also upgrade only the RUM cookies.
| Cookie | Structure | Expires | Max size | Purpose |
|---|---|---|---|---|
| v4 cookie format | Session, or two years from the last access if user tracking is turned on | 130 B | Tracks users across multiple sessions. |
| v4 cookie format | Session | No set limitation, but usually less than 150 B. The size grows with the number of involved frontends. | Tracks a session across multiple requests. |
| v4 cookie format | Session | 38 B | Stores the consent state. This is the only cookie that can be stored when the end user has not consented to data collection; see opt-in mode. |
Upgrade RUM cookies
To upgrade RUM cookies for a frontend
-
Go to
Experience Vitals > Overview. -
Select Web to view all web frontends.
-
Select the frontend you want to configure.
-
On the Settings tab, select Open in Settings.
- Go to Collect and capture > Instrumentation > RUM cookies upgrade.
- Turn on Upgrade RUM cookies.
To upgrade RUM cookies for the whole environment
- Navigate to
Settings > Collect and capture > Real User Monitoring > Instrumentation > Web > RUM cookies upgrade. - Turn on Upgrade RUM cookies.
Web storage
RUM, RUM Classic, and Session Replay use both sessionStorage and localStorage. The following table lists the possible entries. Some of them back up cookies, because browsers may evict cookies when a large number are set.
| Key | Storage | Purpose |
|---|---|---|
| Stored in | Backs up the |
|
| Backs up the session ID from the |
|
| Backs up the |
|
| Backs up the |
|
| Backs up the |
|
| Stores the last beacon response, which contains the RUM JavaScript configuration. |
|
| Indicates that persistent values were removed by using the API method |
|
| Stores the severity of the latest "reason for no Session Replay" message and the |
| By default in | Stores the values required to keep the recording consistent across pages when Session Replay is enabled. Exists from RUM JavaScript version 1.335. |
|
| Stores the current tab ID for Session Replay. |
|
| Boolean flag for Session Replay that indicates whether a window was opened programmatically recently. |
Web storage for RUM
When RUM on the latest Dynatrace is enabled, entries are persisted to web storage in addition to the ones described in Web storage. The following table lists the possible entries.
| Key | Storage | Purpose |
|---|---|---|
|
| Stores the current frontend configuration from the beacon response. |
|
| Stores the consent state. This is the only entry that can be stored when the end user has not consented to data collection; see opt-in mode. |
|
| Stores the off state, which turns off the RUM JavaScript temporarily, and the reason it was set. Can be triggered by certain responses from the beacon endpoint, by invalid beacon responses, or by automatic cookie domain detection failures. |
|
| Stores the source context and passes it to the next HTML document during a hard navigation. This allows RUM to add user action source fields. |
|
| Identifies the browser tab. |
|
| Stores the tab load state. |
IndexedDB
Session Replay uses IndexedDB to persist resource capture state across sessions. The following table lists the possible entries.
| Store Name | Purpose |
|---|---|
| When Session Replay is enabled, |
| When Session Replay is enabled, |
Suffix for cookie names and web storage keys
In environments created in Dynatrace version 1.294+, a suffix is added to cookie names and to the keys of certain web storage entries. In the tables above, this suffix is shown as <environmentID>. It prevents interference when different Dynatrace environments have overlapping cookie domains.
If you need the full cookie names to configure your firewalls and other infrastructure, you can retrieve them using the API endpoint RUM cookie names API - GET cookie names. To find them in the UI
-
Go to
Experience Vitals > Overview. -
Select Web to view all web frontends.
-
Select the frontend you want to configure.
-
On the Settings tab, select Open in Settings.
-
Go to Collect and capture > Instrumentation > Cookies. If there's no Instrumentation entry, go to Collect and capture > Injection > Cookie instead.
-
Find the cookie names at the top of the section.
Allow users to opt in to cookies, web storage, and IndexedDB
Dynatrace cookies, web storage, and IndexedDB are required for Real User Monitoring to work. By default, Dynatrace creates them automatically. To protect your end users' privacy, you can give them the option to accept or decline cookies, web storage, and monitoring in general. This is done through opt-in mode.
When opt-in mode is enabled, monitoring is disabled by default. As a result, Dynatrace sets no cookies, does not use web storage, and does not write to IndexedDB. The only exception is the consent state dtCM_<environmentID>. After an end user accepts your data privacy policy, your application must call dtrum.enable() through the JavaScript API to start capturing data. Dynatrace creates cookies and writes to web storage and IndexedDB only after this method is called.
For details on enabling opt-in mode, see Configure data privacy settings for web frontends.
If users do not opt in, monitoring remains disabled.
Configure cookie attributes
Dynatrace RUM does not support the HttpOnly attribute. Since HttpOnly cookies are inaccessible to JavaScript, the RUM JavaScript cannot read or modify them. Ensure that your infrastructure doesn't add the HttpOnly attribute, because this will break monitoring.
If your company's security policy requires the Secure and SameSite cookie attributes, you need to configure RUM to set them, since they aren't set by default; see Configure RUM cookie attributes.