Dynatrace allows you to granularly control what data you would like to capture. Depending on your use cases, you can configure Dynatrace to provide you with the right amount of data from your monitored environments. However, keep in mind that it's your responsibility to protect your customers' personal data while using Dynatrace.
We offer multiple masking layers either configured in the environment-wide settings—which apply to your whole tenant—or more fine-grained configuration for the following monitored entities.
To access the environment-wide data privacy settings
Unless otherwise stated, all settings on the Data privacy page apply to both the data captured from your end users' web browsers and the data captured by OneAgent on the server side.
Besides adjusting settings provided on the Data privacy page, you can also mask logs captured by OneAgent, restrict the view access to personal information as well as mark some request attributes as confidential.
Note that Dynatrace masks data according to our three levels of data protection: at capture, at storage, and at display. In the following sections, the data privacy settings are grouped by these levels of data protection.
With masking at capture, data is masked at first contact with Dynatrace. The original data does not leave the monitored environment.
OneAgent version 1.277+ for URLs
OneAgent version 1.285+ for exception messages
To access this setting, go to Settings > Preferences > Data privacy > OneAgent-side masking.
🔴 Disabled by default
OneAgent can mask sensitive data points at first contact. The configuration is executed directly on OneAgent; the configured data points are not sent to the Dynatrace servers and are no longer available.
Depending on your use cases and data needs, you can decide whether you want to mask the following data points.
You can apply these settings to specific monitored process groups or globally to your whole environment.
OneAgent-side masking settings do not affect the Dynatrace RUM JavaScript. For web applications, use the Mask personal data in URIs option to control sensitive data point masking for URLs.
To enable the benefit of multiple layers of protection, configure the masking at capture settings independently from the masking at storage and masking at display settings. Note that data points masked at capture are no longer available. Additionally applying the masking at storage settings creates a second protection layer that might be beneficial for various compliance frameworks.
In Log Management and Analytics (powered by Grail), you can benefit from fully configurable masking rules for logs captured by OneAgent.
To access this setting, go to Settings > Preferences > Data privacy > IP masking.
🟢 Enabled by default
Dynatrace captures IP addresses and GPS coordinates of end users to determine the region from which they access your application.
With the Mask end-user IP addresses and GPS coordinates option turned on, Dynatrace masks end user IP addresses and GPS coordinates during Real User Monitoring and server-side monitoring. The last octet of monitored IPv4 addresses and the last 80 bits of IPv6 addresses are replaced with zeroes. GPS coordinates are rounded up to 1 decimal place (~10 km). The masking occurs within the application, monitored process, or browser so that the data is already masked before it's sent (data in transit) to the Dynatrace cluster. Location lookups are made using anonymized IP addresses and GPS coordinates.
The Mask end-user IP addresses and GPS coordinates — Mask all IP addresses option is enabled by default for new environments.
For mobile applications, Dynatrace uses the coordinates from the device by using GPS or Wi-Fi. If the application has the permission to use this geolocation information, Dynatrace uses it to calculate the city that is closest to the reported GPS location. If not, Dynatrace uses MaxMind Geo2 Database.
To access this setting, go to Settings > Preferences > Data privacy > General.
🔴 Disabled by default
The Mask user actions (web applications only) option affects Real User Monitoring only for web applications. With this option enabled, Dynatrace uses generic values for user action names.
When Dynatrace detects a user action that triggers a page load or an AJAX/XHR action, it constructs a name for the user action based on:
click on..., loading of page..., or keypress on...In most instances, the default approach to user action naming works well, resulting in user action names such as:
click on "Search" on page /search.htmlkeypress on "Feedback" on page /contact.htmltouch on "Homescreen" of page /list.jsfIn rare circumstances, email addresses, usernames, or other confidential data may be unintentionally included in user action names. This happens when confidential data is included in an HTML element label, attribute, or other value, resulting in user action names such as click on "My Account Number: 1231231". If such confidential data appears in your application's user action names, turn on Mask user actions (web applications only) . This setting replaces specific HTML element names and values with generic HTML element names.
With user action name masking enabled, the user action names listed above appear as:
click on INPUT on page /search.htmlkeypress on TEXTAREA on page /contact.htmltouch on DIV of page /list.jsfTo avoid capturing personal information for user actions in your mobile applications, check the information on mobile user action masking.
When masking at storage is implemented, data is sent to the Dynatrace server for optimal analysis and is masked before it's stored.
To access this setting, go to Settings > Preferences > Data privacy > General.
🔴 Disabled by default
Dynatrace captures full URIs of requests that are sent from desktop and mobile browsers, as well as URIs of requests that are sent and received within monitored server-side processes. URIs may contain personal data, such as a user name, password, or ID.
When Mask personal data in URIs is turned on, Dynatrace detects personal data—emails, IBANs, payment card numbers, IP addresses, UUIDs, and other IDs—in URIs, query strings, headers, exception messages, and data captured for request attributes and replaces this data with the <masked> string (for example, /url?country=Austria&city=Linz changes to /url?country=<masked>&city=<masked> and /account/iban('123456678890') changes to /account/iban('<masked>')). As a result, the personal data is then masked in the distributed trace analysis, error analysis, user action names for RUM, and elsewhere in Dynatrace.
When data is masked at display, it's stored in its original form but is accessible only to the users of your choice.
Dynatrace automatically considers certain data points it captures as confidential and only displays them to users who have the View sensitive request data permission. All other users see that the data point exists, but the personal data is masked out with asterisks *****.
If your organization captures personal user data such as email addresses, IP addresses, or passwords in the course of monitoring, you should restrict view access to this personal data so that only authorized users can view it. Also note that only users with the View sensitive request data permission can override data masking settings.
Note that the following data types are considered confidential and are masked at display:
Request attributes are key-value pairs of metadata that are filterable across all Dynatrace service and distributed traces views.
Dynatrace allows you to decide whether a request attribute should be marked as confidential. To manage request attributes, you must have the Manage capturing of sensitive request data permission.
To access this setting, go to Settings > Preferences > Data privacy > General.
🔴 Disabled by default
To provide your end users with the ability to decide for themselves if their activities should be tracked or not (this is called "cookie opt-out capability"), enable the opt-in mode.
Usually, Dynatrace creates tracking cookies automatically. When Data-collection and opt-in mode is turned on, RUM is disabled and no cookies are created. When an end user accepts your cookie policy, Dynatrace enables RUM and sets the tracking cookies.
To access this setting, go to Settings > Preferences > Data privacy > General.
🟢 Enabled by default
Another technique for protecting end-user privacy is the "Do Not Track" feature. When a user enables this feature, their browser adds the DNT HTTP request header to all outgoing web requests. This header specifies that all user tracking must be disabled.
After you turn on Comply with "Do Not Track" browser settings, you can select between two options:
DNT header is detected, Dynatrace captures RUM data but excludes all personal information that could lead to the identification of the user. The IP address is masked, and no user tag information is sent.
With the User tracking setting enabled, Dynatrace still sets a persistent cookie to detect returning users.
DNT header is detected, Dynatrace doesn't capture any data from browsers that have the "Do Not Track" setting enabled.If you turn off Comply with "Do Not Track" browser settings, Dynatrace ignores the browser's "Do Not Track" setting and the DNT header.
The Comply with "Do Not Track" browser settings — Capture anonymous user sessions for "Do Not Track"-enabled browsers option is enabled by default for all environments and applications.
To access this setting, go to Settings > Preferences > Data privacy > General.
🔴 Disabled by default
The Use persistent cookies for user tracking setting allows you to enable or disable the use of persistent cookies that detect and track returning users.
When turned on, Real User Monitoring sets a persistent cookie in end-user browsers that detects if the browser has been used previously to access your application. When turned off, Dynatrace is no longer able to correlate anonymous user sessions with tagged user sessions, so the Returning vs. new users RUM metric no longer works. Learn how we store this cookie.
User tracking is disabled by default for all newly created applications. Settings for existing applications aren't affected, so you must configure them manually.