[Updated 2019]Do you need user consent to enable Google Analytics for EU people? The answer is yes. It used to be more complicated (as previous iterations of this article will show), but now there is no debate. You need affirmative consent before turning on Google Analytics.

Why?

It’s because of the ePrivacy Directive and not the GDPR.

The ePrivacy Directive (ePD) is an EU Directive that is implemented within each EU country, such as through the PECR in the UK. The ePD says that processing and storing data on an user’s machine is only permitted for specific reasons, such as providing the website/service you ask for, providing security or allowing the website to work, or if you provide consent. As such, anything that isn’t really necessary or essential requires consent from the user. And that includes tracking, such as with Google Analytics, or even a first party analytics tool that you run yourself but still relies on unique end user tracking with cookies.

The GDPR doesn’t provide any input here on you needing consent, but does add clarity on what “consent” itself is. Previously people had used notions of “implied” consent, with websites seeing a user reading or clicking away a cookie banner as the user implying their consent for the processing. But the GDPR requires affirmative actions for consent to be valid, and once the DPA’s (such as the ICO) accepted this, they dictated that ePD consent must follow suit. All this means that until a user affirmatively and freely consents to analytics, a website cannot load them. (Not great if you want to measure the first page load.)

What Does the UK ICO say?

Consent required.
You are likely to view analytics as ‘strictly necessary’ because of the information they provide about how visitors engage with your service.
However, you cannot use the strictly necessary exemption for these. Consent is required because analytics cookies are not strictly necessary to provide the service that the user requests. For example, the user can access your online service whether analytics cookies are enabled or not.
If you use device fingerprinting for analytics instead of or alongside cookies, you should note that doing so is not exempt from the consent requirements either.

https://ico.org.uk/for-organisations/guide-to-pecr/guidance-on-the-use-of-cookies-and-similar-technologies/how-do-we-comply-with-the-cookie-rules/#comply15

---

N.B. The remainder of this article shown below is old and out-of-date. It was correct pre-2019 when there was still significant “wiggle room” between the various EU regulators’ guidance and that of the EDPB (formerly WP29). Feel free to read what I wrote to give you a feel of why this has been a contentious topic, and why many will still argue for GA not needing affirmative consent.

Two Regimes

Firstly, we need to consider that both the GDPR and the ePrivacy Directive implementations are in play here. So we have GDPR regulating anything involving the processing of personal data. And we have each country’s implementation of the 2009 ePrivacy Directive (ePD), e.g. in the UK the PECR, providing the rules on electronic communications whether there is personal data involved or not. So that’s one GDPR and 28 ePrivacy sets of rules – one for each EU country. Admittedly most of the ePD implementations are similar, but how they are interpreted by each regulator, and more importantly, how they are enforced by each regulator are key factors to consider. If you have a service that has users across the EU then think broad and start with the source – the ePD.

The need for consent for cookies and similar technologies is a generally held principle within the ePD, but there are exemptions noted. The ePD states in Article 5.3:

Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

DIRECTIVE 2002/58/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 12 July 2002 (updated in 2009) – Article 5.3
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:02002L0058-20091219

So what does this mean in the real world, especially for a piece of technology ten years later? Let’s start with looking at the mechanics of Google Analytics.

Google Analytics – A Summary

Google Analytics (GA) is Google’s SaaS product for collecting, storing and analysing web traffic data to help you understand how people are using your website. You load a tracker script onto your webpage and this sends information, such as which links you click on, directly back to Google. Google states that it acts as a data processor for GA – acting on behalf of the website (the data controller). In turn, Google has no rights over that data to use it for other Google purposes, such as advertising or tracking across other services.

Is Google Really a Data Processor?

If you read Google’s terms and documentation, it clearly states that it is indeed a data processor. The more cynical amongst us might find that hard to believe in light of privacy compliance violations as determined by the likes of the CNIL. Many do not trust Google and believe that they will use your data for other purposes without your permission.

Your opinion on this is important, since if you think that Google cannot be trusted to act solely under your instruction then you must not treat Google as a data processor. If however you take Google on their word and find no evidence to the contrary then Google is your data processor for GA.

This is important as the data processor designation opens GA up to potentially not needing consent.

Since we’re here to focus on the rules and what contractual terms we have on paper, let’s assume that Google is indeed a data processor when providing GA.

Personal Data or Not?

GA is a very impressive product and can track a lot of information, from IP addresses and browsing clicks to recording form entries and analysing marketing campaign success. Here you need to decide if you want to take a cautious road and put it into an “anonymous” mode or go all out and collect user identifiable data. If you go with anonymous, you have the ability to not need consent.

In 2012 the WP29 (think data protection referee association of the EU pre-GDPR) produced a document “Opinion 04/2012 on Cookie Consent Exemption” to discuss what cookies, services and scenarios required consent and which could have an exemption to consent. Most things fell into one camp or another (consent needed or no consent needed), but one outlier was the mention of “First Party Analytics” in section 4.3. By “First Party”, the WP29 mean something very different to what 99% of us think of as first party. They mean (as described in section 2.3) the website or a party acting on its behalf (e.g. a data processor). So GA would count as a first party here.

In this section 4.3, the WP29 states how ordinarily analytics would require consent, since it’s a tool that isn’t explicitly requested by the user and thus not “strictly necessary” to provide the website, and therefore doesn’t qualify for a consent exemption. Crucially, they then say that first party analytics could instead use an “opt-out” mechanism if the data is anonymised and service information clearly stated in the website’s privacy policy. Here’s the full quote:

However, the Working Party considers that first party analytics cookies are not likely to create a privacy risk when they are strictly limited to first party aggregated statistical purposes and when they are used by websites that already provide clear information about these cookies in their privacy policy as well as adequate privacy safeguards. Such safeguards are expected to include a user friendly mechanism to opt-out from any data collection and comprehensive anonymization mechanisms that are applied to other collected identifiable information such as IP addresses.

WP29 – Opinion 04/2012 on Cookie Consent Exemption – Section 4.3
https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf

To restate this, the WP29 opinion here is that you can have Google Analytics enabled by default, without the need for consent as long as you:

• Provide clear information about GA in the website privacy policy.
• Provide an opt-out (e.g. pre-ticked tickbox with the ability to untick it).
• Anonymise the data sent to Google from the web browser.
• Are happy that Google is acting as a data processor.

The more technical amongst you will wonder how any anonymisation can work since the browser will still send data to Google directly and that will involve disclosing the user’s IP address in the traffic flow, even if not in the payload of the GA data. This is true, but since Google is acting as a data processor, the user’s IP address being personal data doesn’t impact anything because Google is under the direct instruction of the website data controller. Google has direct permission to use that IP address for receiving the GA data but not for anything else involving the user’s website browsing behaviour.

Anonymisation in Action

The principles of anonymising GA are that you must set GA to anonymise the client IP address (by setting anonymizeIp to true) and must ensure that GA doesn’t capture data in URLs, forms or fields on your website that could help identify an individual user. AnonymizeIp clears the last octet of the IP address, so if your IP address is 111.122.133.144, the GA script in your browser will only send the 111.122.133 part to Google. This means that your GA dashboard will only show users’ geographic location at a country level and not a city or district level. Once you’ve enabled the anonymizeIp setting, you can see it in action on your own site (or someone else’s, such as carlgottlieb.com or ico.org.uk). Follow this procedure to take a look:

1. Open Chrome, press F12 to open Developer Tools (or right click and select “Inspect”)
2. Select the “Network” tab.
3. Load your website of choice (e.g. this website or https://ico.org.uk)
4. Click the “Name” column to order the results by name
5. Find the line that starts with “collect?” and click on that line. This is the Google Analytics request, sending data from your web browser to Google.
6. On the right, click on the Headers tab (if it’s not already open)
7. Scroll down to the “Query String Parameters” and you’ll see the various pieces of data being sent, including a an “api:1”. If you see that, then the AnonymizeIp function is enabled.

This website (https://carlgottlieb.com) uses the anonymizeIp setting to enable GA once the cookie banner has been accepted, giving users the ability to opt out. I could have set this to enable before the banner is accepted but I personally prefer a more informed choice for people on this privacy focused website.

What About Non-Anonymised Google Analytics?

Okay, so you want to capture some personal data and record user analytics in finer detail. There are lots of good reasons why you might want to do this. But you’re now outside of the WP29 anonymised opt-out scenario, so you will need consent from the user. And this consent needs to be captured before you turn on GA. That means a user gets to see your cookie banner, make an informed choice of whether to have GA active or inactive, and only then can it be enabled. If you ever notice that GA is enabled before you accept a cookie banner (like currently on the website of the law firm Fieldfisher or the ICO website), they may very well be using the anonymised opt-out exemption, and thus don’t need consent to enable it.

Edho Pratama