Troubleshoot mobile banking apps without collection of PII

  • Latest Dynatrace
  • Tutorial
  • Published May 07, 2026
Disclaimer

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 use case, a business running a mobile banking application has trouble with crashes, performance issues, and multiple instances of the application not responding. While the application handles sensitive data, it is imperative that PII is masked and customer data protected. Unmasking should only be considered when data is needed to resolve bugs.

Key terms

Masking at capture

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

Masking at storage

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

Masking on read/on display

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

Masking at ingest

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.

Scenario

As a mobile site reliability engineer (SRE) and app owner, you’re responsible for:

  • Finding stability regressions such as crashes and ANRs, and identifying user journeys with slowdowns and other problematic areas.
  • Correlating issues to a country and device without identifying individual users.

You get an alert about crashes and user journeys with slowdowns. To address this, you open a dashboard that:

  • Shows summarized information and error details grouped by app version, device type, and country.
  • Locates problematic user journeys and regions.
  • Reproduces and fixes the issues in testing.
  • Confirms that improvements are implemented.

You need to do this without using any sensitive user data.

Key privacy practices

As a first step, you can activate the user opt-in mode. In this case, the monitoring is off by default, and is activated only after the user grants consent. Since we don't want to collect any personal data, set the data collection level to Performance.

Data typeEligible for collectionActions/mitigationLearn more

Country

Yes

The country information is available in the user session data.

Data privacy for mobile frontends

Device

Yes

The device information is available in the user session data.

Data privacy for mobile frontends

Email addresses

No

User tags are not captured when the data collection level is set to Performance.

Data privacy for mobile frontends

IP addresses

No

All identifiers are randomized when the data collection level is set to Performance.

Data privacy for mobile frontends