How AppMon uses cookies
To identify a visit, AppMon uses cookies. Therefore it is a technical necessity that a Webserver Agent set a temporary session cookie; otherwise UEM cannot measure a user's performance experience. This cookie is sent on the first web request and expires when the browser is closed. It is non-persistent and is not used for ad tracking. AppMon sets these first-party cookies for the sole purpose of application performance management, not for tracking a user's purchasing bias or click behavior.
First-party cookies are defined as cookies that are directly used for communication between a website and a user. For example, if you purchase goods in a web shop, the shop uses first-party cookies to identify you and keep track of your shopping cart; you have a direct business relationship with the web shop. The shop needs to know who you are, otherwise you can't pay and the shop can't deliver your purchase to you.
In contrast, third-party cookies are cookies that communicate with other websites, for example advertising services or analytics engines. If a website asked to share your address data with another company, you might not agree to the transaction. Regulations therefore rely on the opt-in concept, in which a user has to explicitly authorize the sharing of their data with a third-party.
AppMon uses only first-party cookies. Real-user metrics are returned securely to their originating URL (the web server behind the URL) and not to a different server in the Cloud that is not under the vendor's control. The visit identification using the first-party cookie is standard technical and business practice.
AppMon cookies
The following table provides an overview of cookie usage in AppMon. These are all first-party cookies.
If you use AppMon 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 | <randomValue> | <encoded application info> | visit | 100B | Technical visit ID for PurePath correlation |
| dtLatC | <numeric value> | visit | 5B | Measures server latency for performance monitoring |
| dtPC | <serverID>$<randomValue>_<currentMillis>v<randomValue> | visit | 54B | Required to identify proper endpoints for beacon transmission; includes visit ID for correlation |
| dtSa1 | <URL-encoded action name> | visit | max URL length | Intermediate store for page-spanning actions |
| dtBw | <status>_<durationMillis> | visit | 13B | Bandwidth measure |
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.
Session storage
AppMon uses sessionStorage to store a backup of dtCookie because certain browsers delete random cookies when too many cookies are used. AppMon sets the dtCookie key.
Local storage
AppMon uses localStorage to cache the last monitor beacon response, which contains the configuration for the real user monitoring JavaScript library. It doesn't store any user-related data in localStorage. The following table gives an overview of the key/value pairs that AppMon writes to local storage.
| Key | Example value | Description |
|---|---|---|
dtagent_<application name>_Store |
OK(nginx) | name=dtagent config=domain%3Ddynatrace.com%7CreportUrl%3D%2Frb_dwypuwjjgx%7CfeatureHash%3D2SVfqr%7ClastModification%3D1494945232091%7CuseNewCookies%3D1%7CdtVersion%3D10119170508093112%7Ctp%3D500%2C50%2C0%2C1%7CagentUri%3D%2Fruxitagentjs_2SVfqr_10119170508093112.js | featureHash=2SVfqr | version= | buildNumber=10119170508093112 | lastModification=1494945232091 | Beacon response. Configuration for the JavaScript code. |