Personal data captured by DESK

DESK captures a lot of end-user data from monitored environments. Based on your license type and configuration, DESK 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 DESK collects (and why) for both DESK 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.

DESK Real User Monitoring (RUM)

DESK 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 DESK OneAgent. DESK 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 DESK RUM?

DESK 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, DESK 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.

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

DESK 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.

Session Replay

With DESK Session Replay, you can capture and visually replay the complete digital interaction of users with your application while also ensuring that your organization remains GDPR-compliant. Session Replay offers several configuration settings that can be applied to your application. Configure Session Replay for personal data protection to ensure that your customers' personal data is always protected.

What data is captured during Session Replay?

Session Replay captures all HTML source code and the mutations originated by user interactions. It also captures all user interactions obtained through form fields, attributes, content, and interactions such as input, mouse movements, and scrolls.

Service request monitoring

DESK 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 DESK OneAgent.

What data is captured by OneAgent during service request monitoring?

DESK 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, DESK 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 Monitoring

With DESK Log Monitoring, 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, DESK 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 Monitoring?

Log Monitoring 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 DESK SaaS customers, log files are stored in Amazon Elastic File System encrypted volume in the zone where your DESK 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 Monitoring provides the ability to mask any information by modifying the configuration file of each OneAgent that handles information you consider to be sensitive.

Summary of personal data capture scenarios

The following table provides an overview of how data that may include sensitive values may be captured by DESK. 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 captured	May contain PII data	Configurable capture	Captured by default	Masked by default	Masked at display	Masked at storage	Masked at capture	Comment
Real User	User clicks	yes	no	yes	no	no	configurable	no
Real User	URL	yes	no	yes	no	configurable	configurable	no	⁴
Real User	IP and Location	yes	no	yes	yes	no	configurable	no	⁴
Session Replay	User input	yes	yes	yes	no	yes	yes	yes	⁶
Session Replay	Images	yes	yes	yes	no	yes	yes	yes	⁶
Session Replay	Content	yes	yes	yes	no	yes	yes	yes	⁶
Session Replay	Attributes	yes	yes	yes	no	yes	yes	yes	⁶
Session Replay	Form fields	yes	yes	yes	yes	yes	yes	yes	⁵
Session Replay	Interactions	yes	yes	yes	no	yes	yes	yes	⁶
Server side requests	URL	yes	no	yes	no	no	configurable	no
Server side requests	URL Query parameter	yes	yes	yes	yes	yes	configurable	no	³
Server side requests	Client IP	yes	no	yes	yes	yes	configurable	no
Server side requests	HTTP request/response header	yes	yes	only some	no	yes	configurable	no	¹
Server side requests	HTTP post parameter	yes	yes	no	no	yes	configurable	no	²
Server side requests	Exception messages	yes	yes	yes	no	yes	no	yes
Server side requests	Method arguments/return values	yes	yes	no	no	yes	no	no	²
Server side requests	SQL literals and bind variables	yes	no	no	yes	no	no	yes

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.
All values are captured when requested by an authorized user (see request attributes)
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.
DESK looks for personal data like IP addresses, UUIDs, credit card numbers, emails and other clearly indentifiable IDs. But there might be some other personal data of individual character that DESK isn't able to detect automatically. You can mask the URL on display with custom names for user actions and resource grouping, or naming.
Although password fields are form fields, their masking can't be disabled.
By configuring your application for Session Replay, you can decide which content needs to be masked. If the content is configured to be masked at capture, it will also be masked at storage and at display. If configured differently, the content will be stored and displayed exactly as it was captured.