GDPR, Google Analytics & You: 5 Steps to Update Your Website (#3 is easier than it sounds)
Disclaimer: We’re not lawyers. This article is based on our research and interpretation of the General Data Protection Regulation (GDPR) and other “e-privacy” regulations. PLEASE talk to your own legal counsel that specializes in privacy laws!
Confused about GDPR and Google Analytics? This article will help. You’ll probably have to make a few small changes to your website and/or your Google Analytics tracking. Let’s dive in.
For the purposes of this article, we need to identify 2 groups: data controller and data processor.
- Data Controller: This is you (or your organization). You control which data is sent to Google Analytics.
- Data Processor: This is Google Analytics, or more broadly, Google, because they process the data.
Technically, the Data Processor is the one bound by new legal obligations to conform to the EU GDPR. But there’s still plenty that you need to know, and maybe do.
Google is well aware of this development, and they’ve even set up their own Privacy Compliance website. They say that they’re “working hard to prepare for the EU’s General Data Protection Regulation.
It’s a pretty safe bet that, given how important Google Analytics is to—like—the entire internet, it will be fully compliant by May 25, 2018. And as part of that, Google will have to provide its users with a data processing agreement—you’ll need to accept the agreement.
TO DO: How to Make Your Google Analytics GDPR Compliant
First and foremost, you need to be sure of what data you are and are not sending to Google Analytics’ servers.
Ultimately the data will be handled by Google on their servers, but they have policies—and GDPR has regulations—about which information you can send them in the first place.
#1) Personally Identifiable Information (PII)
Collecting any sort of Personally Identifiable Information (PII) is—and has always been—against the Google Analytics Terms of Service. (This is true for both the standard/free GA and the paid Google Analytics 360 solution.)
Here’s how to check your website and GA data for PII:
Page URLs, Page Titles, etc
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 does not contain PII. Most often this comes in the form of Event Tracking. If your
_gaq.push() functions send an eventLabel containing the user’s email address (for example), that’s bad news.
For purposes of this article—about Google Analytics and GDPR—this applies to form data that is also collected by GA. If you store this PII yourself or submit to any other trackers, be aware that GDOR has implications for those services/servers too.[callout]Note: It’s important to note that filtering out PII via Google Analytics filters is not good enough. You must address this at the code level to prevent the data from ever being sent to Google Analytics.[/callout]
#2) Anonymize IP Addresses
The GDPR legislation considers IP address to be personally-identifiable. I happen to disagree with that, but they didn’t ask my opinion.
Google doesn’t reveal users’ IP address in its reporting by default, but they do use them to provide geolocation data, which is reported.
So, to be safe, we recommend enabling Analytics’ standard IP Anonymization feature.
If you use Google Tag Manager
If you use Google Tag Manager, you can make this change in the GTM interface. No code change is required.
Adjust your tag or Google Analytics Settings variable:
- Go to More Settings -> Fields to Set
- Add a new field called ‘
anonymizeIp’ and give it a value of ‘
If you use Google Analytics Snippet
If you don’t use GTM, you may need to edit the code directly, but how to edit the code depends on which version of GA you use.
(Don’t you love this stuff?)
Analytics.js “Universal Analytics” version
This is the GDPR anonymous IP address command line for the newest version of Google Analytics snippet.
Google deprecated this version in 2016, but lots of websites still use it. (Don’t worry, it still works just fine. But you do miss out on some new features.)
What does this code do?
This code tells Google to anonymize the IP address. But what does that mean?
It means that they’ll remove the last octet of the IP address (your IP becomes 188.8.131.52 — where the last portion/octet is replaced with a ‘0’).
Here’s what Google’s documentation says—
…the last octet of the user IP address is set to zero while still in memory.
For example, an IP address of 184.108.40.206 would be changed to 220.127.116.11.
If the IP address is an IPv6 address, the last 80 of the 128 bits are set to zero.
(The emphasis and pretty colors were added by me!)
The documentation goes on to explain that the anonymization happens as early as possible in the data collection process:
Only after this anonymization process is the request written to disk for processing.
If the IP anonymization method is used, then at no time is the full IP address written to disk.
These two lines are the important parts. This is why anonymization is GDPR-compliant.
They even provide this handy dandy graphic to illustrate how it works:
Are there any downsides?
Unfortunately yes. Well…kinda.
This will have a small impact on your data. It’s up to you whether or not that’s a downside.
Like zip codes, area codes, and bank routing numbers, IP addresses are location-specific. That means that for Analytics purposes, they’re used in geo-locating your users.
When you remove the last octet (set the last few digits to zero), you remove the most specific part of that data. The result is that your accuracy of your geographic reporting is slightly reduced.
Just how reduced?
Well, according to ConversionWorks, not badly.
81% of the visits have less than 50 km [~31 miles] discrepancy (or no discrepancy at all).
There are some statistical outliers of course. But for the most part, your anonymized, GDPR-compliant IP address data can narrow down to the city, but not to the city block.
#3) Pseudonymous Identifiers
Your implementation of Google Analytics could already be using pseudonymous identifiers.
What the fluff does that mean?
IAPP to the rescue. IAPP is a not-for-profit “global information privacy community and resource” that educates and advocates for the privacy profession globally.
Here’s what they say about pseudonymization:
The GDPR introduces a new concept in European data protection law – “pseudonymization” – for a process rendering data neither anonymous nor directly identifying.
Pseudonymization is the separation of data from direct identifiers so that linkage to an identity is not possible without additional information that is held separately.
So it’s not directly identifiable. But it’s not-not identifiable, either.
Pseudonyms are good.
The whole point of GDPR is to allow users to be more private. Using pseudonyms improves their privacy.
In Article 5, the GDPR defines pseudonymization as
“the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information”
They go on to talk about storing that information securely. But the point is the same: one step below a-nonymous is psuedo-nonymous.
Pseudonyms are good, but not good enough.
Pseudonymization alone is not enough to save you from GDPR requirements, but the GDPR does recognize that it “can reduce risks to the data subjects concerned and help controllers and processors meet their data-protection obligations.”
So that’s something.
It also created some strong incentives for Data Controllers (that’s you, remember?) to pseudonymize personal data.
Under the GDPR, pseudonymization can help you:
- Fulfill its data security obligations
- Safeguard personal data for scientific, historical, and statistical purposes
- Mitigate its breach notification obligations
Examples of Pseudonymous Identifiers
This is info that could be used to identify individuals if you have enough data to connect the dots. Here are some common examples:
Probably an alphanumeric database ID. You don’t want this to be plain-text PII such as email, username, etc.
Hashed/Encrypted Data (email, e.g.)
Hashing and encrypting are different, but both count as pseudonyms. If you store emails, etc., and you plan to use hashing, Google has some criteria:
“Google has a minimum hashing requirement of SHA256 and strongly recommends the use of a salt, minimum 8 characters.”
Technically, this is a pseudonymous identifier since when linked with another data source, it can identify an individual customer or user. If you store these IDs, they should probably be alphanumeric IDs.[callout]
In both cases, the language used needs to be clear (no technical or legal terms) and answer these questions:
- What data is collected?
- How it will be used?
According to Blast Analytics and Marketing, Google announced at their Analytics Superweek Summit that they’ll soon allow for User ID/Client ID data deletion.
Frankly, lots of websites probably never had one at all. That has to change.
- 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
Here’s where the rubber meets the road for GDPR. The big takeaway from the whole legislative initiative is this:
If EU citizens don’t want to be tracked online, they don’t have to be.
This means that we, as the Data Controllers, are now legally obligated to let them decide.
And “we’re gonna track you unless you say no” is not good enough. It has to be “can we track you? Please click yes or no.”[callout]Remember: ask a lawyer. We’re just marketing nerds.[/callout]
What to ask your lawyer
If you are collecting User ID or other pseudonymous identifiers, you may need to gain consent from the user.
If so, this consent needs to be explicit (opt-in). All those cookie notices stating that, if you proceed to use the site, you consent? Yea not anymore. That’s not considered consent anymore.
So that’s the question: do I need to gain consent from my users?
Delay Google Analytics loading
Depending on what your lawyer says, you’ll need to ask users for their permission clearly and most importantly, before Google Analytics executes.
Most commonly, this looks like an overlay modal/popup that asks the user for permission. If the user clicks “yes” or “opt-in,” either the page reloads or the Google Analytics (and/or other martech scripts) start to run.
GDPR requires that you keep a record of users’ opt-ins, in order to prove that consent has been given.
Typically this comes in the form of some type of application or security log that provides an audit trail of the actions taken against data from the time of its creation to its erasure.
Our solution to this (so far) is to track this “yes” consent in Google Analytics as an event, and to record it in our own database, attached the Google Analytics Client and/or User ID.
GDPR Definitions & Terminology
For the purposes of the GDPR law, Regulation (EU) 2016/679 uses these definitions. We kept the spelling in the original British-English, because—well—we’re not sure if we’re allowed to change it.
Here’s where we got this info→ Check out the original, which claims to be “official.”
- any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person
- any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction
restriction of processing
- the marking of stored personal data with the aim of limiting their processing in the future
- any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements
- the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person
- any structured set of personal data which are accessible according to specific criteria, whether centralised, decentralised or dispersed on a functional or geographical basis
- the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law
- a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller
- a natural or legal person, public authority, agency or another body, to which the personal data are disclosed, whether a third party or not. However, public authorities which may receive personal data in the framework of a particular inquiry in accordance with Union or Member State law shall not be regarded as recipients; the processing of those data by those public authorities shall be in compliance with the applicable data protection rules according to the purposes of the processing
- a natural or legal person, public authority, agency or body other than the data subject, controller, processor and persons who, under the direct authority of the controller or processor, are authorised to process personal data
consent of the data subject
- any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;
personal data breach
- a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed
- personal data relating to the inherited or acquired genetic characteristics of a natural person which give unique information about the physiology or the health of that natural person and which result, in particular, from an analysis of a biological sample from the natural person in question
- personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data
data concerning health
- personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status
- as regards a controller with establishments in more than one Member State, the place of its central administration in the Union, unless the decisions on the purposes and means of the processing of personal data are taken in another establishment of the controller in the Union and the latter establishment has the power to have such decisions implemented, in which case the establishment having taken such decisions is to be considered to be the main establishment;
- as regards a processor with establishments in more than one Member State, the place of its central administration in the Union, or, if the processor has no central administration in the Union, the establishment of the processor in the Union where the main processing activities in the context of the activities of an establishment of the processor take place to the extent that the processor is subject to specific obligations under this Regulation;
- a natural or legal person established in the Union who, designated by the controller or processor in writing pursuant to Article 27, represents the controller or processor with regard to their respective obligations under this Regulation
- a natural or legal person engaged in an economic activity, irrespective of its legal form, including partnerships or associations regularly engaged in an economic activity
group of undertakings
- a controlling undertaking and its controlled undertakings
binding corporate rules
- personal data protection policies which are adhered to by a controller or processor established on the territory of a Member State for transfers or a set of transfers of personal data to a controller or processor in one or more third countries within a group of undertakings, or group of enterprises engaged in a joint economic activity
- an independent public authority which is established by a Member State pursuant to Article 51
supervisory authority concerned
- a supervisory authority which is concerned by the processing of personal data because:
- the controller or processor is established on the territory of the Member State of that supervisory authority;
- data subjects residing in the Member State of that supervisory authority are substantially affected or likely to be substantially affected by the processing; or
- a complaint has been lodged with that supervisory authority;
- processing of personal data which takes place in the context of the activities of establishments in more than one Member State of a controller or processor in the Union where the controller or processor is established in more than one Member State; or
- processing of personal data which takes place in the context of the activities of a single establishment of a controller or processor in the Union but which substantially affects or is likely to substantially affect data subjects in more than one Member State.
relevant and reasoned objection
- an objection to a draft decision as to whether there is an infringement of this Regulation, or whether envisaged action in relation to the controller or processor complies with this Regulation, which clearly demonstrates the significance of the risks posed by the draft decision as regards the fundamental rights and freedoms of data subjects and, where applicable, the free flow of personal data within the Union
information society service
- a service as defined in point (b) of Article 1(1) of Directive (EU) 2015/1535 of the European Parliament and of the Council (¹)
- an organisation and its subordinate bodies governed by public international law, or any other body which is set up by, or on the basis of, an agreement between two or more countries.
What about you?
These 5 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 complicated. Tell us about your struggles! Or, if you need a hand— give us a call!