Analytics & Digital Marketing Tips

Blog Home › Analytics › 5 Actionable Steps to GDPR Compliance with Google Analytics

5 Actionable Steps to GDPR Compliance with Google Analytics

February 16, 2018 Joe Christopher Analytics, Google Analytics

Shares 68

Disclaimer: I am not a lawyer and this blog post is based on my own research and interpretation of the General Data Protection Regulation (GDPR) and e-Privacy Regulation. You are advised to seek legal counsel that specializes in the GDPR and e-Privacy Regulation to ensure that your organization conforms to these regulations. GDPR is complex and interpretations vary. If you have questions or suggested clarifications, please comment and provide sources, as appropriate.

Countdown to GDPR

What is GDPR and Why Should I Care?

The General Data Protection Regulation (GDPR) is a European Union (EU) data privacy regulation that puts the customer/individual in control and it goes into full effect on May 25, 2018. The purpose is to consolidate privacy regulations across the EU.

If you are not yet familiar with the details of GDPR and why you should be taking action for readiness ahead of the May deadline, read my blog post on how to Avoid Penalties and Build Trust by Becoming GDPR Compliant.

Quick Highlights of GDPR

Monetary administrative penalties of €20 million or 4% of worldwide revenue if your organization is not in compliance.
Subjected to GDPR even if you don’t have a physical presence in the EU; if you provide goods or services to EU citizens, you are impacted.
The definition of personal data is expanded and clarified to include IP addresses, cookie identifiers, and GPS locations.
Explicit content and transparency is required; this means that inactivity and pre-checked boxes are not considered consent.
EU citizens have the right to be forgotten and personal data must be erased upon request.
GDPR is an opportunity to build trust and help your brand stand out.

While the GDPR may at first appear daunting, I’ll provide you five actionable steps to help you on your journey towards GDPR compliance with Google Analytics.

Disclaimer: Be aware that this blog post is only considering Google Analytics and not the other marketing technologies that your site likely uses.

Google Analytics: Your Data Processor

Under the GDPR, if you use Google Analytics, then Google is your Data Processor. Your organization is the Data Controller since you control which data is sent to Google Analytics.

With Google as your Data Processor, they have obligations to conform to the EU GDPR. According to Google’s own Privacy Compliance website, they are “working hard to prepare for the EU’s General Data Protection Regulation.” You can see more details on this site and it is almost certain that Google Analytics will be fully compliant by May 25, 2018. As part of being a Data Processor, Google must provide a data processing agreement that you’ll need to accept.

As a comparison, Adobe Analytics is working on the same GDPR readiness, as is Mixpanel.

Actionable Steps to Become GDPR Compliant with Google Analytics

#1) Audit Your Data for Personally Identifiable Information (PII)

Hopefully this doesn’t come as a surprise, but collecting Personally Identifiable Information (PII) is against the Google Analytics Terms of Service.

This is true both of Google Analytics Standard and the paid Google Analytics 360 solution. Whether you are confident or not, now is the time to audit your data collection to ensure that you are not transmitting PII.

Check your Page URLs, Page Titles, and other data dimensions to ensure that no PII is being collected. A common example of PII data collection is when you capture a Page URL that contains an “email= querystring” parameter. If this is the case, you are likely leaking PII to other marketing technologies in use on your site!
Ensure that any data entered into forms by Users, that is also collected by GA, does not contain PII.
Be aware that simply filtering out PII (via Google Analytics filters) is not sufficient; you must address this at the code-level to prevent the data from ever being sent to Google Analytics.

#2) Turn on IP Anonymization

Under the GDPR, an IP address is considered PII. Even though the IP address (by default) is never exposed in reporting, Google does use it to provide geo-location data.

To be safe, we recommend turning on the IP Anonymization feature in Google Analytics. This requires a code change to enable. If you use Google Tag Manager, adjust your tag or Google Analytics Settings variable by clicking into More Settings -> Fields to Set and then add a new field named ‘anonymizeIp’ with a value of ‘true’.

screenshot of google analytics anonymizelp settings

If you don’t use Google Tag Manager (GTM), your tag management system may have this setting exposed as an option, or you may need to edit the code directly.

The result of this change is that Google will anonymize the IP address as soon as technically feasible by removing the last octet of the IP address (your IP becomes 123.123.123.0 — where the last portion/octet is replaced with a ‘0’). This will happen before storage and processing begins. “The full IP address is never written to the disk” when this features is enabled.

The impact of this GDPR change on your data is that geographic reporting accuracy is slightly reduced.

The impact of this GDPR change on your data is that geographic reporting accuracy is slightly reduced. Click & Tweet!

#3) Audit your Collection of Pseudonymous Identifiers (hashed Emails, User IDs)

Your Google Analytics implementation may already be using pseudonymous identifiers. This may include the following:

User ID — This should be an alphanumeric database identifier. This should never be plain-text PII such as email, username, etc.
Hashed/Encrypted Data such as Email Address — “Google has a minimum hashing requirement of SHA256 and strongly recommends the use of a salt, minimum 8 characters.” — Source. We do not recommend collecting data in this manner.
Transaction IDs — Technically, this is a pseudonymous identifier since when linked with another data source, it can lead to the identification of an individual. This ID should always be an alphanumeric database identifier.

Under both GDPR and the Google Analytics Terms of Service, this appears to be an acceptable practice. But, this is where you are advised to ensure that your Privacy Policy is updated to reflect this data collection and purpose, as well as to gain explicit consent (via opt-in) from your users. In both cases, the language used needs to be clear (no technical or legal terms) and answer the questions of, “what data is collected?” and “how it will be used?”

If you are familiar with the GDPR at this point, you may be asking yourself how you can reasonably honor a User’s request to be forgotten.

This is tricky as Google Analytics does not (currently) provide a method for selective data deletion. From our point of view, you’ll likely need to delete the User ID from your CRM to satisfy this requirement, which will prevent the record in Google Analytics from being associated to a known individual. ~~We do not have insight into Google’s plans, but perhaps they’ll offer a method of User ID/Client ID data deletion by the time GDPR goes into effect.~~ (UPDATE: Thanks to Yehoshua Coren for letting us know that Google announced at Superweek that they will support User ID/Client ID data deletion.)

#4) Update your Privacy Policy

The most important update to your Privacy Policy under GDPR is that these notices need to be written in a way that is clear, understandable, and concise.

As it always should have been, the intent of the Privacy Policy is to describe what you do in a clear manner and then, most importantly, your organization needs to follow through and do what it says. Your audience of the Privacy Policy is the end user (not lawyers).

Per this eConsultancy article, you should consider the following questions when writing your privacy notice:

What information is being collected?
Who is collecting it?
How is it collected?
Why is it being collected?
How will it be used?
Who will it be shared with?
What will be the effect of this on the individuals concerned?
Is the intended use likely to cause individuals to object or complain?

#5) Build an Opt In/Out Capability

The big question on everyone’s mind is if they really need to get explicit consent for tracking. After all, this could be a substantial amount of work and could absolutely impact the participation of users in your Google Analytics data. The answer to this question is multi-pronged in that most likely you will, that it depends, and that you should seek legal counsel.

Let’s dive into a few considerations to think through.

If you are collecting User ID or other pseudonymous identifiers, you’ll need to gain consent from the user. As mentioned at the beginning of this blog post, this consent needs to be explicit (opt in). Gone are the days of the cookie notice stating that if you proceed to use the site, you consent — that is no longer considered consent. Instead, you’ll need to ask users for their permission clearly and most importantly, before Google Analytics executes.

The most common approach to this that we’ve seen is to have an overlay modal on the page that asks the user for permission and then once granted, the page either reloads or the Google Analytics scripts (and other marketing technologies) proceed to execute.

You may consider leveraging technologies such as Tealium’s Privacy Widget to achieve this technical objective. There are many other vendors to consider such as Evidon and TrustArc.

See our Healthcare.gov Case Study from back in 2015 where we helped implement the US Government’s first website to offer consumers the ability to opt out of tracking and to honor the Do Not Track browser setting. This was achieved by using Tealium iQ’s Privacy Manager technology.

If you are using Google Analytics data to collect UserID/Hashed PII or to assist in behavioral profiling or if you are using other advertising technologies, you’ll need to build an opt-in consent mechanism as well as functionality for your users to opt-out at any point.

Since Google Analytics also records an online/cookie identifier called the GA Client ID, and because this is part of the core functionality of the product, you will likely need to offer the opt-in consent for all EU visitors to the site. This is a point that you’ll want to seek legal counsel on, but if you read the regulation, it specifically mentions that online identifiers (such as the GA Client ID) are considered personal data and thus it would be subject to this regulation. We’ve read other sources that indicate that there would be no need to offer consent if you aren’t collecting User ID or any other pseudonymized data in Google Analytics.

There are requirements as part of GDPR to prove that consent has been given (audit trail). We recommend as part of the explicit action of affirmative consent, that you track/log this in Google Analytics as an event. You may also want to record this in your own database against the Google Analytics Client ID (and User ID if applicable).

Share Your Challenges

These five actionable steps towards Google Analytics GDPR compliance are a great way to help your organization either begin the conversation, or continue your efforts with new ideas that you may have missed. GDPR is a complex regulation and it is imperative that your organization develop the right roadmap towards becoming compliant.

While the focus of this post is Google Analytics, these steps also apply towards other digital analytics and marketing vendors. Each organization is different and there are certainly more that you’ll need to do for compliance, so we’d love to hear about your challenges.

Please share your tips, concerns, and questions in our comments section below to continue the conversation around how to progress towards GDPR compliance.

Ian Feavearyear

Do you think this is only for the protection of individuals in their _private_ capacity, such as on a B2C website (an online store, for example), or in their “business capacity” too – e.g. people visiting B2B sites on behalf of their employers in order to assess the quality of products or services their employers are considering purchasing?
Christopher Mason

Thanks for the article – one of the clearest summations of the issues (and solutions) I’ve seen! My question relates to point 5, and the likely impact of this on the quantity (and quality) of GA data as a result of the opt-in. Do you think this will result in a resurgence of logfile analysis? Or is Google going to develop a version of GA that does not use cookies and doesn’t include User-based metrics? And then the ultimate irony is that the only way to ‘remember’ that a user has opted out of cookie-setting is by setting a cookie!
Chris

I’m thinking of only allowing access to the site if one agrees to the use of cookies for analytics. I think this will be ok for B2B organisations like ours, not sure how it will go for consumer-based websites.
poshest

Google has expensive lawyers. Really they should just publish a guideline for us all: “If you plug in GA, do these steps to comply with GDPR: 1, 2, 3…”
Joe Christopher

@ianfeavearyear:disqus Thank you for your comment. The GDPR doesn’t distinguish between this because in reality, everything you do on your web browser/mobile device is from the perspective of an individual.
Joe Christopher

@disqus_WH6wx8D2Wu:disqus Great question! There’s a few points I’ll address. The ePrivacy Directive, which is still not finalized, may make an exclusion for analytics being exempt from consent if there is no other personal data being sent. I’m not sure when that will be finalized or if things will go that way. It is interesting to read about Snowplow’s and Matomo’s (formerly Piwik) approach to GDPR since you are the owner of the hardware that collects/processes the data — I suggest taking a look at their blog posts that they have on GDPR.
Joe Christopher

@poshest:disqus Sounds ideal, but they are in the role of the Data Processor, not Data Controller and as such there’s no legal basis for them to do so as it probably opens them up to lawsuits.
Joe Christopher

@disqus_X1BTVm1fb1:disqus I mentioned a little about this in the comment above, but a potential modification to the ePrivacy Regulation (separate from GDPR, but related) may create an exemption for Analytics cookies. See this link for more information: https://www.cyberwatching.eu/news-events/news/e-privacy-regulation-new-rules-analytics-cookies. The issue here is that ePrivacy Regulation is not finalized and won’t be until sometime later this year. This means that technically on May 25th, you are subjected to the full extent of how GDPR reads. Of course, if the ePrivacy Directive is approved with an exception for Analytics cookies and if you do collect things like UserID or pseudonymous data (hashed, etc) then in my opinion, you need consent still.
poshest

Well, I see what you mean, but that’s what disclaimers are for. And it is in Google’s interest to have happy users of its product. I’d take the risk if I were them. 😉
poshest

On another related topic, “As part of being a Data Processor, Google must provide a data processing agreement that you’ll need to accept.” Actually, I think your “but they are in the role of the Data Processor” applies here too. My understanding is that it’s controllers that are obliged to have the contracts in place. I’m sure Google will offer a contract, for efficiency reasons, but it’s not their responsibility as processor from my reading of GDPR.
Edward Upton

Thanks Joe – a comprehensive guide.

However, it’s quite extreme to consider the GA client ID to be PII: requiring opt-in for any cross-session tracking would ruin most B2C analytics. My own view is here https://blog.littledata.io/2017/10/19/is-google-analytics-compliant-with-gdpr/

Littledata has also developed an audit check for finding PII in page URLs, titles and events: https://www.littledata.io/features/audit
Joe Christopher

@lynne_mcnamee:disqus Thank you for pointing this out. I am the original author of this blog post. We reached out to the company associated with the link you provided to combat this.
Joe Christopher

@edwardupton:disqus Thank you for sharing your point of view. If you look purely at the language of GDPR, a GA Client ID is an online identifier and one that persists via a cookie. I’ve read that recent iterations of the ePrivacy Regulation make an exception for these Analytics identifiers, but ePrivacy Regulation is not yet finalized.

I encourage our clients to seek legal counsel on how aggressive they view this language to be/or not to be. Not sure there is a one-size-fits-all approach here.
Yoosuf

Ok so does that mean if we want to continue using the User ID view we may have to display an opt-in modal on the first page which someone lands on? And is this only applicable to visitors from the EU or is it applicable to anyone from any part of the globe?
Adam Lavery

This demonstrates how poorly the EU has approached this, as usual. We should not need legal council to interpret these new regulations. One “expert” may interpret one way, another a different way depending on how much they’re looking to make. Ultimately it will need the courts to decide, but given this has international impact, which court? The regulations should be clear and unambiguous. Instead, they are woolly and open to interpretation.

Can you imagine the frustration real people are going to experience if they have to explicitly consent to tracking on each and every website they visit? The cookie law was bad enough, but at least common sense prevailed and now we’re all just subject to an annoying and utterly pointless pop-up that can be ignored.

The correct approach to tracking and cookies would have seen regulations targeted at the 0.0000001% of the population that cares about such things. Cookie control is already a feature of all browsers – those that care just need to learn how it use it instead of forcing 99.9999999% of web-users and 100% of web owners to be inconvenienced. Same for tracking – the law could have just mandated all browsers support a common tracking standard and all tracking services observe the browser settings. Clear, simple, unambiguous – job done!

While this comes into force soon, no regulators should be enforcing it until the instigators of these regulations get off the backsides and publish clear, unambiguous, practical, day-to-day guidelines on what they actually mean.
Erik Mork-Barrett

Does the overlay have to show up for all users or only for users from the EU?
Joe Christopher

@erikmorkbarrett:disqus I recommend showing this just to users that are physically present in the EU, so often I see clients doing this via geo-ip lookup.
Joe Christopher

@disqus_8yDC61fJ4Z:disqus Yes, my interpretation is that you would need opt-in in this situation. This is applicable to your visitors from EU. Geo-IP identification is the most common way I see this done.
Andy

Hi Joe, I’m not quite sure what you mean by “Ensure that data entered into forms by Users does not contain PII.” in #1 above. A contact form would require a User to enter their email address for example? In this case (and probably for all forms) wouldn’t a checkbox agreeing to some GDPR compliant ‘terms’ (ie accepting the org’s privacy policy) be sufficient?
Joe Christopher

@Trenbania:disqus Thank you for the comment. I’ll update the post to provide clarification on this point. What I meant by this was that if you have forms where users are entering PII AND you are also collecting form-input-level data in GA, you must make sure that the collected form fields do not contain PII. As it relates to GA data collection, I would be more comfortable collecting the dropdown field selection versus any user input field. On your other question about requiring a checkbox, you will need consent if you plan to use the data for any type of marketing activities. If a user types in their email address for a contact form, they know that they are providing their information; often times they are not aware of how else that data will be used.
Rachael Clark

Really good article. Thank you for sharing. Couple of questions. Firstly a question related to how Google Analytics may use your cookie data for advertising even if you do not have the advertising features enabled. By this I mean, whilst you aren’t using the advertising features, can they still use your user data to inform their advertising products? i.e. given we’ve given Google Analytics data on what category our site that we’re tracking is and they collect that cookie data, they can then associate that cookie with that category and then allow other advertisers to market to them if they select they want to reach a user matching that interest category. My second question is whether we should be holding off firing the GA tag until a user has either provided consent (ticked the button) or provided implied consent by continuing to browse if it is worded as such in the consent banner? This meaning you miss initial traffic and any subsequent will likely be bucketed under “direct” traffic if they continue to browse as the tag would only fire then…
Joe Christopher

@disqus_vcfpFI9u5D:disqus Great questions; thank you!

Question 1) Under the GA Account Settings, there is a lot of information that Google provides on how data is shared. This includes benchmarking and more. You are in full control as an organization on whether you wish to opt in to this data sharing. The data that is shared is anonymous/aggregated and isn’t used by Google (according to what I read) to directly target any individual users that go to your site based on behavior, etc. Under Google’s terms, they have quite a bit of documentation on how they safeguard your data and how it is used/not used. https://support.google.com/analytics/answer/6004245?hl=en&utm_id=ad is a good starting point for reading through all of this.

Question 2) My recommendation is to not fire the GA tag until you have consent (and even more importantly if you are using GA features like User ID or other pseudonymous identifers.. You mention implied consent, but be aware that this is not an appropriate mechanism of consent under GDPR. It requires explicit consent.

Joe Christopher

Joe is the VP, Analytics at Blast Analytics & Marketing. He understands Digital Analytics like nobody else and is a master of many programming languages.

Add Joe to your circles on Google+ Joe Christopher has written 39 posts on the Web Analytics Blog.

Analytics Blog

We're here to help with tips and insight on the following topics:

Subscribe to RSS

Stoke Your Passion for Digital

Subscribe for a monthly digest of analytics tips, digital marketing news, and case studies from experts certified with Google, Adobe, Tableau, Tealium, and more!

Connect with Blast Analytics & Marketing

Digital Marketing and Analytics Tips on Twitter
Get to know our team better on Facebook

Popular
Comments
Featured
Tags