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.
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.
Configure masking via the Mask end-user IP addresses and GPS coordinates option in the data privacy settings.
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.
Only certain headers are captured automatically. You can capture other headers via request attributes.
Query parameters are always masked on display and can also be masked upon storage. To capture parameters explicitly, configure request attributes.
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.
Literals that are part of the WHERE
clause of an SQL statement are replaced with *****
, for example, WHERE userId = '*********'
.
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.
Configure via request attributes.
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
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.
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).
Configure masking via the Mask end-user IP addresses and GPS coordinates option in the data privacy settings.
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.
By default, location capturing is disabled for mobile applications.
Configure masking via the Mask personal data in URIs option in the data privacy settings.
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.
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 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
.
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.
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.
Except background images or images set by CSS.
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
.
—
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 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
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.