Reading Time: 6 mins 6 sec
With the follow up question “do I need all users to opt-in so you can track them?”.
These are two good questions so I’ve put together a review of the current understanding and what needs to be done.
Please note this is not legal advice and you need to talk to your own counsel to understand your company’s position depending on your set up.
If you need help with preparing your company for GDPR then SLX has partnered with LawBite’s low-cost GDPR documentation and review service.
To clarify, the law that will impact Google Analytics in most installation cases will not be GDPR, because GA stores very limited #PII – personally identifiable information and GDPR is designed to protect PII . In most Google Analytics installations PII is only stored in certain specific circumstances. You still have to check that your version of GA is GDPR compliant but it is not going to kill its use.
However, the law that will impact Google Analytics will be ePrivacy regulation but that isn’t ready yet (it was going to launch with GDPR but has been delayed due to negotiations).
We will be covering more on the development of ePrivacy Regulations later so stay in touch with SLX on our social media spaces where we’ll notify you through our future newsletters.
We need to start with what GDPR is focused on – personally identifiable information. And that means any data you can identify a real natural person. IP addresses and unique ID’s can all be combined to identify the real person and so have to be considered as PII.
A standard installation of Google Analytics doesn’t expose these in the standard report, instead it reports on volumes of site sessions, pages viewed and has data thresholds in place to stop drilling down to an individual visitors behaviour.
For full compliance, your company needs to be able to audit/confirm that Google Analytics is not storing PII.
The circumstance for PII in GA vary from the hidden (IP) to the obvious (Customer ID) but can be boiled down to:
These are tracked automatically by GA but aren’t exposed via any of the reports or through the API, so we are safe, aren’t we?
No, it turns out legally we may not be if you are a special category data controller processing this type of information:
As a company, you are a Data Controller, and Google is a Data Processor. In this special category relationship, the Data Controller must protect the data subject from the Processor’s risks.
As Google states in its new Data Processing Amendment
7.1.2. Security Compliance by Google Staff. Google will take appropriate steps to ensure compliance with the Security Measures by its employees, contractors and Subprocessors to the extent applicable to their scope of performance, including ensuring that all persons authorized to process Customer Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.
The risk is that users IP addresses could be accessed by a Google employee and that is used to track users (this is an outlier risk as it would take a rogue employee to be part of the GA team).
If you are processing special category data through Google Analytics you may consider “hiding” the IP of visitors from the system
There is a tool provided by Google (yep who knew) but thanks to the German privacy requirements this has been created and is available here.
This tool stops the IP being fully recorded to disk in the Google Analytics Collection Network and instead removes the last digits from being stored.
Its use could cause less accuracy at country and city level reporting but its a small penalty.
The other downside is many companies filter their reports by IP to remove visits and activity from their internal users. By using the German tool it will remove your ability to remove users at an IP level which will change the numbers in your reports, Therefore if your reports are relying on removing internal IP addresses from reports do this in a test view and filter before adding it to your main view.
Now, this is definitely a rogue CMS issue rather than a direct intentional PII data collection.
When users complete sign up forms or sign into an authorised area, some CMS systems pass PII within the URL, that URL will be passed to GA and recorded in your reports.
This is bad practice, it breaks GA service level agreement (no PII to be stored in GA duh!) but has historically been ignored as webmasters just saw it as junk data.
However, come GDPR this will make your GA illegal!
So to check your Google Analytics do this:
Please note this list is for starters please share any thing you find that matched in the comments box below please so I can update this post and help everyone out.
So is anything coming up?
To correct this problem contact the website developer and ask them for a solution to prevent this happening.
A further note on this, we are investigating if it is necessary to remove old data prior to 25th May 2018. If it is then you may need to start a new Profile! More to follow on this….
We all track campaigns in Google Analytics, and you might have specialist tags for specific Source, Medium, Keyword, Campaign, Content. Check that these don’t contain PII especially an email address or name.
To do that look at your campaign report, you can ignore Google Adwords campaigns unless your naming scheme is particularly specific (people level!)
When “Users” have been turned on in settings, Each User will have a unique ID generated by GA and this can be seen by this report:
Google Analytics Audience > User Explorer Report
Obviously, if you are covered by consent or legitimate interest then you can continue but otherwise, it could be seen as a GDPR risk.
To disable this you will need to stop tracking users, which is done by:
This will have the added benefit of stopping the use of a couple of cookies (_ga/_gid), technically there two but most people don’t tend to use the other one.
Update – Google Analytics has recently released a new tool to allow for user and event data to have a “lifetime” in Google Analytics of between 14 months and just over 4 years. If you are going to continue with the user function you should strongly consider this as it will demonstrate that you are no holding data for “no longer than is necessary” part of GDPR.
And finally if your company activity stores customer data in GA by injecting data from other sources which could be any of these:
This will normally be handled by a bespoke development that will have been an IT / Developer project and therefore it should be known what it is doing, how it works and how to fix it.
You will need to go talk amongst your marketing, legal and developers on the legal coverage for using this data and if it needs to stop.
These are the key points to take out of this post, but as I said before, your company needs to make its own decisions and most importantly document them.
If you have a custom GA setup using known PII then you have 4 options
Also, remember you could be breaking the Google Analytics Service level agreement by storing PII in there!
Please remember none of this is legal advice, do your own research and if you need help SLX can do a full GA GDPR (email and other systems) audit for your company.