Key question: do I need to ask permission from website visitors before using Google Analytics? This is a web developer’s guide, describing what GA is, how it relates to the law, and suggests some potential implementations.
How Google Analytics works
GA can be installed on a website in one of two ways – either by directly including analytics.js on the site, or by using Google Tag Manager. In either case, GA is activated, and the following happens:
- GA’s Javascript code is injected into the site, loading analytics.js from Google’s server, referencing the GA property we have set up
- A series of cookies are stored on the browser
- A tracking pixel is requested for every page view or event
The cookies provide persistence – once set, they remain the same throughout the visit, so that GA can ‘track’ your behaviour across multiple pages.
The tracking pixels are never actually visible on the website, but are loaded via an HTTP request as if they were an image hosted by Google. The cookies in your browser are sent with each request, which is how Google gets all that information back.
The Javascript code is what ties it all together – managing the cookies, detecting visitors’ activity, and packaging up all the information to send back to Google’s servers.
EU Cookie Law
This came into effect back in May 2011, and was adopted by all EU countries. Websites were given a full year to make themselves compliant. In the UK, the Information Commissioners’ Office (ICO) can enforce action, and in exceptional cases website owners can be fined a considerable amount.
The purpose of the EU Cookie Law is primarily to protect our privacy. It came about in response to a swathe of tracking technologies designed to track visitors activity across different websites, potentially stealing personal information along the way. The law doesn’t just extend to cookies, but to any mechanism of storing information on a browser.
GDPR
Another EU-wide regulation now in effect is the General Data Protection Regulation, enforced as of May 2018, and which is a thorough revision of 1993’s Data Protection Act. At its core, its aim is to protect Personally Identifiable Information (PII), giving people more control over their privacy and their data.
PHP sessions
When someone visits a website, PHP can assign that person a session ID, to keep track of any information that needs to persist throughout their visit. Typically this is what powers any login functionality, where we need to maintain the user’s logged-in status across multiple pages. To achieve this persistence, PHP stores a cookie in the browser. It contains no PII, and is harmless, but it is still a cookie.
EU Cookie Law is unclear at this point, but the general consensus is that session cookies do not pose a risk to privacy. We therefore do not need to ask permission before storing a session cookie, which can be considered “essential” to the normal/expected operation of the website.
Other types of cookie
While GA and session cookies might be considered relatively ‘safe’, others are not. Take special care if you are using Google Tag Manager, AdSense, HotJar, and other products that store cookies. You may need to change your approach if you are bundling these in with GA, or you might have to ask for permission for these separately. At the very least, it is unlikely you can silently imply consent for these.
GA and GDPR
The good news here is that GA does not handle PII at all. All its cookies and all the information sent back to Google’s servers is intentionally anonymous, and is reported in aggregate, so that users’ privacy is already protected. There is therefore no special consideration relating to GDPR when using GA.
GA and EU Cookie Law
The guidance given by the EU Cookie Law is that website owners must ask permission before storing cookies. In short, this means we cannot use GA until consent has been given.
However, guidance and implementation varies widely across the internet, and in reality the EU Cookie Law is not strictly or uniformly enforced. Many would argue that since GA only uses first-party cookies any data stored in them (which is already anonymous) cannot be accessed by other websites, and therefore already respects visitors’ privacy; this viewpoint advocates the silent use of GA without asking permission first. Weight is given to this approach because the ICO simply does not have the power or resources to enforce the EU Cookie Law across every single website, and only targets the biggest and worst offenders – smaller websites/companies can essentially ‘get away with it’ by remaining unnoticed. This does not make them compliant, but some are happy to take the risk.
GA isn’t always private
When setting up a new GA account, you are asked to specify your Data Sharing Settings. By default, these are all ticked. If you accept these default settings, data collected from your websites will be shared with others for various purposes. If we are concerned with our visitors’ privacy, which we should be, these options should be disabled.
Also bear in mind that it is possible for a developer to deliberately send PII to GA. This may be done with the best of intentions, but it is very clearly in breach of GDPR if explicit consent has not been given. GA events should not include user IDs, email addresses, names, or any other PII. When creating sites, we should also ensure that URIs do not include any PII either, as that would show up in the page view data.
How people manage their privacy
Education around internet privacy is improving, but it is far from mature. Some will happily accept cookies from anywhere and everywhere. Some will vary their response depending on the website or the reason stated for needing to store cookies. Some will avoid cookies wherever possible. It is possible to completely disable cookies in your browser, but given how many sites rely on cookies, especially for managing login sessions, those users will quickly find most of the internet doesn’t work any more. A worrying trend is that cookie consent notifications are becoming annoying and intrusive, to the point where people accept and discard the notifications just so they can get to the content of the site, without really thinking about what they are agreeing to.
Consent lifetime
How long we retain a visitor’s consent (or otherwise) may vary depending on the context. At the very least, it should aim to be unintrusive to the visitor, such that once a declaration has been made it is ‘remembered’ so that they are not asked again. For website owners, we might want to remember that for as long as possible, so that acceptance is eternal and data is guaranteed. However, best practice means thinking about our visitors first, so it may be appropriate to limit consent to a ‘reasonable’ amount of time, after which the original permission is deemed to be out of date. How long that time is will depend on the site and the audience; for some it may be a year, for others it may be as little as 30 days.
Negative indications can be treated differently again. If a visitor declares that they don’t want to accept cookies, the visitor could argue that they should only be asked once; however, this introduces the problem of how we remember that we asked them without storing it in a cookie. A simplistic solution might be to remember the indication for the duration of the session; when the browser is closed, the indication resets, and the next visit would prompt the visitor again. A more aggressive solution would be to keep asking on every page view, but this could be considered intrusive. Another approach might be to record the preference on the server, if a login system is used, which would allow more control over the lifetime, assuming the visitor is logged in.
My recommendations
Today, I primarily create websites for my company’s clients, and therefore it is other companies’ reputations that are at stake. We have a duty of care to ensure that the websites we create do not put our clients at any risk, and we must therefore strive to be fully compliant with GDPR and EU Cookie Law, regardless of the size of the site.
At the same time, we have a vested interest in showing the performance of our websites, which in some cases is best measured by visitors’ activity. If we cannot accurately track how people are using our websites, we cannot be sure we are providing good return on investment. We therefore need to strike a balance between compliance and pragmatism.
We also have a duty of care for the visitors to our clients’ sites. We need to respect their privacy, even if it makes business more difficult for us and our clients. We should therefore avoid any tactics that might be considered underhand; our websites should not be misleading, nor should they bully visitors into actions they are not happy with.
Implementation 1: silent GA
If we are confident that GA has been set up to completely anonymous, that Data Sharing is disabled, and that no PII is being sent, we could take the stance that GA is essential to the operation of the website and include it silently, without asking for permission first. This has the advantage of allowing us to capture every visit to the site, which is very good from the point of view of measuring the effectiveness of the site.
The danger here is lack of visibility. If we are storing cookies and not giving visitors any choice in the matter, this would be seen as a breach of the EU Cookie Law.
Implementation 2: notification-only GA
A common approach is to include GA automatically, with the aforementioned benefits of capturing everyone, and simply inform visitors that it’s happening. This is often achieved with a short note in the footer, or a notification bar that can be dismissed. The messaging usually follows that ‘continued use of the site is an indication of consent’; if the visitor is not happy with our approach, they are free to leave the site.
In this case, the implementation is actually misleading. At the point of visiting the site, we are already storing cookies and tracking them anonymously via GA, before they have had a chance to accept the terms. Leaving the site immediately does not undo their initial visit.
| This site uses cookies. Read our Privacy Policy for more details. |
Implementation 3: consent via interaction
As an improvement on the above, we might consider ‘activating’ GA once there has been a positive interaction on the site. This might include dismissing the notification bar, navigating to another page on the site, or even scrolling down the page. If we are confident that visitors will be suitably informed of our intentions as soon as the page loads, any subsequent action can be considered an acceptance of those terms. If the visitor does not accept the terms, they can safely leave the site, and we will not have tracked them.
The risk with this approach is that the positive interactions we are listening to are not necessarily related to giving consent. Dismissing a cookie notification, for example, could be argued to imply that the visitor doesn’t want us to store cookies. Similarly, a visitor may want to scroll through the page before deciding whether they want to accept cookies. Implied consent is unintrusive, but risks assuming consent where there wasn’t any.
GDPR has trained us to think about “explicit consent”, such that implying consent via an unrelated action seems insufficient. However, GDPR is primarily about the handling of PII, which is (hopefully) out of scope for GA. This approach is a good compromise – it protects visitors’ privacy, ensures as much data as possible for us to analyse, and shows that we are serious about privacy.
Actually implementing this approach has several implications. Rather than simply copying and pasting the GA code into the page source, we need to conditionally include it once we have detected a suitable interaction. A recommended approach would be:
- Check for the presence of a GA cookie – if it’s already there, we can assume that consent has already been given, and we can inject the GA code immediately.
- Listen for suitable events – these can include navigating to another page on the site, scrolling down the page some distance, clicking a button, dismissing a notification, or entering information in a form. Time on site should not be considered a reliable source of consent.
- As soon as an event is detected, inject the GA code and stop listening for further consent events.
- Remove the notification, ideally making it clear that consent has been received.
| This site uses cookies. By using our site, you are accepting the terms of our Privacy Policy. | X |
Implementation 4: explicit consent
Another approach is to only activate GA if the visitor explicitly agrees to it. This limits the above approach to only an action relating to giving consent. Typically this would mean relying on a cookie notification bar or window that asks for consent; clicking an ‘Accept’ button would close the notification and activate GA. Ignoring the notification would mean the visitor can browse as much of the site as they want without being tracked.
While this sounds ideal, many have taken to making their consent notifications as obtrusive as possible, coercing visitors not to ignore the request and to give consent. This approach, while not specifically in breach of GDPR or EU Cookie Law, could be considered bad form, and potentially gives visitors an unwanted negative experience. At the same time, implementing this approach with a more subtle notification means that visitors can ignore it and use the site untracked, which is bad for measuring activity. This is however generally a good approach if the client is happy to accept lower numbers in GA data.
In terms of implementation, it is similar to the above, except that we are only considering consent if an ‘Accept’ button is clicked on the notification. Do not include any other way of dismissing the notification, as that would be misleading. You will also need to continue showing the notification on every page until consent is given.
| This site would like to use cookies. Read our Privacy Policy for more details. | Accept |
Implementation 5: explicit consent with rejection
An approach sometimes seen, which is an extension of the above implementation, is to allow visitors to either accept OR decline the use of cookies. GA cannot be activated until consent is explicitly given, but we additionally allow visitors to permanently (or temporarily) decline consent so that they are not tracked and they are not pestered by the notification any more. This is excellent from a user’s perspective, as it puts them in complete control.
However, this is clearly a poor option from the point of view of the website owner, who is likely to see very few visitors accepting the request; people are more likely to reject than accept, given the choice. At this point, the implementation seems overkill given that GA is already anonymous; it may be more applicable if other, less harmless, cookies are also being stored. It also has the counter-intuitive impact that we need to store the visitors negative response by storing a cookie for the preference.
| This site would like to use cookies. Read our Privacy Policy for more details. | Accept | Decline |
Implementation 6: explicit consent with options
For a more comprehensive solution, we may consider splitting our cookies into different categories, and letting the visitor choose which ones they want to accept. In this case we can make it clear in the messaging that GA and session cookies are essential parts of the normal working of the site; we might in this case take the approach of implementation 4 and activate GA as soon as consent is given. The advantage here is that we are communicating a sense of control to the visitor, reassuring them that GA is ‘safe’ and allowing them choose whether they want anything else.
This is the best solution if you are using cookies other than GA, such as HotJar or AdSense, and is especially good if visitors can easily come back and change their decision later on. It gives the visitor a sense that we are taking their privacy seriously. However, it is a much weightier solution, perhaps unsuited to smaller sites where it might seem out of proportion to the significance of the site.
At this scale, it may be more appropriate to use an off-the-shelf implementation rather than rolling your own. This not only reduces workload for us, but potentially helps instil a sense of trust.
| This site uses cookies. Read our Privacy Policy for more details. Indicate below which cookies you are happy for us to use:
[ x ] Essential [ ] Optional |
Accept |
Conclusion
Google Analytics is cool. Cookies are useful. The EU Cookie Law is there to protect our privacy. The GDPR is there to protect our data. The hard part is getting all of these to work together. The implementations above are all suggestions, and any one of them might work for you. Or there might be another way I haven’t thought of, in which case let me know in a comment below. Either way, never take consent for granted, always think about your visitors, and cover your back.
Matthew Dawkins 