The introduction of the GDPR made companies realize the importance of personal data protection. High fines for violations, reaching €20 million and more, mean these issues shouldn’t be taken lightly. In this context, it’s worth taking a look at Google Analytics as well.
Security and GDPR compliance
Let’s start by stressing that Google Analytics, the most popular website analytics tool, is fundamentally secure, and Google takes steps to ensure regulatory compliance.
This article is not a legal opinion, hence the absence of definitive statements on legal matters. The compliance of the tools you use should be assessed by a lawyer or another appropriately qualified person — with reference to your individual case.
Access to the data is protected by a range of technical and organizational measures (see the Analytics help article), and the likelihood of the confidentiality of the data stored there being breached is negligible.
Google declares that Analytics is GDPR-compliant, in particular:
- Google offers a data processing amendment, which serves as a form of data processing agreement;
- Tools have been provided to set the data retention period (see the Analytics help article on data retention) and a tool to delete cookie data associated with individual users;
- Data processing in Analytics takes place under the EU-U.S. Data Privacy Framework, the agreement between the EU and the USA on processing the personal data of European Union citizens.
- Analytics doesn’t log IP addresses. After reading it and determining the user’s approximate location, the IP is discarded.
It also has to be stressed that the Google Analytics terms of service prohibit sending Google any data that allows a person to be identified. Google reserves the right, in case of a violation, to terminate the service and delete the data.
Where does personal data in Google Analytics come from?
Analytics processes pseudonymized personal data, such as User ID, transaction IDs, and the Analytics identifier (User pseudo ID, Client ID). That is a natural and correct use of an analytics tool.
Explicit personal data, however — such as names, email addresses or postal addresses — should never appear in Google Analytics at all. So why can it happen?
The reason — as with any tool — is improper use of Google Analytics by site owners. It has to be emphasized that this is usually unintentional and stems from a lack of awareness of how the website works and how users arrive at it.
Most often, personal data is fed into Analytics by websites through URLs — including their parameters — and page titles (meta title).
URLs containing personal data
Personal data can appear in a URL directly (see the illustration below), e.g.:
- as tracking parameters generated when sending mailings or SMS (1);
- as parameters created during a product purchase, based on data entered by the user (2);
- as login-related parameters, which in the worst case can include the username and password (3):
Personal data can also be present in URLs indirectly (4 and 5). In this case the URL itself contains no personal data, but it points to a page where personal data is accessible — and sometimes it even contains an authentication key that allows logging in. An example of such a page is a transaction confirmation link, e.g. for a hotel booking:
Of course, some of the above examples are extreme cases (though unfortunately still found in practice). Most services have a proper architecture and there’s no way to read a username and password from the URL, or for outsiders to log in to an account and make changes.
Sometimes, however, you get the impression that website designers simply didn’t take into account that the URL or page title can be read by anyone other than the user.
Site search
A special case of personal data entering Analytics through a URL parameter is site search. It can happen that a user (usually by mistake) types personal data into the site’s search box:
Page titles
A site can also introduce personal data into Analytics through the page title (meta title), which Google Analytics reads as well. It also happens that this field simply contains the page’s URL:
Other possibilities
Personal data can also enter Google Analytics through more advanced features, such as event parameters, eCommerce transaction values, the API, a manually uploaded CSV file, or the Measurement Protocol. It’s worth checking whether information enabling user identification isn’t being sent to Analytics this way through an oversight.
It may be a harmless incident
Personal data that has entered Google Analytics is available only to authorized people with access to the Analytics account. Most often these are the site owners, employees and third parties (e.g. marketing agencies) bound to confidentiality by law or by contract. Frequently, most of these people also have access to the same data through other systems (e.g. accounting and billing software), so the fact that they can also see it in Analytics changes little from the standpoint of the data’s actual security.
Google employees’ access to Analytics data is likewise limited to the necessary minimum and hedged with numerous procedures. So even if data that shouldn’t be there ends up in Analytics, the probability that Google will use it to the detriment of the people concerned is negligible.
That’s why in most cases, sending personal data to Google Analytics doesn’t create a significant data security risk. If you’re the only person with access to GA, the chance that anyone will ever find out is practically zero.
Google allows selective deletion of data from Analytics, and in such situations you should use this feature.
It may be a serious problem
Transferring personal data to an external company without a prior data processing agreement may constitute a breach of the law — confirms attorney-at-law Tomasz Palak. Meanwhile, Google’s data processing amendment for the Analytics service covers only data such as cookie, IP, device and client identifiers (pseudonymized data).
This means the data processing agreement does not cover ordinary personal data sent to Google in violation of the Google Analytics terms of service.
The appearance of such data in Analytics can, in some cases, also mean a genuine threat to its security.
Who had access to the data?
Access to your Google Analytics account may have been granted to various people. It happens that access is granted without an appropriate confidentiality agreement and without awareness that Analytics contains personal data.
Regardless of signed agreements, the question arises: do the people who had access to Analytics genuinely guarantee the confidentiality of the information? Are we sure they properly protect their Google account credentials?
Personal data is not statistics
Unauthorized use of analytics data about website traffic will, at worst, breach trade secrets. Its disclosure to unwanted parties (e.g. competitors) may in particular cases prove damaging to the company.
The scale of the problem, however, is incomparable with a leak of personal data and its unauthorized use on a mass scale, which can bring financial and legal consequences and hurt the company’s reputation.
Scope of the data
Another question is what data we’re talking about. Is it only email addresses, or full personal data enabling identity theft? Could it be sensitive data? How much could this data matter for that person’s privacy, safety and property? Did the data allow logging in to an account? Was it possible to conclude a transaction or make a payment? Are we talking about the customers of a small shop, or of a large financial institution?
Combining the information about who had access to the personal data, when and on what scale — and what data it was — will let you assess whether you’re dealing with a minor incident or a serious problem requiring immediate action.
What to do when you find personal data in Analytics?
- First of all: stay calm. This data has most likely been accumulating in Analytics for a long time. If no problem has arisen so far, chances are slim that it will happen right now.
- Determine exactly what data ended up in Google Analytics and when. Check who has access to Analytics and review the change history to find any deleted users who may have had access to the data in the past. This will let you gauge the scale and gravity of the problem.
- Inform the person responsible for personal data security, or the company’s management.
- Identify which pages of your site send personal data to Google Analytics, and modify those pages’ settings and/or the tracking code so the data no longer reaches Analytics.
- Decide what to do with the data collected so far.
This article is not legal advice and presents primarily the technical aspects of personal data in Analytics. In every individual case, seek a professional opinion assessing the technical and legal situation and proposing solutions. Feel free to contact us.
Below are a few practical remarks worth taking into account:
- If you want to remove this data from Google Analytics, know that Google provides no procedure for individually removing this kind of data from an Analytics account — especially since, under the terms of service, it shouldn’t be there in the first place. The only way is deleting the account/property/view. After being moved to the trash, it is permanently deleted after some time (see the Analytics help article).
- Before deciding to delete the account, consider whether such a radical step is necessary in your case. The fact that the data was sent cannot be undone. As long as access to the account is limited to a very narrow group of people with appropriate authorization (or indeed just one person), and Analytics doesn’t contain thousands of credit card numbers with security codes, the real threat to data security is negligible. Historical data and remarketing lists may still be useful, so consider keeping them until they can be considered practically useless. Note also that it’s possible to move an Analytics property to another account.
- If the decision to delete the account/property has been made, it’s worth saving at least a few of the most important reports so you can reach for historical data in the future. You can also download data from Analytics via the API. If you use the free version of Analytics, limits on the number of records retrieved may prevent downloading everything. Still, the more data you save, the better. In these files you can of course redact the personal data.
- If the data was sent only indirectly — i.e. as URLs enabling access — it’s enough to set up appropriate server-level redirects and/or make code changes so that personal data can no longer be accessed using the URLs that ended up in Analytics, and nothing will need deleting from Analytics.
- Check whether site search reporting contains personal data. One solution is dictionary-based search, which limits search terms exclusively to phrases present on the site.
- Create alerts that detect the appearance in Analytics of data that could be personal data. Remember that at any moment a developer oversight or improper use of URL parameters (e.g. in a mailing) can cause the data to appear there again. Alerts aside, it’s worth regularly auditing Google Analytics in this respect.
- If the functionality of a link containing personal data (e.g. a hotel booking confirmation) is needed for the service to work, make sure the addresses of that page are not sent to Google Analytics.
One security option is removing all tracking codes from such pages. However, since these are often conversion pages, that may require additional development work to keep reporting conversions and transaction data. Filters in Analytics are sometimes used, but remember that filters only alter the data after it has been sent to Analytics.
To truly prevent personal data from being sent to Google Analytics, the Analytics code must be modified so that it changes the URLs before sending them to Google (see the Analytics help article). Such modifications can easily be prepared in Google Tag Manager.
Below is an example of this solution implemented on Booking.com. Note that this page not only allows access to the data without logging in, but also allows modifying the booking. However, the address sent to Google Analytics has the authentication key stripped.
It’s not Google’s fault — it’s your website’s fault
As you can see, the source of the problem is that on some websites, part of the URLs contain personal data, or those URLs enable access to personal data (sometimes even including an authentication key that allows logging in).
Google Analytics provides tools that make it possible to keep data private even on such pages. Properly configured Google Analytics code can safely be placed on any page.
Keep in mind that other Google codes also collect URLs:
- Google Ads codes (see the Google Ads help article on personally identifiable URLs)
- AdSense codes (see the article on preventing the transmission of personal data in AdSense)
- Google Marketing Platform Floodlight codes (the relevant article is practically a repetition of the AdSense one)
For these codes, the recommended solutions include:
- changing the form submission method from GET to POST (see also the article on w3schools.com), and
- replacing URL strings containing personal data with anonymous or pseudonymized identifiers.
Google notifies AdSense, Google Ads and Google Marketing Platform users of detected violations of the ban on transmitting personal data via emails combined with a demand to resolve or explain the problem (see e.g. Google’s help article on fixing policy violations and Google’s guidance on avoiding sending personal data to Google).
Google Analytics has introduced a default data redaction option, which removes email addresses and other strings from the URLs being sent — see the Google help article.
Remember, though, that the ability to delete and redact data within Google services doesn’t change the fact that the data was previously sent to Google. So the priority should be preventing such situations from happening at all.
Other tracking codes
The Facebook pixel also transmits URL information. Access to these addresses isn’t as comprehensive as in Analytics reports, but the fact remains that Facebook collects the data.
And then there are all the other tracking codes — those of other ad networks (especially remarketing ones), affiliate networks, SaaS tools, ad-serving codes — most of which read URL information. Be aware that not every one of these companies necessarily maintains the highest data security standards or provides tools to redact personal data.
Note also that even if you make sure such URLs aren’t collected by tracking codes, there’s a chance that the user will thoughtlessly share such an address themselves — sometimes even unknowingly, through installed browser extensions or other software on their device. For example, the ubiquitous ad blockers collect the addresses of all visited pages on their servers. And who knows what else the user may have installed. Yes, it will be the user’s fault — but the situation won’t do anyone any good.
In the worst-case scenario, such pages may end up indexed by a search engine.
Don’t use URLs containing personal data
Since with many tracking codes masking the URL and page title won’t be possible, and the user themselves may unknowingly (e.g. through malware) pass information about visited pages to unidentified third parties, the general conclusion is that websites should avoid URLs that contain personal data or that enable access to it without additional authentication.
So consider whether such pages are truly essential to your service. If they are, then on pages whose URLs enable access to data without authentication, place only tracking codes that allow the address to be masked before it is collected, such as appropriately modified Google Analytics code. Such pages should limit the visible data to a minimum (e.g. first name only: “Anna, here’s your order”), and full data and modification options should be available only after a recent login in the given browser.
Check whether this affects your site
The fact is that Google services — Google Analytics in particular — are probably the best prepared to track users while preserving privacy. With the GDPR in force and growing awareness of the importance of personal data protection, these issues will only gain in importance.
So it’s probably high time to audit Google Analytics and your website: check what tracking codes are present and what information they read, determine whether and to whom your site has been sending personal data, and who has access to that data.
If you need help analyzing the issues raised in this article, get in touch with us.
Thanks to Maciej Lewiński, author of Google Analytics trainings, for consulting on this article.
