Cookies
DESK Real User Monitoring (RUM) relies on browser cookies to correlate user interactions in the browser, for example user actions, with general page and backend performance metrics.
Cookies are used to:
- Monitor site performance
- Analyze website usage
- Track user behavior
The data stored in cookies is made up of random values, time stamps, and data that are required to correctly identify the applications in your monitored environment. The Real User Monitoring JavaScript library must be able to set and modify these cookies. This means that DESK cookies don't support the HTTPOnly
flag. Cookies must be included with each request so that user actions can be correlated with backend performance.
You can use the Secure
cookie flag, however this leads to loss of visibility into any unencrypted HTTP communication.
DESK cookies
The following table provides an overview of cookie usage in DESK. These are all first-party cookies.
Note: If you use DESK to monitor your own customers' websites, you may re-use the cookie information detailed in the table below for your organization's own cookie policy.
Cookie | Structure | Expires | Max size | Purpose |
---|---|---|---|---|
dtCookie |
<serverID>|<sessionID>|<applicationID>|<applicationState>
or =3=key1=value1=key2=value2=keyN=valueN Possible keys are:
|
session | No set limitation but usually less than 100B | Tracks a visit across multiple requests. |
dtLatC |
<numeric value> | session | 5B | Measures server latency for performance monitoring. |
dtPC |
<serverID>$<randomValue>_<currentMillis>v<randomValue>e<eventCount> | session | 58B | Required to identify proper endpoints for beacon transmission; includes session ID for correlation |
dtSa 1 |
<URL-encoded action name> | session | Max number of characters in the URL | Intermediate store for page-spanning actions. |
dtBw |
<status>_<durationMillis> | session | 13B | Bandwidth measure. |
rxVisitor |
<visitorID> | permanent | 45B | Visitor ID to correlate sessions. |
rxvt |
<timestamp>|<timestamp> | session | 27B | Session timeout. |
1The dtSa
cookie is used to save user action names, such as Click on Login
across different pages. This is required because page loads result in JavaScript code restart and so all contextual information must be stored in cookies.
Cookie opt-out capability
DESK cookies are essential for providing you with all the benefits of Real User Monitoring. If you provide your users with the option to decline the use of these cookies, Real User Monitoring won't work to its full potential.
To provide your end users with a cookie opt-out capability, DESK must be configured appropriately. Usually DESK creates tracking cookies automatically. When using cookie opt-in mode
, DESK RUM tracking is disabled by default and no cookies are created. When an end user accepts your cookie policy (opt-in mode), DESK RUM is enabled by calling dtrum.enable()
within the JavaScript code module. Following this method invocation, DESK tracking cookies are created and RUM is activated.
Note: To configure Cookie opt-out mode please see How do I configure Real User Monitoring for privacy?.
Cookie storage
When a lot of cookies are in use, some browsers delete a few cookies at random. To avoid losing data from such deleted cookies, DESK stores backups of all cookies. When Use persistent cookies for user tracking is enabled, this backup is stored in localstorage
. Otherwise, it's stored in sessionstorage
.
DESK stores backups of the following cookies:
rxVisitor
rxvisitid
rxvt
rxec
Note: The backup of dtCookie
is always stored in sessionStorage
and the backup of ruxitagentjs_<appid or empty>_Store
is always stored in localstorage
.
DESK also uses localStorage
to cache the last monitor beacon response, which contains the configuration for the RUM JavaScript tag.
Secure cookies
DESK allows you to set the Secure cookie
attribute for all cookies that are set by DESK. By applying this attribute (i.e, flag) on the set-cookie
header, you can ensure that the browser sends these cookies only over secure connections.
Note that DESK cookies don't support HTTPOnly. Cookies must be included with each request so that user actions can be correlated with backend performance. If, in such cases, you use the Secure cookie
flag, the flag may lead to loss of visibility into any unencrypted HTTP communication.
To set the Secure cookie flag:
- Select Applications from the navigation menu.
- Select the application for which you want to set the secure cookie flag.
- Click the Browse [...] menu button and select Edit.
- From the Application settings menu, select Advanced setup.
- Scroll to Cookie and header settings and enable the Use the Secure cookie attribute for cookies set by DESK switch.
Note: Before enabling the Secure cookie
flag, ensure that the application is completely served over secure connections.