Blast Analytics and Marketing

Analytics Blog

Supporting Leaders to EVOLVE

5 Actionable Steps to GDPR Compliance with Google Analytics

February 16, 2018

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 consent 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 — 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.

#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 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.

tealium privacy widget for

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?

    • @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.

  • 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!

    • @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.

    • I can not see that irony.

      If there is no cookie, there is no approval. Why would your store opt-out in a cookie? You would only store opt-in, as that permission can be used in the future. As soon as the opt-in cookie disappears (or has been removed by the user, as you have to give them the ability to do so) you have to request opt-in again.

      No Cookie irony detected here.

      • Kieran Metcalfe

        The issue is that without a cookie, you can’t distuingush between “I’ve not been asked” and “I’ve said No”.

        That would mean every visit to every page would result in a consent popup, reducing the usability of the site considerably.

        It’s important to note that the consent only applies to ‘non-essential cookies’ anyway – functional cookies pertaining to making the site work are allowed. I’d suggest that a ‘no analytics’ cookie is part of the site functionality.

        • I agree. Plus, the cookie you store is not an ‘online identifier’ if you are simply storing the preference of the user’s consent (yes/no). There’s no problem with setting cookies; it is how they are used.

        • MileHighSi

          You could use local storage to save the preference?

        • MileHighSi

          You could use localstorage to save the preference? HTML localStorage is covered under GDPR, too, but is much less prone to being used maliciously. The contents don’t get sent in the headers of every request, for a start. Used as a simple device to save a yes/no preference, especially with it being to comply with GDPR, will not get you in trouble and reduces any irony (if irony is an actual concern – and I’m not sure why it should be in a legal sense).

  • 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.

    • @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: 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.

    • You might have problems with that approach, as based on the GDPR you are not allowed to force users to provide personal information, unless it is required to provide your service.

      So if you charge for access to your website, then you would be OK. But to force a user to provide personal details so they can browse your website appears to be illegal under the GDPR, as it is not required as part of the service you offer.

      So let’s hope collecting anonymous analytics will become exempt.

  • 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…”

    • @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.

      • 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.

      • Manvi Agarwal

        Hey Joe, do you know whom can I contact in order to get their Data Processing Agreement for Google Analytics, as you mentioned in your post above. Thanks

        • @manvi_agarwal:disqus If you are using the free version of GA or the paid GA 360 version direct from Google, then you can accept the DPA by going to ‘Account Settings’ under the Admin section of GA. If you purchased GA 360 from a reseller (such as Blast), then you should receive a DPA with that reseller. More information:

  • 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

    Littledata has also developed an audit check for finding PII in page URLs, titles and events:

    • @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.

  • @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.

  • 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?

    • @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.

      • mshpungin

        This strikes me as an odd approach, given that GEO IP Lookup requires an identifier (IP) specified in your article?

        • @maxess:disqus Point taken, but this is about data collection and usage of that data (a geo-ip lookup does not imply data being collected; use a service for this that aligns with your privacy policy). You must have reasonable methods in place to comply with GDPR. This is similar to how you should be capturing consent (and lack of consent).

          • mshpungin

            Good point on the difference there between storage vs. immediate use – hopefully all this stuff gets more clear as GDPR moves forward (thanks for the article!)

  • 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.

    • Amen. Preach brother! If the EU is this concerned about privacy, they could provide free/low cost VPNs to their member countries rather than threaten to destroy small businesses with absurd and unenforceable requirements.

    • roger’d ✓ᵛᵉʳᶦᶠᶦᵉᵈ

      I couldn’t have said it better myself. I’m just glad that I’m not a European trying to browse the web … it’s going to be an awfully annoying and cumbersome experience for them to have to deal with complex consent dialogues on every website they visit. Their online experience is about to suck really hard IMO. I won’t be complaining about the bureaucracy out here in the US anytime soon…

  • Erik Mork-Barrett

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

    • @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.

      • Stacey Gluchman

        @joechristopher:disqus Any recommendations for specific Geo IP lookup services? IPs seem tricky, as they aren’t always accurate as to the user’s location. This is the brick wall we’re hitting at the moment.

        • @staceygluchman:disqus Yes, MaxMind is the most common one we use: If you are looking for something more server-side, if you use a service like CloudFlare, they can automatically append a HTTP Header with the country value and then you can access that in your server-side code.

          • disqus_N4R1mQ2nhr

            There’s a risk involved in just showing the overlay to just users in the EU. Any EU citizen is protected by GDPR no matter where they are located. If a EU citizen is visiting your website from the US or any other country outside the EU, you would still be subject to the GDPR.

          • @disqus_N4R1mQ2nhr:disqus My interpretation aligns with what this article states: That “GDPR stipulations only apply when personal data is collected from an individual person who is located in an EU country at the time the data is collected.” So technically, even non-EU citizens traveling within the EU would apply.

  • 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?

    • @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…

    • @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. 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.

  • Thankfully, Subsign has replaced the content of their post that they copied from this original post by Joe. It still has the URL with a Google Analytics reference but the post content no longer has any reference to Google Analytics.

  • Hi @[email protected]:disqus, this is a great post, thank you so much. Two questions:

    1. Will your suggested IP anonymization affect IP filters? I suspect I know the answer (it will trash them) but wanted to get your thoughts.

    2. Have you (or any other person) read the latest Data Processing Amendment Google wants GA admins to consent to? It’s under Account Settings. It’s 17 pages of legalese, have you seen a good summary of the key implications anywhere?

    • @erikmorkbarrett:disqus Thanks! Great questions.
      1) Yes, this would affect IP filters. You would want to filter out at the same granularity (last octet removed).
      2) I’m aware of Google’s DPA and have read through parts of it. I’m not aware of a good summary though. Let me know if you find anything 🙂

  • Aleah

    Can anyone share a privacy policy that’s GDPR-compliant? Thanks!

  • Balaji Naidu

    Interested to know your views on below situation. We are an hospitality based startup helping users & business to find extended stay hotels across united states. Now if any user travelling to united stated looking to book extended stay hotels in united states, so he searches in Google with keyword extended stay hotel in united states and our result popped up. Now i can see in one of your suggestion you suggested that even GA code should load after user confirms that they don’t have any problem but in this case as we are serving exclusively united state only we never know if any such user visit our website from Europe. Also if such user booked a hotel room from our website do we need to follow different rule (GDPR Compliance) for that particular email id?

    • @disqus_5MFQOzm6cX:disqus Thank you for the great question! Under GDPR, even if you are selling/providing a service that is targeted to your local market (US), the fact that a EU citizen may engage with your service is enough to state that you need to be compliant. Further, the data you collect (newsletter, bookings, etc) would be subjected to GDPR. Whether or not you need consent before firing Google Analytics is a decision you’ll have to make (if you aren’t using GA for things like remarketing lists, UserID collection, etc then you are certainly safer based on the definition of the unapproved, latest version of the EU Privacy Regulation).

  • Daniel Erik Kamen

    So the company I represent we have our own US based website and only ship in the US, show currency in US, language is english only but we do get some EU traffic. That being said our parent company is in Italy and they share the products which is where all Europe visitors should go for more info on our product. Is the US website still liable to comply? We incorporated here in the US (though the parent company is incorporated in Europe)

    • @danielerikkamen:disqus This is a tricky part about GDPR. Presumably if you don’t ship a product to the EU, then EU citizens really have no interest in being your customer and coming to your site right? There’s nothing to prevent them from going to the site, but they aren’t your customer. You would want to consult legal counsel on this sensitive topic, but in my ‘non-legal opinion’, you aren’t providing a good/service through your website to EU Citizens. One idea is to make it clearer upon entry (via popup) to send them to the EU parent company’s site if they do arrive to your site.

  • This is a great overview, but ultimately many of these requirements are absurd and unenforceable. Big data like Google or Microsoft will pretend to dance to whatever tune the EU calls, but ultimately they know it will fall apart because it’s untenable – even for companies in the EU. And… if the EU is this concerned with data privacy, they could start by providing free/low cost VPN services to their member citizens.

  • roger’d ✓ᵛᵉʳᶦᶠᶦᵉᵈ

    Thank you – This is the most clarity that I’ve gotten on the subject so far and believe me, I’ve been spending hours reading different articles.

    • @jickthehick:disqus Thanks for your comment! Yes, there’s a lot of information out there on GDPR and not many that are talking about this from a Digital Analytics perspective. Glad we could help!

  • John

    I operate a website in the US that is targeted to US users. If a EEA user comes onto the site, can GA identify them as a EEA user and not engage in further tracking of that user session? Would that comply with GDPR?

    • @disqus_aASi7JoMQy:disqus GA doesn’t have the built-in ability to not track certain users based on geographic location. They don’t know the user’s location until data is processed. You could use other methods to identify the geo-location of users and decide to just not fire GA tracking (nor other marketing tags) if the user is in the EU.

      • John

        Thanks, Joe. Can you suggest another method to identify the user location? We use DFP, and I believe that has the capability?

        • roger’d ✓ᵛᵉʳᶦᶠᶦᵉᵈ

          We use a GeoIP database from MaxMind to translate visitor IPs to Country codes. They also have an API to make real time calls. They have both free and paid versions of data to download, and so do other services such as IP2Location. It’s unfortunate that such a burden is forced on us as US-based publishers who never meant to target EU traffic to begin with.

  • Carlee C

    I have very little European Traffic, currently 2%. I do not sell products or services from my website, I am a personal Blog. I do however use Google Analytics to collect traffic numbers, a link to collect an email addresses for a newsletter and I also have Google Adsense. Is this something that even applies to a website owner with this type of setup? Thank you in advance.

    • @frugalandfunmom:disqus I’ll respond with my opinion, but please note that this is not legal advice towards what you should do. My opinion is that as a personal blog you likely don’t need to worry about GDPR. You probably aren’t collecting anything close to PII/pseudonymous data. A personal website/blog likely is not on the radar for enforcement.

      This being said, it is an opportunity to look at your own privacy policy and how you get consent from users for newsletter, etc. Laws could change in the US to be more aligned with GDPR eventually and despite many of the headaches perceived with GDPR, there’s a lot of good things out of it in terms of becoming more organized and aware of what data exists and how it is used.

      • Carlee C

        Thank you for this! I really appreciate your feedback. The positive has been I am redoing my privacy policy and having some work on my page to make it more secure!

  • ariacorrente

    As a possible workaround, if Google Analytics is configured with a fixed “clientId” (see ) no real personal ID will be sent. The data recorded by Google Analytics will be a lot less detailed but still better than nothing. Have someone tested this?

    • @ariacorrente:disqus Thank you for commenting. If I understand you correctly, if you pass in a fixed value (same value for all clients), then it will really mess with sessionization and other issues. In fact, there is a session hit limit in GA where after 500 hits in a session, they get discarded.

      Another idea I’ve heard about is to pass in a session ID instead of a persistent ID. The value of this is that you still have sessions, just not any data around Users. This can help with GDPR.

      • ariacorrente

        Thank you for you reply. I did not know about the limit of 500 hits per session, this makes my solution unviable.
        Tracking sessions instead of users is an interesting solution. It requires a little interpretation and I hope the lawyers will came to a positive solution.

  • @fikatown:disqus Great questions.
    1) Your campaign site may be subjected to GDPR beyond just GA if you also have other marketing tags and you use a user’s behavior to target them via other marketing campaigns, etc. Whether you need to deploy consent management prior to firing your GA tag, that is a tricky question. Under a strict lens of GDPR, the GA Client ID is a persistent cookie identifier and you need consent for this. Not everyone agrees on this, so it is up to you (or your legal consult) to decide what to do here.

    2) If I understand you correctly, the database ID refers to data in your system, but doesn’t necessarily relate back to an individual. GDPR is about tracking information about an individual.

    I don’t have enough context about your business to weigh in deeply on this, but if EU citizens are able to sign up for your service, you should be getting consent on things like: email newsletter, marketing tags, and potentially analytics tracking.

    3) Thank you for sharing the gtag() example. Most of our clients use GTM/tag management and so gtag() isn’t used that often in this scenario.

  • @jickthehick:disqus I like the way you are thinking about this. Technically, I think this works and avoids any type of data collection on a user where it is tied to a user. The issue, as you pointed out, is that every pageview ends up being its own user if GA can’t identify the same person across multiple pages (and I think this is a show-stopper for most people). There is also an option to pass in your own ‘clientId’ value, which could put you in control to do something like passing in a session identifier that is not a permanent cookie or record against the user’s multiple visits.

    Yet another method to consider, with certainly more technical overhead to implement, is to send data via measurement protocol (server-side). In this scenario, it is again, up to you, to build the clientId and perhaps map it to some sort of application session id.

    Then, as you stated, once you have consent, start sending data to GA as normal. So that it doesn’t impact my metrics of my data collection against the population where I do have consent… I would add a custom dimension with the consent status I can use to create a filtered View (with/without/combined).

    • roger’d ✓ᵛᵉʳᶦᶠᶦᵉᵈ

      Appreciate all of your feedback on this! The measurement protocol is definitely something for me to consider since we already use it in our outgoing email messages. And tracking consent status inside a custom dimension is also sound advice, as it could help to provide an accurate record if things were ever called into question. Thanks again Joe!

  • Alex

    Re: IP anonymization – Note that editing the code directly is different depending on whether you are using analytics.js or gtag.js
    Looking in my GA admin I am finding that only gtag.js is now available.
    I am not sure how gtag.js affects what is required for GDPR compliance as compared to older versions of GA code.

  • Martin Baker

    Typo on “Explicit content and transparency is required”, should be “Explicit consent and transparency is required”

    • @disqus_iToP5jUbOk:disqus Thank you reading with close attention and for pointing that out! We’ve corrected the typo.

  • teacher one

    How will this affect what we webmasters see in google analytics? If my users are now refusing to accept cookies will this not show a large drop in users? What about adwords? How will this affect my adwords account? Will my ads be shown as before? Less? To different people?

    • @disqus_sXjUH8oFbC:disqus If users are opting out of the analytics tag category, then you will see less traffic in GA. If most of your traffic is not from the EU, you can implement the opt-in mechanism to only show to EU traffic to reduce the impact. The key point here I would stress is that it is important to be transparent with your visitors and create an experience where they do want to opt-in, because they trust your brand. Regarding AdWords, if users are opted out, then you will have less data to personalize ads against.

  • Ben


    Something I am not really understanding here.
    If you set Google analytics to IP Anonymization, how can this affect the user’s privacy? Do we really need an optin for this? Every webmasters need to know if their websites are becoming popular and from which country, I mean this is a basic need. If we need an optin with IP Anonymization, then I am lost….. Now regarding Mailchimp, people optin in to register to a newsletter but is this enough? I find this new law very strange and extreme when you compare this to a shop in a town center that films your face and can find out who you are with the coupon cards and all these things you register to. I understand how it would apply strongly to websites like facebook that resell you details to make money but to poor websites like most of us have, it is sad…..

    • @disqus_TT3n29FruY:disqus When you enable IP anonymization, it removes the last octet (last portion) of the IP address, but still uses the rest of it. This means that instead of an ip like, GA uses just 123.123.123.* to perform geo-location. It reduces the accuracy down to the city level, but generally is accurate still at the country level.

      Regarding email newsletter subscriptions, you should make sure that this is a true opt-in. Meaning that if a user goes through your checkout that you don’t have the ‘subscribe to newsletter’ box pre-checked. Users must check the box.

      • Ben

        Thank you so much for the fast reply. Regarding the subscription, yes it is a true opt in, meaning that they add their email address in an optin widget, receive an email to confirm their optin and only then, I send them a newsletter. They can also unsubscribe any time they like. So in fact, as I am using Google analytics with the anonymization, I could imply show a popup saying something like “We uses cookies to ensure you get the best experience on our website” with a button “Got it” and a link to the privacy policy. I was trying to add a button to accept or remove cookies from Google analytics, a bit of a nightmare. If I could simply use the “Got it” popup way then it would be fantastic! Less headaches:-)

  • MIjal

    For a company that falls under the GDPR and collects data sets in one country but does not collect that same data in another… Is a consolidated privacy statement preferable, even if it referenced data sets not collected or used?

    • @disqus_yMsF9lfpDL:disqus All situations may be unique, but my suggestion is to work towards a consolidated privacy statement that clearly explains how your company approaches privacy. This reduces the complexity of managing and updating many separate policies over time. GDPR won’t be the last regulation you have to attend to, so think forward-looking.

  • MIjal

    Can you advise whether a consolidated privacy statement is in fact preferable, even if it references data sets not collected or used

  • Ed Truman

    I’ve read so many resources now and I am still NOT clear on what is means for the client ID and whether consent is mandatory for this? For sites I’ve seen that offer opt in – no one opts in. Therefore GA traffic just falls off a cliff.

    • @disqus_cgBVXLsnr7:disqus GDPR is complex and there’s various interpretations. Google’s latest guidance is that if you are not using the Advertising features (remarketing, etc) then you don’t need consent. I would add to that litmus test that if you are not collecting a UserID (or other personal identifier) and you are not using that data for behavioral targeting, then you may not need consent. Of course, things could change once the ePrivacy Regulation goes into effect (not yet finalized/released).

  • Philip William

    Hi Joe,

    I will be honest, much of what is written here is way above my head.

    I own a website, I am just a blogger in affiliate marketing.

    There has been a lot of human emotion and plenty of fall outs as to what is the right way.

    Here is what I have done:-

    EU COOKIE LAW PLUGIN – INSTALLED. <<<– THIS will or will NOT capture consent for Google Adsense Ads? <<<– THAT THERE, is my problem.

    I just started to see Adesense ads on my website. Then I go to my Adsense Account and now they are saying some mad stuff I can't make out.

    WordPress wants us to have the Plugin for Compliance. Now Adsense is saying something about all the different types of codes to use.

    I mean, what do I need to do to be compliant so people accept the use of data handling on my site so ads can be shown and I earn from them.

    I have gone through the UTTER SHAMBOLIC NIGHTMARE of Google Analytics throwing the responsibility on to people like by going through their GDPR compliance steps.

    I am lost. I updated my Privacy Policy Page. My PPP clearly states you accept cookies when you land on my site and interact with it in any way.

    So when people comment on my site they must tick a box so they accept GDPR handling of their data – why is this not enough – and if it is – why is Adsense alerting me to be compliant? I mean, if I was not already compliant, WHY did they approve my site for ads – IT MAKES NO SENSE!

    I am really sorry to drop all of this on you Joe, but you seem to have a better understanding than most, so I am desperate for your help.
    Those that have some understanding are not that helpful – they just keep on giving me flipping links to data I can't make out, I am not one of minutia!

    ULTIMATELY, could you PLEASESSSSSS do a post or tell me here, what exactly, step by step, I need to do have be sure to have PERSONALIZED Adsense Ads on my site, that I will be paid for so long I am compliant?

    I wonder if that alert in adsense is just there for everyone, compliant or not.

    Last question, if a site makes money with these ads, and that site is not compliant, will Adsense use that as an excuse not to pay website owners?

    THANK YOU VERY MUCH MARK ZUCKERBERG! – The rest of us now suffer.

    Looking forward to your response Joe. Any help here would be deeply appreciated.

    It just occurred to me, I was not asked for any acceptance to comment or handling of my data on this site – what is it am I missing? Oh, yes, I am in the EU – Wonderful Nightmare it is indeed.


    • @disqus_tfSMIB8H8K:disqus There are so many platforms and unique scenarios when it comes to websites, the marketing technologies used, etc. Based on your comment, it sounds like you are using as the WordPress Cookie Law plugin. If you work with a developer, they can better navigate the plugin features as you may have to put in extra code into WordPress around scripts that might fire ahead of consent (to prevent them from doing so). I’ve never used this plugin though, so I’m not able to fully advise on it.

      In short though, there is no one-click solution to GDPR compliance.

      I know you were hoping for a response with the exact steps for your scenario, but I’m unable to provide that. I do wish I was able to help you directly in comments more fully, but unfortunately getting to GDPR compliance is a lot of work and there are so many unique scenarios.

      • Philip William

        Thanks Joe,

        I know of far too many bloggers online that tell me that GDPR is only for the big sites and that we little blogs should not worry. Doesn’t sound right to me.

        I’d rather be as compliant as all the big sites so I am not worrying if I am going to get a knock on my website door from some GDPR enforcer!

        So, I have anonymized my sites ip addresses traffic. I have put in an op-out code for my traffic not to be tracked by analytics.

        Updated PPP and added Cookie Policy Page.

        Do you know of a pop up that I could use for free to capture consent soon as people land on my site? I seen this with a lot of sites lately and actually seems to be a great idea.

        Thanks again Joe and I am a little less paniecked now. Regarding adsense, I was advised by a long term blogger, to set your ads to auto ads and to non-personalized ads. Now, those ads won’t be based on tracking peoples interests i.e. tracking their personal data, and so that seems to be the best way.

        • @disqus_tfSMIB8H8K:disqus Yes, you can use OneTrust’s free solution:

          • Philip William

            Hi Joe,

            That is great and thank you for helping me on all of this. I think for now that OneTrust will be my final step until the GDPR fanatics invent more rules.

            Thanks again Joe and I will be sure to refer others to this article.


  • Irene Santos

    Very interesting article. However, I do not agree with one of your interpretations. I do not think that the user ID is a pseudoanonymous identifier. “‘pseudonymisation’ means 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”.

    I interpret that a pseudoanonymous data is one that contains the personal data encrypted in some way. If an isolated pseudoanonymous data falls into the wrong hands, they may be able to reach original personal data. If an isolated userID falls into the wrong hands, it can not do anything.

    • Hi @disqus_R9OVCCkuIZ:disqus, thank you for reading my blog post and for your comment!

      The way I understand pseudonymous in the context of the User ID is that by itself it cannot be used to identify an individual “without the use of additional information” such as a user database which then contains additional data to reveal the direct identify of the individual. This is what separates it from pure PII and distinguishes it from completely anonymous data as well. In this case, the data “is kept separately” per the definition.

      I’d be happy to better understand how you interpret this though. Let me know what you think.

      • Irene Santos

        Hi Joe, thank you very much for reading my comment.

        I interpret that in this case it is in the user database where my personal data is stored (for example, my name). It is in this database of users where my personal data must be pseudo-anonymized if we want to avoid any kind of identification (for example, encrypt my name). For me, it is very controversial due to the IP is a personal data. But I understand that a personal data is something related to my identity. Let’s think we lose two columns of data. If they have my name and my income, it is very painful. If they have my encrypted name and my income, it is dangerous. If they have my user ID and my income, it is nothing (from my point of view).

      • Irene Santos

        Thank you very much for reading my comment.

        I interpret that in this case it is in the user database where my personal data is stored (for example, my name). It is in this database of users where my personal data must be pseudo-anonymized if we want to avoid any kind of identification (for example, encrypt my name). For me, it is very controversial due to the IP is a personal data. But I understand that a personal data is something related to my identity. Let’s think we lose two columns of data. If they have my name and my income, it is very painful. If they have my encrypted name and my income, it is dangerous. If they have my user ID and my income, it is nothing (from my point of view).

      • Irene Santos

        Thank you very much for reading my comment.

        I interpret that in this case it is in the user database where my personal data is stored (for example, my name). It is in this database of users where my personal data must be pseudo-anonymized if we want to avoid any kind of identification (for example, encrypt my name). For me, it is very controversial due to the IP is a personal data. But I understand that a personal data is something related to my identity. Let’s think we lose two columns of data. If they have my name and my income, it is very painful. If they have my encrypted name and my income, it is dangerous. If they have my user ID and my income, it is nothing (from my point of view).

  • vlaxmax

    @joechristopher:disqus Thanks for the excellent article one of the best I found so far in the net.
    Just one quick question regarding point 5, how do you store consent without storing personal information?
    What value does that consent storage has if you cannot pin it to a specific person or institution?

  • Cam Winton

    It was planned to be, but is not expected to take effect until 2019.

Joe Christopher
About the Author

As Vice President, Analytics at Blast Analytics & Marketing, Joe leads a team of talented, analytics consultants responsible for helping clients understand and take action on their vast amounts of data, to continuously improve and EVOLVE their organizations. With 20 years of experience in analytics and digital marketing, Joe offers a high-level of knowledge and guidance to clients across all industries. He is an expert in all major analytics platforms including Google Analytics and Adobe Analytics, as well as various tag management systems such as Tealium and Adobe Launch. He also consults on data visualization, data governance, and data quality strategies. Having extensive expertise in many areas, has enabled Joe to become a well known thought leader and speak at industry events such as Tealium’s Digital Velocity series. Joe remains on the pulse of various information technology, programming languages, tools and services, keeping Blast and its clients on the leading edge.

Connect with Joe on LinkedIn. Joe Christopher has written on the Web Analytics Blog.

HIPAA and Analytics White Paper CTA

Featured White Paper

Healthcare Analytics and HIPAA: Ways to Minimize Risk and Ensure Compliance

The rise in digital data and analytics adds complexity and risk for healthcare organizations. Those that don’t comply with data privacy requirements, including Health Insurance Portability and Accountability Act (HIPAA), could face heavy fines, civil action lawsuits, and even criminal charges. Not to mention loss of patient trust.

Download the White Paper

Ready To Do More With Your Data?

If you have questions or you’re ready to discuss how Blast can help you EVOLVE your organization, talk to an Analytics Consultant today.

Call 1 (888) 252-7866 or contact us below.