Personal data captured by Dynatrace

From monitored environments, Dynatrace may capture end-user data, potentially including personal and confidential information about your end users.

This page identifies where personal data may be captured and how you can limit the capture, storage, and display thereof to help you comply with privacy-related legal requirements, including the California Consumer Privacy Act (CCPA; California, United States), General Data Protection Regulation (GDPR; European Union), or Lei Geral de Proteção de Dados (LGPD; Brazil).

Dynatrace masks data according to our three levels of data protection: at capture, at storage, and at display. In the following sections, icons indicate the level of masking applied to each data type that Dynatrace captures.

Captured by default
Captured by default
Not captured by default
Not captured by default
Masked
Masked
Not masked
Not masked
Masking preferences can be configured; masked by default
Masking preferences can be configured; masked by default
Masking preferences can be configured; not masked by default
Masking preferences can be configured; not masked by default
Masking is dependent on the configuration set during capture and storage
Masking is dependent on the configuration set during capture and storage
Masking preferences are set according to end-user permission
Masking preferences are set according to end-user permission

Service request monitoring

Dynatrace captures the most important data points of incoming requests as well as the web requests of end-users of your application (that is, service requests). URLs, client IPs, and certain HTTP header fields are captured automatically.

You can configure global privacy settings to mask client IP addresses, URIs, and HTTP post parameters.

Data type

Default

Masking at capture

Masking at storage

Masking at display

Client IP addresses1

Captured by default

Masking preferences can be configured; masked by default

Masking preferences can be configured; masked by default

Masking preferences are set according to end-user permission

URIs2

Captured by default

Masking preferences can be configured; not masked by default

Masking preferences can be configured; not masked by default

Masking is dependent on the configuration set during capture and storage

HTTP headers2, 3

Captured by default

Not masked

Masking preferences can be configured; not masked by default

Masking preferences are set according to end-user permission

HTTP post parameters2

Not captured by default

Not masked

Masking preferences can be configured; not masked by default

Masking preferences are set according to end-user permission

URL query parameters2, 4

Captured by default

Masking preferences can be configured; not masked by default

Masking preferences can be configured; not masked by default

Masking is dependent on the configuration set during capture and storage

Exception messages2, 5

Captured by default

Masking preferences can be configured; not masked by default

Masking preferences can be configured; not masked by default

Masking preferences are set according to end-user permission

SQL literals6

Captured by default

Masked

Masked

Masked

SQL bind variables7

Not captured by default

Not masked

Not masked

Masking preferences are set according to end-user permission

Method arguments / return values8

Not captured by default

Not masked

Not masked

Masking preferences are set according to end-user permission

1

Configure masking via the Mask end-user IP addresses and GPS coordinates option in the data privacy settings.

2

Configure masking at capture via the OneAgent-side masking option and masking at storage via the Mask personal data in URIs option in the data privacy settings.

3

Only certain headers are captured automatically. You can capture other headers via request attributes.

4

Query parameters are always masked on display and can also be masked upon storage. To capture parameters explicitly, configure request attributes.

5

To avoid capturing certain exceptions, go to Settings > Server-side service monitoring > Deep monitoring, expand the Exclude noisy and unnecessary exceptions section, and add the required exclusion rules.

6

Literals that are part of the WHERE clause of an SQL statement are replaced with *****, for example, WHERE userId = '*********'.

7

Bind variables support availability depends on your deployment and license. To learn how to start capturing SQL bind values, see Support for SQL bind variables. SQL bind values are replaced with *****. Only users who have permission to view a specific entity or management zone can view unmasked bind values within that entity or zone.

8

Configure via request attributes.

OpenTelemetry attributes for distributed tracing

Dynatrace automatically captures all OpenTracing and OpenTelemetry attributes, but it only stores attributes that are not blocked. See Dynatrace configuration.

Data type

Default

Masking at capture

Masking at storage

Masking at display

Non-blocked attributes

Captured by default

Not masked

Not masked

Masking preferences are set according to end-user permission

Real User Monitoring (RUM)

With Dynatrace Real User Monitoring, you can understand your customers better by accessing performance analysis in real time. This includes all performed user actions and how their impact on performance.

To allow performance analysis based on geographical regions, Dynatrace captures IP addresses and GPS coordinates, which are masked by default. To mask user actions and URIs, configure the global privacy settings. Dynatrace can also detect returning users by storing a randomly generated ID (a user tag) in each user's browser or on their device; this kind of user tagging is not enabled by default.

Data type

Default

Masking at capture

Masking at storage

Masking at display

1

User actions contain a name, a set of timings, and metadata.
Web applications Configure masking via the Mask user actions (web applications only) option in the data privacy settings. You can also create custom user action names.
Mobile applications Configure masking via a special masking property or set action naming and extraction rules (mobile application settings > Naming rules).

2

Configure masking via the Mask end-user IP addresses and GPS coordinates option in the data privacy settings.

3

Dynatrace looks for personal data such as IP addresses, UUIDs, payment card numbers, emails, and other identifiable IDs. However, there might be other personal data or individual characters that Dynatrace isn't able to detect automatically. To mask the URL on display, use custom names for user actions, resource grouping, and naming.

4

By default, location capturing is disabled for mobile applications.

5

Configure masking via the Mask personal data in URIs option in the data privacy settings.

6

Web applications You can set up user tagging using either the RUM JavaScript API or your application's page metadata.
Mobile applications Leverage a variant of a "user tagging" method to add a user tag to a session; check the corresponding documentation for more information.

7

Session and action properties for web, mobile, and custom applications need to be explicitly defined and contain whatever the selected underlying data sources propagated them with.

You can also use the following settings to control how personal data is captured when RUM is enabled for your applications.

Log Monitoring

Log Monitoring is an optional feature that is enabled by default. You can use it to directly access the log content of all your system's mission-critical processes, search for specific log messages, and store all logs centrally.

Log files can include user names, email addresses, URL parameters, and other information that you might not want to disclose. By default, nothing is masked, but Log Monitoring offers the ability to mask sensitive information in the logs. You define the masking rules, so any data can be replaced with an SHA-1 hash or a fixed phrase, for example, *****, #######, MASKED, or Last name.

Data type
Masking at Dynatrace log processing
Masking at OneAgent configuration
Log file content
Masking preferences can be configured; not masked by default
Masking preferences can be configured; not masked by default

Session Replay

Session Replay is an optional feature that is turned off by default. You can enable Session Replay to capture and visually replay users' complete digital interactions with your application.

  • For web applications, Session Replay captures all HTML source code and the mutations that are originated by user interactions. It also captures all user interactions obtained through form fields, attributes, content, and interactions such as mouse movement and scrolling.
  • For mobile applications, Session Replay is available only for those sessions that end in a crash. To visually recreate the end user's experience with your app before a crash, Session Replay captures screenshots and events from the monitored app.

Data type

Masking at capture

Masking at storage

Masking at display

Password form fields

Masked

Masked

Masked

User input1
Text1
Images1, 2
Attributes1

Masking preferences can be configured; masked by default

Masking is dependent on the configuration set during capture and storage

Masking is dependent on the configuration set during capture and storage

Interactions3

Masking preferences can be configured; not masked by default

Masking is dependent on the configuration set during capture and storage

Masking is dependent on the configuration set during capture and storage

1

Web applications Configure in the application masking settings or by adding the data-dtrum-mask attribute to the required element in the application code. For details, see Configure Session Replay | Masking. User input and text are replaced with *** or 000. Only alphanumeric characters are replaced; format characters such as periods, commas, and colons are not masked. Attributes values are replaced with ***. Images are replaced with a placeholder image.
Mobile applications Configure in the application code for iOS and Android. User input and text are replaced with ***** in the Session Replay timeline and with black boxes in the screenshots. All characters are masked. Images are replaced with a black box.

2

Except background images or images set by CSS.

3

Web applications Configure using the Block list option in the application masking settings.
Mobile applications Not possible to mask interactions.

You can also use the following settings to control how personal data is captured when Session Replay is enabled for your web and mobile applications.

Application type

Option name

Description

Default

Web

Use to record a particular part of a session or to implement end-user permission for session recording. When this mode is on, Session Replay is disabled until the dtrum.enableSessionReplay(ignoreCostControl: boolean) method is called.

Disabled

Mobile

Opt-in mode: permission to record replays of crashes

Use to implement end-user permission for session recording. If a user allowed you to record replays of crashes via Session Replay on crashes:

iOS: Set privacyConfig.crashReplayOptedIn to true/YES.
Android: Set .withCrashReplayOptedIn to true.

Session Replay - Session Replay opt-in mode for mobile apps

Web

Use this setting to exclude particular pages from session recording.

Web

Enable this feature if you want to comply with the "Do Not Track" setting that your users can turn on in their browsers.If you select Turn Real User Monitoring off for "Do Not Track"-enabled browsers, Session Replay is disabled when the "Do Not Track" setting is detected in your users' browsers.

Comply with 'Do Not Track' browser settings — Capture anonymous user sessions for "Do Not Track"-enabled browsers

Web
Mobile

Use the Replay sessions with masking and Replay sessions without masking permissions to control who has access to session recordings with and without masking.

Replay sessions with masking permission is enabled for all users

OneAgent diagnostics

OneAgent diagnostics is an optional feature that enables you to collect and analyze support archives for anomalies.

Support archives are created by Dynatrace OneAgent and contain OneAgent log and configuration files as well as specific data from monitored hosts and processes, for example, process names and identification numbers. OneAgent log files may contain personal data, for example, as part of a stack trace.

To comply with regional data protection and privacy regulations, Dynatrace does the following:

  • Masks some personal data before storing a support archive in Cassandra and uploading it to an AWS S3 bucket. For example, IBANs and URI credentials are replaced with <masked>. However, some personal data may not be masked.

  • Writes audit log messages when support archives are created, analyzed, accessed, and deleted to ensure transparency in the use of support archives.

  • Provides access to OneAgent support archives only to users that have the View sensitive request data environment permission.

  • Automatically deletes all diagnostic data 30 days after its collection.

    This applies to the data in your Dynatrace environment. You can also choose to delete collected diagnostic data earlier.

Data type

Masking at capture

Masking at storage

Masking at display

OneAgent log and config files

Not masked

Masked

Masked

Log sharing

The shareLogsFile API allows you to share locally stored log files via an iOS sharing sheet (UIActivityViewController). This feature requires the DTXWriteLogsToFile flag to be set to true.

This feature allows logs to be shared directly from the device without requiring access to Xcode for log extraction. It is not intended for use in production applications.

The shareLogsFile API is not available on tvOS.