Google Analytics and GDPR - what do you need to do
Google Analytics is used by over 30 million websites, including 1 in 4 of the world’s top websites. Given that you’re reading this article, I’m going to guess that one or two of those 30 million websites are websites you have something to do with.
The GDPR (General Data Protection Regulation) will come into force across the entire EU on May 25th 2018 (as well as EEA member countries Iceland, Liechtenstein and Norway). The General Data Protection Regulation puts new laws in place to put the consumer back in control of their personal data and put strict rules on its processing.
There’s been no escaping the fact it’s coming given the endless stream of emails that have been arriving in recent weeks from organisations working right up to the deadline to hopefully get your consent to keep receiving marketing information from them.
If you want to know the specifics the there’s no shortage of articles out there explaining exactly what GDPR is. A search for GDPR for dummies is probably proof of that – but basically, if you have anything to do with a GDPR country, you will need to put a little bit time into making sure you’re compliant with the new regulation and to work out how to become compliant if you realise you aren’t.
Okay, so we’ve got GDPR and we’ve got Google Analytics. But what does that combination mean?
By its very nature, Google Analytics is gathering information about the people who are visiting your website. GDPR applies to the personal data and monitoring of individuals by enterprises.
An enterprise, as defined in article 4 of the regulation, is any person or organisation engaged in economic activity irrespective of legal form. Which means all company related websites are included, but not personal websites or blogs as long as you don’t receive any money from them.
According to the Google Analytics terms of use, you’re not allowed to send personally identifiable information (PII) to Google Analytics, but you might be (accidentally or unknowingly) – or you our your organisation might have done in the past. You might also be sent personal data (I’ll explain the subtle but important difference between PII and personal data later on).
Slightly less obvious is that you might have Google Analytics data that, when combined with other data, results in something personally identifiable. GDPR covers identification of someone both directly and indirectly.
In short, GDPR means you’ve got to know what data you’ve got, why you’ve got it, what you are doing with it, and who is handling it.
Making sure you can work out the answers to those questions from a Google Analytics perspective and give you an idea about what you can to do in order to be compliant (or least more compliant!) is what I’m going to help you with in this article.
At this point, I think it’s the right for me to make a disclaimer: I’m not a legal expert and I’m not giving you legal advice on GDPR compliance. I’m an expert in Google Analytics and using analytics data to generate actionable insights that will help improve the performance of websites I work with. Please get someone to review your Google Analytics GDPR compliance documentation from a legal perspective and take further legal advice where necessary.
Here’s the checklist that I’m using when checking GA setups from a GDPR perspective.
I work primarily with analytics setups that don’t have e-commerce features enabled. If you have that enabled, there may be a few more areas you’ll need to look, or at least dive a little deeper into.
Google Analytics GDPR checklist
1 – Documentation
I’m starting with the end; You need to be able to prove your compliance.The documentation required is covered by Article 30 in the GDPR regulation – “Records of processing activities”.
Article 30 says that organisations with less than 250 employees are, generally, not obligated to maintain written documentation – but don’t cheer too loud too soon if you’re a small org! You’re still obliged to be compliant even if you don’t have to write it down!
Some basics: Google Analytics is the data processor. Your organisation is the data controller. You need to document what personal or pseudonymised data you are collecting, the purpose for collecting it, records of consent (or the legal basis if other than by consent), and data processing agreements.
For most of us, we won’t be collecting any personal data as it’s against the Google Analytics’s T&Cs, and we won’t be collecting any pseudonymised data, and you won’t need to collect records of consent.
Your legal basis for collecting analytics data will probably be legitimate interest – To judge if it is, a benchmark test would be: Would the visitor be surprised/alarmed if you explained to them what data you collect and how you use that data? If they would, then legitimate interest isn’t likely to be good grounds for processing.
You’ll need to:
- State what the purpose of collecting Google Analytics data is (and why the processing is necessary to achieve it),
- explain your process for regularly auditing the GA data collected to make sure there isn’t any personal data being collected,
- who has access to the data,
- and a copy of your data processing agreement with Google.
If you’ve got more than 250 employees in your organisation, I’d expect there will be someone internally who’ll provide you with guidance on exactly how the documentation should be (and possibly even provide a template and further guidance).
2 – Account ownership and access.
You need to know can access your data, and have control over exactly who can access your data. Who owns the GA account? “Ownership” of a Google Analytics account is not always straightforward, but make sure your organisation has admin rights at the account level.
If your organisation doesn’t have admin access it’s hard to claim you are the data controller. If you have a profile that’s part of an agency account (or a private account, or anyone else account), then you should bite the bullet and migrate to one of your own.
Go into user management and tidy up access. Remove people who don’t need access any more. Minimise the number of people who can give other people access. Make sure you do this for all three levels – account, properties and views.
Don’t share accounts. It still amazes me how many times I hear of organisations using one Google login to access Analytics (and other Google services). Yes, it is a good idea to have a functional account as an admin – it’s a clear statement of ownership and gives the organisation control even if, and when, individuals leave – but don’t allow multiple people to use that account.
Always delegate access to individual accounts. This gives you an audit trail (you can see when people have been added in “change history”) and makes it much easier to manage access.
3 – Audit your data – historical and current
You need to make sure you aren’t unknowingly retaining personal data collected some time ago. You might be aware of personal data you used to collect, but perhaps you haven’t been working with this analytics account since it was first created.
Try to fill in the blanks by talking to people who have knowledge of the GA account – this might be people internally and agency staff. How far back does the data go? You could have data going back as far as 2006, when Google Analytics was launched. What has been collected during that time?
What you are sniffing for is personal data. In a GDPR context this is much broader than the US concept of PII – Personally identifiable information. PII covers a narrow set of data including name, date of birth, address, social security number and bank/credit card numbers. Under GDPR personal data can be things such as photos, transactions, IP addresses, as well as name, address, date of birth. PII is a subset of personal data, but not the equivalent of it.
Checking for personal data in GA involves a fair bit of manual work. This article does a great job of showing how to go about finding personally identifiable data. You can also use this as a template for doing similar work in languages other than English.If you do find any historical data containing personal data, you’ll need to check if it is still being collected and make a decision about what to do (stop collecting, delete, get consent, change legal grounds for collection).Things to check:
- Check campaign tracking for personal data. Your newsletter tool, for example, might be sending in personal data.
- Check site search for personal data
- Check URLs and query strings for personal data or potentially personal data. account URLs, form submissions, long URLs, email addresses
- Check the use of custom dimensions and custom metrics for personal data
- Check event labels, categories and actions for personal data
There have been many really good suggestions and guides written during the years covering all kinds of interesting ways you could use Google Analytics to collect data. Technically many of those suggestions may still work, but they are perhaps no longer legal.
For example, this technique for tracking form submissions explained by JotForm is good, but a big GDPR no-no without implicit consent.
4 – Review and accept the data processing amendment
Google is your data processor, you need to have a formal agreement. The data processing amendment is your formal agreement. To find it, go into Admin, account settings, and then scroll down until you find the data processing amendment heading.
If you’re making use of a free Google Analytics account, or a Analytics 360 account sold directly by Google (rather than a reseller) then you have a “direct customer contract with Google to use Google Analytics”. Which is the phrase Google uses in the account settings to say whether you’re eligible to accept the amendment.
Take a moment to review the data processing amendment and then accept it. This agreement is something you will probably have to keep with your compliance documentation. If your organisation is big enough, legal will probably want to look at it too.
Next, click on the button “Manage DPA Details”. This is where you declare details of the legal entity which is responsible for the analytics account. You need to add at least one legal entity and at least one contact person.
Anyone who has account level edit privileges has the ability to accept this agreement and manage the DPA details, so it’s vital you check who has access (see point 2 in this checklist!) and make sure the details are correct.
5 – Review the data retention settings
Google has introduced new data retention settings that allow you to control when data associated with a user’s cookies, advertising identifiers, or user identifier, will be deleted from Google Analytics servers. Aggregate data isn’t affected by these settings.
There are two settings. One is the length of time before data will be deleted – the retention period. The other is whether the retention period gets reset every time a user is active.
So, if you set the retention period to 14 months, and have “reset on new activity” enabled, a visitor who comes back for the first time in 13 months will cause the timer to go back to zero and no data gets deleted.
Google has set a default of 26 months for the retention period. You can alter it, but only from a fixed list of 14, 26, 38, 50, or “do not automatically expire”.
Google has also set the automatic reset of the retention period to on. If you don’t make any changes, these are the settings that will come into action on May 25th 2018.
I’ve been keeping the default of 26 months for most sites but turning off the “reset on new activity” setting. If you leave it on, add to your documentation your justification of why you need the data of regular visitors for an indeterminable length of time. If you can’t write that down, you shouldn’t have this setting on.
6 – Check IP anonymisation is turned on.
IP addresses are classed as personal data under GDPR. Google doesn’t make the IP address available in reports but it uses it for geo-location purposes.
Thankfully you can make Google mask the IP address as soon as possible once it reaches Google. This is done by setting anonymizeIP to true in your tracking code. Doing this causes the last octet of the IP address to be set to 0. So the IP-address 85.227.17.132 becomes 85.227.17.0. The true IP address is never stored.
There are some consequences of doing this. If you’ve have filters that are IP-address based, then there’s a good chance they will stop working once you start anonymising your visitors IP-addresses.
In my experience, IP-address filters are generally used for dealing with internal traffic or traffic from suppliers/partners. Simo Ahava wrote a great article explaining how you can use Google Tag Manager and a custom dimension to achieve a similar result, even with IP anonymisation enabled.
7 – Check if you’re using userid
“User ID” allows you to create your own identifier for each visitor in Google Analytics. It would generally be used if you allow people to log-in to better unify sessions across browsers and devices.
If you make use of it, you’ll need to obtain explicit consent from the visitor. Legitimate interest isn’t good enough as the legal basis for processing for User ID as you are obviously and clearly connecting that ID to an individual.
Google have, just before GDPR comes into force, released the User Deletion API. This makes it possible to delete the data associated with an individual. So if you are asking for consent and get a “no” or “right to be forgotten request”, you can use this API to delete the user’s data given the user_id or client_id of that user. (They also accept the app_instance_id.)
8 – Check use of transaction id (when eCommerce is enabled)
The transaction ID is pseudonymised data and will require explicit opt in. The reason for that is the transaction ID will also be stored somewhere else – presumably in the form of an order number in your order system. That system will have personal information, so it’s pretty simple to connect the transaction ID (which is visible in Google Analytics reports) to an individual.
If you aren’t running an e-commerce site, you probably aren’t going to have the e-commerce features enabled so this isn’t going to be an issue you for.
9 – Check if you use advertising features
If you have Advertising Reporting Features enabled then Google makes use of its advertising cookies. This feature is the one that allows you to see demographics in your audience reports – including gender. It also means that you are allowing your website to pass data through the advertising cookies.
So if you want to make demographic and interests data available in Google Analytics, you’ll need to turn this on and obtain explicit consent from your visitors. I’ve been turning this setting off. You can find this setting under admin, property settings, tracking info, data collection.
10 – Check your use of data import
Google allows you to upload data from other sources and combine it with the data collected in Google Analytics.
Do you know if any data has ever been imported to your account? What was imported? There might not be any problem at all with the data you’ve imported – but to judge whether it is, you will first need to know what’s going on.
On the data import page (found under admin, property, data import), you can see the data sets that have been previously been uploaded to Google Analytics for that property.
Additional metadata about content, products or custom locations added using the data import tool is unlikely to raise any GDPR flags – but if you are adding data from a CRM system, or other external systems containing customer data – including transactions, then you’ll need to investigate more closely.
To explore them more closely you need to go to the data import dataset list. From there you can click on “manage uploads”. After that you’ll be presented with a list of all the imports that have been made into this property.
Each row has a “download” option. You can download the file and analyse/check the content. If you conclude that for some reason the data can no longer be retained in Google Analytics, there is a “delete” link on each row.
11 – Provide a means of obtaining explicit opt-in (when collecting pseudonymised data)
If you are collecting pseudonymised data – such as user ID, transaction ID or data in custom dimensions or events, then a means for opting in (and out) is likely to be needed for compliance – depending on your legal basis for data processing.
If you do need to obtain consent, then you’ll need to keep a record of that consent. You’ll need to record when the consent was given and what specifically the consent is for.
The “old style” Cookie banner – which is more often than not just some text and a “OK” button – isn’t good enough if you require consent under GDPR.
The “cookie law” is separate from GDPR and GDPR hasn’t replaced it – Each has their own requirements with regard to consent.
The ICO in the UK has a pretty good at a glance page that gives an overview of what you need to consider when asking for consent.
For any GDPR-compliant consent, make sure the opt-in is stored (perhaps sent as an event to GA). Don’t run Google Analytics if they say no to analytics tracking (unless you can be sure no pseudonymised data will be collected before being asked for consent).
There are a number of tools/script to help with this, most of them I’ve looked at cost money but Civic UK offers a community version of Cookie Control for free that they say is “GDPR compliant” (if your legal basis is consent, then you’ll need to log in and accept their data processing agreement for the logging consent option to take effect).
Cookie control allows you to present the user with cookie categories, giving them the ability to pick and choose the groups of cookies you store – which is definitely in the spirit of GDPR.
12 – Update your privacy policy
If your privacy policy isn’t already, then make sure it’s clear, understandable and concise. GDPR gives you the perfect opportunity to sort it out!
This article from eConsultancy gives some good tips and examples for writing good privacy policies with GDPR in mind.- Explain your reason for collecting analytics data, but also mention some of the safeguards and settings you’ve implemented.
- Explain that you’ve anonymised the IP address as soon as technically possible so that it doesn’t even get processed by Google.
- Explain the data retention settings you’ve chosen, so they know how long data will be kept. Be honest and open.
- You should also have some kind of version control for your policy and consent texts. It’s good practice (perhaps even necessary) to keep a record of what was presented to a person when they consented to your use of analytics as GDPR requires informed explicit consent. So keep a version each time you update them!
Privacy by design
Congratulations on making it through all 12 points!
If while working though this checklist you discovered that you have collected personal information or pseudonymised data and you don’t have records of consent for that data or some other legal basis to be processing it, then you should consider deleting the analytics property and start again with a new one.
That may sound drastic, but it’s a pretty certain way of wiping the slate clean. Starting with a new property gives you the opportunity to implement privacy by design in your analytics collection.
The Journey to Compliance
So there you have it, that’s my list of 12 action points that I’ve gathered together during my work on the journey to GDPR compliance with Google Analytics. Have I missed anything? Anything I’ve got wrong? There are still a lot of uncertainties, even mysteries, around what needs to be done with regard to web analytics – even at this late stage – so I’d be really appreciate any feedback.
Good luck!