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.

Note

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.