This guide is intended for informational purposes only and does not constitute legal advice. While every effort has been made to ensure the accuracy of the information provided, it is recommended that you consult with a qualified legal professional to ensure compliance with all applicable laws and regulations.
In this customer service use case, businesses handle customer complaints by analyzing real user monitoring (RUM) data.
This data is crucial for identifying affected sessions and resolving issues efficiently. At the same time, companies must ensure that access to personal data is restricted only to authorized personnel. When using Dynatrace to monitor user sessions, data can be leveraged to streamline complaint resolution and enhance customer satisfaction.
At-capture masking requires identifying and masking sensitive parts of your log records before data is transferred to Dynatrace. To achieve this, you can choose OneAgent to collect your logs. OneAgent has a built-in mechanism for sensitive data masking that can be granularly configured on the host, host group, or environment level.
For details, refer to Mask your logs at capture or Protect personal data by not capturing it (masking at capture).
When masking at storage is implemented, data is sent to the Dynatrace server for optimal analysis and is masked before it's stored.
For details, refer to Protect personal data by not storing it (masking at storage).
When data is masked at display, it's stored in its original form but is accessible only to the users of your choice.
For details, refer to Protect personal data by not displaying it (masking at display).
With this method, you can mask the data once it reaches Dynatrace, by setting log processing rules. After data is processed, it is sent to storage and is available for further analysis. The key advantage of this method is the fact that it allows data flow from all log ingest channels.
For details, refer to Mask your logs at ingest.
As a help desk manager for a large fashion online retailer, your primary responsibility is to quickly address and resolve customer complaints (for example, “My order didn’t go through” or “Wrong merchandise”). You can leverage user tags (specifically, customer email addresses) to link sessions with particular users. However, it’s crucial to ensure that your team can efficiently locate the relevant sessions without accessing unnecessary personal or sensitive information that is irrelevant to your task.
| Data type | Eligible for collection | Actions/mitigation | Learn more |
|---|---|---|---|
Email address | Yes | By default, all sessions are anonymized. Email addresses can be configured to be used as user tag fields. They would then be captured but masked on read. Only users with access to builtin-sensitive-user-events-and-sessions fieldset are able to view them. | |
IP addresses | No | No action needed. IP addresses are masked by default | |
Credit card1 | No | Captured URI may contain personal or financial data. Turn on Mask personal data in URIs to mask personal data, such as credit card information in URIs, headers, exception messages, and data captured for request attributes at ingest. | |
Shipping address | No | Captured URI may contain personal or financial data. Turn on Mask personal data in URIs to mask personal data, such as shipping address in query parameters at ingest. | |
Password | No | User input is not captured. | |
Products viewed and bought | Yes | Dynatrace captures a user journey. The user journey can only be linked to a person with applied user tags. |
SaaS customers should not ingest restricted information such as credit card data into Dynatrace. For details, see the Dynatrace Subscription Agreement.
Privacy configuration needs to be set up for each frontend individually. Currently, RUM stores data in both Dynatrace Classic and Latest Dynatrace (double storage). Privacy settings are linked, meaning that configuration applied to one frontend will affect both datasets. However, permissions for accessing data may differ between Dynatrace Classic and Latest Dynatrace. For details, see Permissions in Grail and New RUM Experience permissions.