Google Analytics and GDPR: Is it Compliant?
We’re just a month out from GDPR enforcement. There’s a lot to do, and a lot we still have questions about.
A big one:
How can you ensure your Google Analytics tracking is compliant with GDPR? Or the coming ePrivacy Regulations legislation?
The short answer:
Well, no one knows for sure.
Sincerely: right now, cookies, anonymized tracking—a lot of it is about to change, in a very big way. But the “how” behind it all, isn’t quite finalized.
BUT wait—before you go. Before you dash away from this article thinking: “god, what a waste of a click”—we know what GDPR restricts (coming May 2018). And we have draft legislation on what likely could become the new ePrivacy Regulations legislation.
And that gives us a solid foundation for how you can start readying yourself for the big changes coming to analytics.
Remind me. GDPR. I care because…?
Money!
And fairness and transparency and a shift towards using and storing data responsibly.
But also, yeah—noncompliance with GDPR means big fines.
Of course, this doesn’t seem like anything new. Europe has always had rules about how one can process the data of its citizens. But they varied by country. And the last piece of union-wide data regulation legislation hadn’t been updated since the 1990s.
GDPR makes things clearer, and stricter, and expands the legislative scope. Now, if you’re based in the EU, store data in the EU, or collect ANY personal data, from ANY EU citizens—you have to follow the new rules.
So let’s talk analytics compliance, shall we?
First off, some good news:
GDPR has a lot to say about consent, and personal data. And it can mostly be distilled to this: if you’re going to use someone’s personal data—you have to ask, and they have to give you the “okay.”
(And they have to be able to redact that “okay. And the terms have to be given with clear language. And they have to be able to view the data that they gave you the “okay” about, and….that’s a process for another article).
Personal data now means any bit of data that you could use to identify or re-identify an individual.
So what does this have to do with Google Analytics?
Well ideally, you shouldn’t be storing personal data in GA anyway.
It’s against their terms of service.
That means your account should be clear of: usernames sent in page URLs, phone numbers captured from form completions, email addresses that can be used as custom identifiers in custom dimensions.
Zip codes, too, can be linked to specific users—when coupled with pages visited, and segmented down to small groups. Those should stay out of your custom dimensions as well.
Really, anything that can be clearly used to identify the “who” behind a data subject—even if it’s hard puzzle to piece together, is personal data.
So your account. It’s clear of those?
Great.
Now this is where it gets (potentially) tricky.
Some less good news:
There are a few potential fields in your Google Analytics, which aren’t considered “no-go”s for Google—but are definitely “personal data” as defined by GDPR.
Amongst them…
- Long URLs (if you can use them to identify a specific user)
- IP Addresses
We’ll go through both of these, and discuss how you can make sure your bases are covered.
Long URLs / Parameters
Usually, long URLs aren’t too much a cause for concern. The only time you’d likely see your URL serve as a personal identifier is if they contain multiple user data inputs.
Sometimes you see these on forms. A user submits a form or survey, detailing, for example, their age, location, and gender. They get directed to a URL like this:
[www.notcompliant.com/form?gender=male&birthdate=31-12-1980&location=Iowa_City]
Then, in GA, this data can be linked with the user who visited that URL—and you can potentially pull out the “who” behind the “anonymous” input.
Luckily these are rare, and pretty easy to manage.
Shortening any questionable links is your best bet for avoiding the issue altogether.
But you might also have parameters that directly capture personal data.
What if your plugin, or form—takes the name and email, and uses it for a field prefill? Or a landing page personalization? Does this get stored—or create a custom URL that finds its way to Google Analytics?
Then you’re storing personal data.
Eliminating parameters
There are a few built-in ways GA allows you to exclude parameters.
Excluding at the View Level:
As a GA Admin you can exclude parameters by heading to View -> Filters. There you should see an option for: “Exclude URL Query Parameters”.
First inventory what parameters you use (“name”, “email,” etc)—and enter each one, separated by a comma. Keep monitoring the parameters for new additions in the future. This method is manual—and only works as well as you’re understanding of the parameters you store.
Something to note here: If you have parameters that you send to dimensions—this will no longer work, if you’re excluding those parameters. The “Exclude URL Query Parameters” setting is processed before filters.
Excluding at the Filter Level:
Another option is to filter out parameters, using the Search & Replace option from: Administration -> View -> Filters -> Search & Replace.
Use this by for example by adding \?.* basically removing any query strong after the main URL.
(This should also help filter out your pesky long URLs).
If you use other filters to send things to dimensions this filter, “Search & Replace” option, is handy. When placed on the bottom of your filter list, your other filters should still work. Your parameters will be cleaned, after these first few filters run.
This is also a good way to get a handle on what parameters you may have lurking around.
Use Search & Replace -> Request RUI -> Search \?.* ->
When verifying the Filter, you might find lots of nasty surprises.
Once done, you will find your new parameter filter in the list of filters on your view.
IP addresses:
Anonymizing your IP addresses in programs like Google Analytics has long been best practice in countries with strict data protection laws (like Germany). Now, it’s key to keeping your analytics GDPR compliant.
The problem here arises from a technicality. Customer IP addresses are not stored in your GA database, and they’re not accessible to any client specifically. But—they can be accessed by a Google employee, and they do qualify as personal identifying information. So even if you don’t have access to your visitors IP addresses—you need to make sure they’re are anonymized.
Eliminating IP Addresses:
Luckily, Google has a lot of documentation on this. And a handy plugin—which you should add to your tracking code, everywhere it exists onsite.
This _anonymizeIP function takes the user’s IP and masks it, setting the last few digits to zero. This process starts as soon as the data is received by the Google Analytics Collection Network—meaning that personal data is never stored.
A heads up: this might make your geographic reporting slightly less accurate. But it’s the price worth paying if you hope to avoid those hefty noncompliance fines.
Cookies:
If you’re in Europe (or visiting a European website)—you’ve likely seen the ubiquitous cookie popups.
You know: “This website uses cookies to ensure you get the best experience. Read More.”
That’s called a soft-opt in. It’s the “we told you, and you’re still browsing, so you consent” route to consent.
And according to GDPR—soft opt-ins are no longer on the table. Implied consent doesn’t count.
Consent needs to be affirmative, and unambiguous. If personal data is involved, users have to check that box, or click that button that says “I’m okay with this.”
So the cookie pop ups of the future might look a little more like this example, from ionetrust.com.
And only when someone says “Activate or I consent” do you get to start adding cookies.
According to GDPR, analytics cookies with identifiers ARE personal data. But all cookies are not created equal. It may be possible that some require user consent, whereas others do not. The particulars will be determined by the new ePrivacy Regulations—once they’re approved. For now, we have draft 15333, which has an exception for web analytics software.
“Cookies can also be a legitimate and useful tool, for example, in assessing the effectiveness of a delivered information society service, for example by helping to measure to the numbers of end-users visiting a website, certain pages of a website or the number of end-users of an application.”
Analytics programs like Google Analytics “assess the effectiveness of a delivered information society service.” but also are connected to many third party systems to pass through data to other Google services and so while ePrivacy Regulations updates are still in draft right now, there’s a possibility consent will not be required for a cleaned up version of Google Analytics.
Eliminating (Definitely Non-Compliant) Cookies:
If you’re using Google Analytics’ User ID feature—stop, and clear your data. Unique identifiers, like the User ID feature (which tracks individual users across devices and sessions)—are explicitly considered personal data, and not subject to this exception.
It also might be in your best interest to turn off Client ID—which is an optional tracking feature in Google Analytics. It, similar to IP addresses, anonymously tracks “browser instances”—to count recurring versus new site visitors.
There’s some really good news regarding this process.
GDPR applies to all the data you have at your disposal—not just all the data you collect after May 25th.
Which means, technically, if you used to collect User IDs—you’re in trouble. Because there wasn’t a easy way to selectively delete user data in the GA platform. It’d have to be wiped across the board.
But a recent, pre-GDPR product release is changing that.
From the team:
“Before May 25, we will also introduce a new user deletion tool that allows you to manage the deletion of all data associated with an individual user (e.g. site visitor) from your Google Analytics and/or Analytics 360 properties. This new automated tool will work based on any of the common identifiers sent to Analytics Client ID (i.e. standard Google Analytics first party cookie), User ID (if enabled), or App Instance ID (if using Google Analytics for Firebase).”
They’ll be releasing news regarding this update on their development page here. If you’ve got some deleting to do, keep an eye out.
Permissions:
So we’ve gone over how to make sure your data collection is compliant.
But now you’ve got some data protecting to do.
If you regularly dole out GA permissions—to agencies, or contractors, or now-former employees—it’s best to check regularly who has access to your account.
Some common sense rules apply here.
Do you remember who john_1954@gmail.com is after a while? It might be better to make a “business email only” access policy for your account.
Google Analytics Organization creates some solid infrastructure for doing just that. It allows you to link any associated GA accounts under one roof—and it offers some additional powers to the organizations admin. You can create policies, see who’s logged in, and easily manage product users and permissions.
Turning on GA Organization is a pretty straight forward process. Google details how here. Below below the screenshot on how to find the initial setting.
To sum it up:
Google Analytics has already done us a lot of favors by maintaining a strict privacy policy—one that restricts the storage of personal data.
So keeping your analytics Google happy, and GDPR compliant, seem to go hand and hand.
To breathe easy though, we could all stand to anonymize our IPs, double check our Long URLs, delete our parameters, and remove our stored User IDs. And keep GDPR in mind—throughout every phase of our user journey.
Resources:
The Google Analytics Terms of Use
Analytics.js anonymizeIP Google help
Android anonymizeIP Google help
