Problem statement
Imagine the following – You run an analytics solution on your website. The website visitor granted consent for their data to be used for analytical purposes but didn’t provide consent for the data to be used for any other purposes.
The analytics solution you use, like most solutions these days, offers multiple downstream connections. Among them are data warehouse connectors as well as marketing platforms (think of ad platforms or engagement platforms like email service providers).
Let’s look into two potential issues that can arise.First of all, any person with the right access levels can decide to forward data to any destination. Meaning that a very motivated marketer can leverage behavioural data captured under analytics consent and use it to fuel their marketing campaigns and even use it to build audiences even though no marketing consent was granted. As a result data can end up in destinations that use the data for purposes it never was cleared for.
A second risk arises within the data warehouse. While offloading data to the data warehouse is a common practice, the rise of reverse ETL solutions exposes that data to a very similar risk here. Additionally data warehouse data is increasingly used to train models for which explicit consent should be granted as well.
As illustrated the increased downstream connectivity and disclosure of the data captured by analytics platforms represent a risk for user privacy (in a non-transparent way) and as a result for the company’s regulatory compliance.
Interestingly, while vendors offer this downstream connectivity they rarely provide any form of guardrails to prevent mishaps from happening.
Note that while I'm using analytics platforms as an example, this risk applies to any type of platform.
Solution
In order to overcome this challenge, or at least to mitigate it, organisations need to build and deploy their own processes.
One of the guardrails we implement at Human37 is something we call “consent context”.
Consent context is the practice of contextualising which other types of consent were granted by a user when a data point was captured (beyond the consent type required to store the data in the first place).
To explore this with an example, let’s imagine a website which offers 3 types of consent:
Analytics
Marketing
Personalisation
A user provides the following configuration:
Analytics – Consent granted
Marketing – Consent not granted
Personalisation – Consent not granted
As a result data is captured in the analytics platform and a data point is stored.However, when capturing the data point we explicitly mention all the consent states as event properties or attributes:
consent analytics : true
consent marketing : false
consent personalisation : false
Note that in our example consent _analytics should always be set to true by the user in order for the data to make it to an analytics platform.
Now that we have a consent state we have additional context in order to build processes and guardrails in order to prevent that:
Data gets streamed unlawfully to destinations that require other consent types. This can be done by ensuring streaming filters are defined that require a specific consent value to be set to true.
Data is stored in the data warehouse and often repurposed for uses beyond its original intent, as each event now includes the consent context under which it was captured.
Next steps:
Now that we have laid out the principles, let’s explore how this can technically be applied for a number of platforms through our implementation guide.
GA playbook [COMING SOON]
Interested? Feel free to reach out!
Comments