Header background

Building a responsible data capture policy

If comic books (and subsequent movies) have taught us nothing else, it’s that “with great power, comes great responsibility.” Data capture is a powerful way to add business context, but it must be used responsibly.

The addition of the Digital Business Analytics module to the Dynatrace Software Intelligence Platform gives you a new way to understand the impact that application errors, performance and user behavior have on your business. Since this module has been added, capturing additional business context from end users provides even more insights.  As part of existing digital experience monitoring (DEM) capabilities, you have the ability to capture business context on the front-end (e.g. in the browser via CSS selector, javascript variable, etc). And as part of core APM capabilities, you can capture business context on the back-end (e.g. inside any of your microservices via HTTP headers or payloads, Java/.Net method parameters, etc).  With Digital Business Analytics you have the power to understand this newly captured business context.

Examples of business context

The value of a shopping cart is a great example. Wouldn’t you want to know how much potential revenue you lost from a user that had slow performance, javascript errors, or was rage clicking like a crazy person?

Dashboard showing customer abandons

Or, would you like to know the impact of loyalty status or marketing campaigns on user behavior and business outcomes? This additional context is quick and easy to capture, all with no code changes.

Dashboard showing loyalty status

The uses of these powerful capabilities are endless. However, we must also wield them responsibly. Specifically, how do you decide what should and shouldn’t be captured? There are obvious things you shouldn’t be capturing, such as passwords or credit cards, but other cases may not be so cut and dry.

Let’s step away from Dynatrace for a moment and learn about responsible data capture more generally.

Guard rails

Recently, I attended a conference at Washington University in St. Louis on Leadership Perspectives: Data Responsibility and the Ethics of Analytics. One of the speakers, Jesse Wolfersberger, Chief Data Officer at Maritz Motivation, gave a great talk about “Incorporating Guard Rails around Transparency, Targeting and Tracking”. Much of what he talked about we can directly apply to data capture with Dynatrace.

Here’s just a few of his “guard rails” that I took away:

  1. Legality isn’t a high enough bar – Compliance with relevant laws, standards, and company policies (e.g. GDPR, PCI, HIPPA, etc) is necessary, but this alone is not sufficient. Ensure what you collect is relevant and be sure you don’t collect protected or overly sensitive data, as well as making sure none of the data you collect is a proxy for protected groups, especially if you plan to use the data to train your algorithms.
  2. Context matters – Be sure the data you’re capturing is contextually relevant to what you’re trying to achieve. For example, imagine if Stitch Fix collects your weight – ok, that’s pretty important for well-fitting clothes. But imagine Facebook wants to collect your weight – no way, that’s creepy.
  3. People appreciate transparency – While your lawyers may require that 40-page, 8-pt-font Privacy Policy / Terms & Conditions page, users appreciate something more meaningful, something open and comprehensible.  Google and Apple are great examples of companies trying to adopt more human readable privacy policies, as a way of being transparent about: what they collect, how they use it, and what control the user has over it.

Now that we have some best practice guard rails for data capture generally, let’s apply each to data capture in Dynatrace….

Guard rails in action

Guard rail #1 – Legality isn’t a high enough bar

When you think about Jesse’s first guard rail, start with our Help Docs which provide an overview of our privacy configuration options and best practices, including recommendations for GDPR.  For example, even if you’re not doing business in the EU, consider using Tracking Opt-in mode. Those Help Docs should help cover the legality bar, but as you’re capturing data responsibly, go further.

Out of the box, Dynatrace masks or doesn’t capture any potentially sensitive data. As you setup additional capture or unmasking, be sure that it does not include protected or overly sensitive data.

Here’s an example: Open Enrollment is the most important time of year for health insurance providers. Conversion rates for online insurance applications can have a dramatic effect on their top and bottom line. A potential customer that abandons an online application can impact either one. If they choose a different marketplace plan, it impacts revenue or if they default back to manual processes like phone or paper, it increases cost.  With a simple CSS selector you can capture which plan a user was interested in; enabling you to quickly understand which plans have interest but not conversions and focus your attention there.

Conversely, you could, but shouldn’t, capture certain SocioEconomic Status (SES) info, such as family income, education, and occupation. While these might enable better targeting of high value customers, they also create risks of bias or discrimination and should be avoided.

Guard rail #2 – Context matters

Jesse’s second guard rail reminds us to be sure the data being captured is contextually relevant. But how do you do this at scale in Dynatrace? Focus on the people and processes deciding contextual relevance.  Dynatrace provides special permissions, View sensitive request data and Configure capture of sensitive data, to ensure that only explicitly authorized users can access potentially sensitive data or configure additional data capture.

Ask yourself: who in my organization should have this permission and what processes should we have in place to ensure they use it responsibility? Once you know who should have this power, you can ensure that they receive appropriate privacy training. Similarly, incorporate the /auditlogs API endpoint into your audit processes to ensure that they are using this power responsibly.

Guard rail #3 – People appreciate transparency

As mentioned above, users appreciate transparency on what data you collect and how you use it.  If possible, follow Google and Apple’s examples – add a user-friendly explanation of what you capture, how you use it, and what control they have.

As an example, think about a user reading about Session Replay capabilities in a news story with no context – it’s probably going to sound creepy.  But if instead you proactively explain to your users what Session Replay means to them, they’re likely to appreciate this capability. The ability for a customer service representative to watch the interaction that frustrated a user and then help them through it can be invaluable. To put users in control, Session Replay also has an opt-in mode, see: https://docs.dynatrace.com/docs/shortlink/session-replay-personal-data.

Getting started

We’ve seen a myriad of customers already capturing additional business context to further extend the answers and insights provided by the Dynatrace Software Intelligence platform. If you’re not sure where to start, please reach out to your Dynatrace Sales Engineer; we would be happy to give you a demonstration and point you in the right direction.  Our Services and Insights teams can also help with more in-depth engagements.