What personal data is captured by Dynatrace?

Dynatrace captures a lot of end-user data from monitored environments. Based on your license type and configuration, Dynatrace can capture both real-user traffic (user actions, captured directly in end-user browsers) and service-side traffic (web requests and other communications that may include personal data).

This page provides information about what personal data types Dynatrace collects (and why) for both Dynatrace Real User Monitoring (RUM) and server-side service monitoring. Here you'll also find information about how sensitive end-user data can be protected, including options for capturing such data by default or excluding it from capture.

Dynatrace Real User Monitoring (RUM)

Dynatrace helps you to improve performance and to both analyze and improve the user experience of your web applications and mobile apps. This includes automatic discovery of client errors and capabilities that detect the root causes of such errors in conjunction with Dynatrace OneAgent. Dynatrace does this by collecting data from the end users of your applications. This is done using client-side JavaScript or the OneAgent for Mobile SDK for native mobile apps.

What data is captured when using Dynatrace RUM?

Dynatrace captures the user experience of each end-user interaction with your application (for example, button clicks and page loads) that triggers a server-side web request. Such "user actions" are named based on the triggered web request URL, but the naming rules can be changed so that each user action is named based on the control that is clicked (for example, Click on Login). For each user action, Dynatrace captures timings as well as the URLs of all web requests that were sent to backend services and the URLs of all related assets, such as images, CSS, and JavaScript files.

Dynatrace combines all subsequent user actions into sessions. This enables you to understand how each user navigates through your application. Along with session data, Dynatrace also stores masked IP addresses to allow performance analysis based on geographic regions. Dynatrace processes full IP addresses but masks them before performing geolocation lookups or storing the values in a database.

Dynatrace can detect recurring users by storing a randomly generated ID in each user's browser or on their device. By default, such user tracking is not enabled.

In addition to the above mentioned features that are available out-of-the box, it's also possible to report additional strings to tag user actions and sessions for deeper analytics use-cases. Such tags may include a user name or other personal data. No such tags are configured by default.

Service request monitoring

Dynatrace helps you to improve the performance of your applications, it also enables you to analyze problems that occur in production in a timely manner. This is done via Dynatrace OneAgent.

What data is captured by OneAgent during service request monitoring?

Dynatrace captures the most important data points of incoming requests and, specifically, the web requests of end-users in your application. These are called service requests. By default, each service requests is named based on the triggered web request URL, but this naming rule can be changed so that service requests are named based on their business value.

For this purpose, Dynatrace automatically captures the URL, the client IP, and certain HTTP header fields.

In addition to the above mentioned features that are available out-of-the box, it's possible to report additional data to categorize requests via request attributes, to allow deeper analysis and enhance the capability of request naming rules. This is configurable at the user level.

Log Analytics

With Dynatrace Log Analytics, you gain direct access to the log content of all your system's mission-critical processes. It's easy to search for specific log messages that you're interested in. Log content can be filtered based on keywords or timeframe. You can even analyze multiple log files simultaneously—even when log files are stored across multiple hosts.

Most significantly, Dynatrace artificial intelligence automatically correlates relevant log messages with any problems that it detects in your environment. Relevant log messages that are associated with problems are then factored into problem root-cause analysis.

What data is captured when using Log Analytics?

Log Analytics enables you to store all logs centrally within external storage. This makes log data available independent of log files themselves. This can be beneficial in the following situations:

  • Short log-retention periods
  • Volatile log storage
  • Legal requirements for keeping logs archived centrally for long time periods

For Dynatrace SaaS customers, log files are stored in Amazon Elastic File System encrypted volume in the zone where your Dynatrace environment resides. Your log data may contain personal data. Specific log messages may include user names, email addresses, URL parameters, and other information that you may not want to disclose. Log Analytics provides the ability to mask any information by modifying the configuration file of each OneAgent that handles information you consider to be sensitive.

How Dynatrace protects personal data

Depending on your environment setup and data-privacy settings, some captured data may be protected by law or considered sensitive for other reasons. In such instances, you must take extra precautions to protect your customers' private data.

Dynatrace has 3 levels of protection in place concerning personal data.

  • Scrubbing of data at the point of capture: In this case the data in question don't leave the monitored process or the end user's browser.
  • Scrubbing of data prior to storage: In this case the data in question are processed by Dynatrace to allow for better analysis, but the original data is scrubbed prior to storage. Scrubbed data portions are replaced with the string <masked>.
  • Masking of data on display: In this case data is stored but only presented to users who have the View sensitive request data permission. All other users will see that the data point exists but the personal data is masked out with *****.

Protect personal data by not capturing it

Dynatrace automatically masks certain data points at the point of capture. This happens within the application or browser (such data never leaves the application or browser). Masked values are replaced with ***.

  • Literals and numbers that are part of the where clause of a SQL statement
  • Bind parameters of a SQL statement
  • URL query parameters in exception messages

Protect personal data by not storing it

If your organization captures personal end-user data that is subject to GDPR regulations, go to Settings > Preferences > Data privacy and enable the data masking option. This settings page contains several configuration flags that allow you to enable proper masking of captured data.

Masking of IP addresses and GPS coordinates

Dynatrace captures IP addresses of end users to determine the region from which they access your application.

Once enabled, IP address masking sets the last octet of monitored IPv4 addresses and the last 80 bits of IPv6 addresses to zeroes. GPS coordinates are rounded up to to 1 decimal place (~10km). This masking occurs on the Dynatrace cluster prior to storage. Full IP addresses are never written to disk. Location lookups are made using anonymized IP addresses and GPS coordinates.

Masking of personal data in URLs

Dynatrace captures the full URIs of requests that are sent from browsers (mobile and desktop) and requests that are sent and received within monitored server-side processes.

Once enabled, Dynatrace will

  • Automatically detect UUIDs, IP addresses, and other IDs in the URL path and replace these parts with the string <masked>.
  • Replace query parameter values with the string <masked>.

Masking of user action names (Web applications only)

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:

  • User event type (for example click on..., loading of page..., or key press on...)
  • Title, caption, label, value, ID, className, or other available property of the related HTML element (for example, image, button, checkbox, or text input field).

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.html
  • keypress on Feedback on page /contact.html
  • touch on Homescreen of page /list.jsf

In rare circumstances however confidential data (for example, email addresses, usernames, or account numbers) may be unintentionally included in user action names because the confidential data is included in an HTML element label, attribute, or other value (for example, click on my Account Number: 1231231). If such confidential data appears in your application’s user action names, you should enable User action name masking. 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 would change to:

  • click on INPUT on page /search.html
  • keypress on TEXTAREA on page /contact.html
  • touch on DIV of page /list.jsf

Protect personal data by not displaying it

Dynatrace automatically considers certain data points it captures as sensitive and only displays them to users who have the View sensitive request data permission. All other users will see that the data point exists but the personal data is masked out with *****. Thus the data is protected from view by unauthorized personal.

Personal data types

The following data types are considered sensitive and are masked from display:

  • Requests attributes that are marked as confidential.
  • Client IP addresses
  • Exception messages
  • URL query parameters
  • HTTP Headers
  • HTTP Post parameters
  • Original captured method argument values (the resulting request attribute is treated separately)

Mark request attributes as confidential

Dynatrace allows you to decide whether a request attribute should be treated as confidential or not. For this and other obvious reasons, users who are authorized to define request attributes must have the Configure capture of personal data permission. For complete details, see How do I configure Dynatrace to protect personal data?

Summary of personal data capture scenarios

The table below provides an overview of how data that may include sensitive values may be captured by Dynatrace. Following are definitions of the various scenarios:

  • May contain PII data: PII data may be captured, either intentionally or accidentally.
  • Configurable capture: Data capture is configurable. Data may or may not be captured.
  • Captured by default: This data is captured by default.
  • Masked by default: If captured, the data is masked by default.
  • Masking on display: If captured, the data is masked on display by default.
  • Masking on storage: If captured, the data is masked before storage by default.
  • Masking on capture: If the data is captured and masking is enabled, the data is masked upon capture.
Product feature Data being captured May contain PII data Configurable capture Captured by default Masked by default Masking on display Masking on storage Masking on capture Comment
Real User User clicks yes no yes yes no configurable future
Real User URL yes no yes no no configurable future
Real User IP and Location yes no yes yes no configurable future
Server side requests URL yes no yes no no configurable future
Server side requests URL Query parameter yes yes yes yes yes configurable future ³
Server side requests Client IP yes no yes yes yes configurable future
Server side requests HTTP request/response header yes yes only some no yes configurable future ¹
Server side requests HTTP post parameter yes yes no no yes configurable future ²
Server side requests Exception messages yes yes yes no yes no yes
Server side requests Method arguments/return values yes yes no no yes future no ²
Server side requests SQL literals and bind variables yes no no yes no future yes
  1. Only certain headers are captured automatically. All others are only captured when requested by an authorized user (see request attributes). The data that are captured aren't masked by default.
  2. All values are captured when requested by an authorized user (see request attributes)
  3. Query parameters are always confidential (masked on display) and can additionally be masked upon storage. They can be explicitly captured by request attributes, in which case their confidentiality depends on request attribute configuration.