GDPR: Scope, Consent & Impact on (Analytics) Tags

May 9, 2018 | Digital Strategy, Digital Trends, General, Google Analytics, Industry News

It’s coming and let’s face it, whilst we’ve been warned since 2016, very few started thinking about it more than 6 months ago if not later…There are a lot of resources out there trying to translate what GDPR means and how it will impact businesses’ organisation and data management but very few manage to give clear and practical guidance. This post is an attempt to provide concrete answers about the user consent mechanism and its impact on web analytics. Of course, the usual caveat: “I’m not a lawyer and you should seek legal advice to assess your own situation and blablabla”….But even if you seek legal advice, you may end up knowing more about the GDPR than your legal adviser, especially here in NZ!

 

 Step 1: Do You Need To Comply With GDPR?

There are two conditions to meet to fall under the GDPR:

1- Do you actively target EU-residents?
2- Do you collect personal data, including pseudonymous data?

If you answer “no” to the first or both questions, then you’re in luck. Otherwise, sorry but you’ll need to go under the hood of you data collection and management processes and adjust them…

 

1. Do you actively target EU-residents?

There has been a misconception that if you don’t process or collect data inside EU, you are not affected by GDPR. This is partially true (or wrong, depending on your mood…). GDPR applies to any sites that collect data about data subjects that are physically in the Union, regardless of the data controllers, (i.e. the site) and/or processors’ locations. Given that you can’t really control who is visiting your site, any sites are actually virtually impacted by GDPR. However the Regulation will look at how actively the site is targeting EU-residents to determine if it falls under the GDPR.

Recital 23: “In order to determine whether such a controller or processor is offering goods or services to data subjects who are in the Union, it should be ascertained whether it is apparent that the controller or processor envisages offering services to data subjects in one or more Member States in the Union. […] factors such as the use of a language or a currency generally used in one or more Member States with the possibility of ordering goods and services in that other language, or the mentioning of customers or users who are in the Union, may make it apparent that the controller envisages offering goods or services to data subjects in the Union.”

So for instance, if you are offering payments in Euros and/or specific shipping rates to European countries (including UK), you explicitly target your offer to EU-residents. Therefore you must abide by the GDPR. Similarly, if you have advertising campaigns specifically targeting a member State of the Union.

The same applies if the site doesn’t sell anything but still monitors users’ behaviour (see recital 24).

 

2. Do you collect personal data, including pseudonomised?

You may think that you are safe because you don’t collect personal data but the GDPR has a rather broad definition of what constitutes personal data:

Recital 26: “Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. […] To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments.The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.”

Recital 30: Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them“

This means that IP addresses and Client IDs (created by the _ga Google Analytics cookie) are considered as personal data by extension, even if you don’t have direct access to these data as they are not surfacing in GA reports.

One way to address this is to mask IP addresses using the IP Anonymization feature. This would make the identification of a specific subject much harder. Note that you will need to either remove or adjust your current IP-based filters in GA accordingly.
Then for users who do not consent to get their data collected for Analytics purpose, you can still track their session by setting the _ga cookie to expire at the end of the session (or even no cookie at all), which makes their identification impossible (the Client ID becomes truly anonymysed), unless they provide personal pseudonmysed data, like a User ID, but in this case you will need to ask for their consent for Personalisation purpose anyway. And remember that GA doesn’t allow you to collect any actual personal data (e.g. name, email, phone number, address, etc.).

By now, you should have a better idea on whether or not you need to comply with the GDPR.
If so, you will have to get the consent from users.

 

Step 2: Create a Consent Mechanism

During my research, I haven’t been able to see a consent modal design, which would fully answer GDPR requirements, i.e.:

  • Be granular by data collection purpose (I’ve seen an example where all data processors were listed, which would end up as a very long list for many sites)
  • Offer free choice, without the opt-in/opt-out button being preselected
  • Explain in plain English what the data processing is for, by purpose
  • And most importantly, address the inter-dependency issue between some data processing purposes

Piwik Pro and Tealium both offer built-in consent management solutions but they fail to fully address these points.

Tealium Consent Manager:

Consent Preferences Manager from Tealium

Tealium proposes a highly customisable consent manager, but not sure if you can customise each tag’s settings according to the consent. It looks like the analytics tags would be all disabled if the consent for Analytics is not given, which would be unnecessary if you can configure them so they only collect anonymised data. And this doesn’t really address the inter-dependency issue (not that there is any between the purposes shown in the example above).
As a side note, I would recommend to ask for consent for the Social Media purpose only when users first click to share on social media, and provide an option to save their selection (so create a specific cookie for social sharing consent).

 Piwik Pro Consent Manager:

Consent form from Piwik Pro

I like the “Agree to all” button but not sure how it addresses dependencies between data processing purposes. And I imagine the saving option should not be available if at least the Analytics purpose is not enabled since by definition you are not allowed to store any data if no consent is given.

Adobe Dynamic Tag Management (soon to be revamped to “Launch”) doesn’t provide a ready-to-use consent management solution but you can add extensions such as TrustArc’s or Evidon’s (not free though).

As for Google Tag Manager, there is no built-in consent manager either but you could easily inject some custom HTML tag as described in this post from AnalyticsMania.

Google has also updated its information portal for publishers and advertisers, suggesting different solutions to add a consent function to your site.

Still, the best solution would be to create its own customised consent modal as no situation is the same…

Below is my attempt to create a consent modal for a first-time user on landing page:

FIRST consent modal
“More details” link would redirect to the privacy policy page describing the purpose in more details and listing all data processors. To address the inter-dependencies between purposes, the Analytics and Personalisation purposes would be enabled if the Personalisation and Advertising purpose are enabled, respectively.

 

Step 3: Adjust Your Data Collection According to User’s Consent Level

The best article I’ve read so far about this is the excellent post by Jente De Ridder from Humix, who proposes a practical solution to make GA GDPR compliant via GTM. It’s logical and well written and probably answers most of web analysts questions.

The diagram I propose below is largely inspired by Jente’s solution, with a few additional notes on the granular consent mechanism.
For instance, one requirement from GDPR is to “be able to demonstrate that the data subject has given consent to the processing operation” (recital 42). Therefore you can send an event to GA to pass the consent level. This event will then be very useful to identify “new users” from consent level 0 (by definition all users with consnent level 0 are new users) from other “”usual” new users.

Additionally in the GA UI, you will need to adjust your Data Retention period to a determined period as required by the GDPR:

Recital 39: “The personal data should be adequate, relevant and limited to what is necessary for the purposes for which they are processed. This requires, in particular, ensuring that the period for which the personal data are stored is limited to a strict minimum.”

I hope this can help visualising the challenge and visualising one solution more easily, if nothing else.
 

GDPR consent mechanism

 

Closing Thoughts

I believe we will certainly see a decrease in the audiences size of the (remarketing) advertising campaigns but with good wording, we can end up with a win-win situation: the user understands why we collect data and why it may be beneficial for him/her while the brand shows its care for data privacy respect and may improve advertising campaigns with a better qualified audience and smarter incentives.

Ultimately, even if you are not directly impacted by GDPR (e.g. you don’t target EU-residents in the Union), I would still encourage you to proactively think about how you collect, store and share users data (especially if EU-citizens constitutes a significant share of your audience – think about immigration-related sites, job listings, or real estate sites, etc.) as New Zealand will most likely cooperate with the EU and update its privacy regulation to get closer to the GDPR. Showing that you have a strong privacy policy can also be perceived as a competitive advantage for users, who are more and more vigilant about how their data is being collected, used and shared…

Some Resources: