Google Analytics & Legal Requirements

A few weeks ago, industry media reported the Austrian Dispute Settlement Body (DSB) case, stating that the use of Google Analytics (GA) violates the “Schrems II” decision by the Court of Justice of the European Union (CJEU), and the Non-Governmental Organization, None Of Your Business (noyb), considered the use of GA illegal. For anyone working in digital analytics and/or marketing, this definitely raises some concerns, and that is the reason for this blog post.

The use of GA is not illegal per se, not even in Austria, but the way you choose to implement GA, and the data you choose to collect, is what dictates the legality of the service. This blog post outlines what to consider in your data collection processes, in regards to data protection laws. It is not legal advice, rather a reference to specific features and configurations that you might want to look into.

Legislations

There are a number of legislations and decisions that are often referred to, such as e-Privacy, General Data Protection Regulation (GDPR), and Schrems II. Let’s have a closer look at these.

e-Privacy

Also referred to as “the Cookie Law”, e-Privacy is the directive governing the use of cookies. It addresses aspects of electronic communications and the tracking of internet users, e.g. by regulating the need for companies to collect users’ consent before certain cookies (and similar technologies) can be used. However, that GA violates the Schrems II decision, as the Austrian DSB case states, does not mean that they are violating the e-Privacy. Nonetheless, to comply you must:

- Receive users' consent before you use any cookies except strictly necessary cookies.
- Provide accurate and specific information about the data each cookie tracks and its purpose in plain language before consent is received.
- Document and store consent received from users.
- Allow users to access your service even if they refuse to allow the use of certain cookies.
- Make it as easy for users to withdraw their consent as it was for them to give their consent in the first place.

Reference: https://gdpr.eu/cookies/

Many companies implement a cookie modal, thinking it meets the requirements without addressing shortcomings in the data collection process.

GDPR

First of all, GDPR applies as soon as you touch upon personal data. According to the European Commission, “personal data” is any information that relates to an identified or identifiable living individual”. Examples of such data are:

• First name and last name
• Physical address
• Email address
• Identification card number
• Location data
• IP address
  
  

As GDPR requires that data collected on EU citizens must be subject to European privacy laws (or with a jurisdiction that has a similar level of protection), you should make sure that no such data is ever stored in GA. This is because Google cannot guarantee that the data collected is subject to such levels of protection.

So, if you do not send that kind of data to GA, are you safe? It depends. The way GA is designed is problematic.

Schrems II

In 2020, the CJEU issued a ruling, stating that a transfer to US providers violates rules on international transfers in GDPR, invalidating the transfer deal Privacy Shield. In short, this means that the data transfer itself (from EU data exporters, to US providers) is a violation if it contains personal data.

Consequently, the act of making a GA request from a user’s browser to Google, constitutes such a violation, because the IP address of the end-user would be exposed in that request. So basically, you need to make sure not to send IP addresses to Google.

Review Points

First, make sure you get legal advice from an expert if you are unsure of what applies within your organization. This list outlines some of the issues that you might have to address.

#1: True IP anonymization

By using the well-known Anonymize IP feature in GA (either in settings or in code), you’re still not safe. As the anonymization of the IP address occurs after Google receives the request, the damage is already done, opening up for US surveillance systems (such as the NSA) to collect and store that data. Instead, you must anonymize IP addresses on your end before sending data to (or requesting resources from) Google’s servers. The easiest way to accomplish this is to implement GTM server-side.

Just make sure to:

• Run your GTM server container on a server located in the EU.
• Load your tracking scripts such as analytics.js, gtm.js, gtag.js, etc from that very same server.
• Anonymize IP in the Google Analytics tag setting.
• Disable Advertising features/signals as it relies on the technique of requesting third-party domains (hence again exposing IP addresses).
  
  

Consequences: As soon as you toggle off advertising features your remarketing capability is limited, as audience building in the Google suite relies on these technologies. This is not saying that you cannot do re-targeting. You can! But that’s another blog post!

#2: Do not collect personal data

Perhaps needless to say, but make sure that you are not collecting any personal data such as names, email addresses, etc. For a long time, this has been a no-go in GA policies, and should not be news for anyone in digital marketing.

#3: Audit your use of pseudonymous data

Any pseudonymous data, such as a Customer ID or Transaction ID, is included in the scope of personal data according to GDPR. Even though a Transaction ID (e.g. “ABC123”) as a single data point cannot be traced back to an individual by external parties, your organization probably has the ability which makes it still fall into the category of personal data. However, during the past years, working in complex privacy projects, our experience is that different legal departments come to completely different conclusions regarding pseudonymous data in GA.

If you choose not to collect pseudonymous data in GA (but still see value in collecting it), there are alternative solutions. For some clients, we have designed a tracking solution using GTM server to split the GA request into two separate tracking pipelines, the first sending data to GA (excluding pseudonymous data) and the second sending data to their data warehouse (including pseudonymous data). Thus, pseudonymous data is never sent to GA.

#4: Right of access

According to “Art. 15 in GDPR: Right of access by the data subject”:

"The data subject shall have the right to obtain from the controller confirmation as to whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data (...)"

Reference: https://gdpr-info.eu/art-15-gdpr/

If you are collecting personal data, you need to be able to send that data in a readable format to the user upon request. If such data is stored in GA (such as a pseudonymous transaction id), all the data you can link to that id, such as all interaction events, campaign information, etc. might have to be included in the dataset presented to the user. This potentially requires advanced integrations and automation. Not to mention, “Art. 20: Right to data portability”, which requires you to present that very same data in a machine-readable format. Again, make sure that you align with your legal department around these details.

#5: Right to be forgotten

According to “Art. 17 in GDPR: Right to erasure (right to be forgotten)”:

"The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay (...)"

Reference: https://gdpr-info.eu/art-17-gdpr/

If you are collecting personal data, you need to be able to delete that data upon request. So if you collect a Transaction ID in GA, you might have to delete that data upon request (and all other data that you can link to the ID). This could be a headache from a technical perspective, as you might have to use APIs to actually delete already collected data, update BigQuery records, etc. An alternative solution is to not send the actual Transaction ID / Customer ID to GA, but a representation of it. In that way, you can instead delete the mapping between the real ID and the corresponding ID, consequently making the data in GA anonymous.

#6: Respect user consent

Suffice to say, make sure that you comply with the e-Privacy regulations described previously. This does not just apply to GA, but all similar tracking endpoints such as Facebook, LinkedIn, Google Ads etc. Be aware of your design choices as they will impact data collection. Examples:

• Forcing vs non-forcing modal

A forcing modal prevents the user from navigating your site until an option is made. From our experience, this will give you higher opt-in rates and better data quality due to all campaign data being intact on the first page load. The downside being that such a modal is perceived as intrusive to the user.

• Offer a reject button or not

Many modals are purposefully designed to get the user to approve cookies, rather than giving them a choice that is as effortless to opt-out as it is to opt-in. Your design choice would definitely impact the data collection, as a reject all button most certainly results in less opt-in.

Roundup

There have been a lot of misinterpretations around GA and whether or not it is compliant with existing regulations. But it is up to you to decide how you want it configured. You can strip down the implementation completely, and essentially make it into a pure web statistics tool without any integration to other Google products, no sharing of anonymized IP addresses, no collection of advertising click IDs, etc. You will then have a tool that has no personal data and/or pseudonymous data in it whatsoever. It will affect your capabilities in regards to data activation and remarketing etc, so it is up to you and/or your legal department to work on the details.