What Intelligent Tracking Prevention (ITP) 2.1 means for digital analytics

What is ITP 2.1?

ITP is part of WebKit, the open source browser engine that powers Safari, among other projects. It was first introduced in 2017 and has been updated several times since then (all ITP release notes are here). The beta releases of iOS 12.2 and macOS Safari 12.1 for High Sierra and Mojave include a new version of ITP known as 2.1. This will likely be rolled out to all Safari users at some point in March 2019.

This latest version of ITP has very significant implications for web analysts, and everyone whose job involves implementing or maintaining digital analytics software should be aware of the changes.

What happens if I do nothing?

Firstly, I’d advise against doing nothing! If the integrity of your analytics data is in any way important to you, it is definitely worth taking the time to understand the intricacies of this important change, the reasons for its introduction, the many potential avenues for how to proceed, and – perhaps most interestingly of all – the possible ways in which analytics vendors will react.

That said, you’re no doubt a busy person and right now you just want the TL;DR for Google Analytics. So, here it is:

At some point in March 2019, users of the Safari browser on both mobile and desktop will have the expiration of their _ga cookie – the one which stores the Client ID and is used to recognise individual users on your website – changed from 2 years to 7 days.

So, if a user were to visit www.builtvisible.com for the first time on Monday 1st then revisit the site on Saturday 6th, they would be recognised as two sessions from the same user. All good. But if they return a week later on Sunday 14th, this third visit will be treated as a new user. Previously, each hit would reset the cookie expiration to 2 years in the future.

When ITP 2.1 is launched, a default implementation would no longer be able to accurately build an audience of loyal users who visit the site once or twice a month.

Hang on, this is huge. Why would WebKit do this?

On Twitter, the WebKit developers have made clear that their key motivation is to move towards eliminating cross-domain tracking. Note that we’re referring primarily to ad networks here, specifically those using cookies to track users across multiple different websites in order to build a profile of their behaviour and interests. Disruption to legitimate cross-domain tracking (e.g. www.mysite.com > checkout.mysite.com) is essentially collateral damage.

All first party cookies, including many analytics platforms and much split testing software, are now capped to 7 days of storage.

Honestly, I do get where they’re coming from. And for reasons I’ll get to, I can see why they’ve taken this approach. In some ways it reminds me of Google’s aggressive push to drive adoption of HTTPS over the past few years, one tactic being to make the insecure protocol increasingly inconvenient for site owners to use.

Won’t this ‘war on cookies’ cause users to be logged out?

Firstly, it’s not a war on cookies; it’s a response to legitimate privacy concerns about cross-site tracking, and our collective failure to adopt features designed to tighten up the security and performance of cookies as a technology.

I’m sure everyone is as sick as I am of intrusive (yet ostensibly well-meaning) cookie banners. In my view, these banners represent a poor solution to a very real issue. Cookies are fundamental to the modern web, and telling a user “this website uses cookies” is as about as helpful as a GPS unit constantly reminding the user that it uses satellites. The user is not educated or empowered in any meaningful sense.

Cookies enable meaningful online experiences, and the web wouldn’t function without them. They allow a stateless protocol like HTTP to support stateful sessions, for example by ensuring that the contents of your shopping basket persists across page loads. They are also deeply flawed and open to abuse. The crux of the issue is that the many features which are available to developers to mitigate these problems – the Secure and HttpOnly attributes, for example – simply aren’t being widely adopted. Check out this article by Google engineer Mike West for more on this tricky issue.

But to return to the original question, the answer is no: authentication cookies which have been properly implemented won’t be affected by the 7-day cap. Authentication cookies should be secure and HTTP-only, meaning they’re set using the Set-Cookie header in the HTTP response and are inaccessible via JavaScript’s document.cookie API. These cookies are exempt from the 7-day cap on first party cookies:

“Authentication cookies should be Secure and HttpOnly to protect them against man-in-the-middle attacks, cross-site scripting attacks, and speculative execution attacks […] Only cookies created through document.cookie are affected by this change.”

– John Wilander, WebKit

Okay, fine. But how can I ensure our digital analytics platform continues to function?

The inimitable Simo Ahava has already explored some of the many possible solutions to this problem on his blog (required reading for analysts!). Numerous code snippets and cool workaround ideas are cropping up on Twitter, GitHub, and across the blogosphere (literally never used that word before).

These ‘solutions’ are broadly grouped into two categories:

1. Using localStorage to persist the unique identifier (i.e. the client ID) instead of relying solely on the _ga cookie
2. Setting the _ga cookie with the HTTP response, rather than with JavaScript

The first of these is typically implemented using the customTask API for Universal Analytics. Tasks – which incidentally are one of are one of my favourite features and sorely underused by analysts! – essentially allow us to manipulate Measurement Protocol hits as they’re being generated, before they’re sent off to Google. In our case, we’re using customTask and Custom JavaScript variables in Google Tag Manager to keep the client ID in localCtorage in sync with the one in the _ga cookie (if one exists). Check out Simo’s great guide for more detail.

An understanding of how localStorage works is critical. While its data has no expiration time, and so can easily dodge the ITP’s 7-day expiration on client-side cookies, it is subject to the same-origin security policy (you’ll be familiar with this if you’ve ever delved into the CORS quagmire). In short, this means that the client ID stored in localStorage is only accessible on the hostname on which it was set (e.g. www.builtvisible.com). This is in contrast to the _ga first party cookie, which – when the cookieDomain field is set to the default of ‘auto’ – will set the cookie on the highest level domain it can (in this case, *.builtvisible.com).

If you operate on a single domain, then the localStorage approach could work well for you. But if your content is split across www, blog and shop, for example, you can still fall afoul of the 7-day expiration in instances where you’re reliant on the first party cookie.

Moving onto our second approach, you could move your analytics to HTTP cookies instead of client-side cookies (i.e. eliminate reliance on JavaScript cookies and the associated 7-day expiration). You obviously need access to your server and an understanding of how to configure it, and implementation will vary depending on your setup, but this is definitely worth exploring. I recommend checking out the tech demo from Peter Nikolow and the Cloudflare Workers snippet from Dustin Recko for inspiration.

What’s the most robust solution in the long-term? How will other vendors react?

This is an interesting question.

Personally, given the aforementioned focus on cross domain tracking, I think that this is where the restrictions are likely to be tightened. I wouldn’t be surprised if we eventually arrived at a place where all legitimate cross domain tracking requires something akin to the Linker plugin: decorating URLs with a parameter containing the client ID and picking this up at the other end. Perhaps ITP 3.0 will enforce some kind of same-origin policy on first party cookies, meaning seamless cross-subdomain tracking in GA with the cookieDomain:auto setting would be a thing of the past.

As for the 7-day expiration, which has been slapped onto all client side cookies, I fully expect analytics vendors to respond with official solutions or workarounds of some kind. Google hasn’t made a statement yet, and Adobe has simply stated that it is “assessing the impact of ITP 2.1 on data collection”. It’s worth mentioning that I fully expect other browsers to follow suit, too. Firefox is making noises and may follow suit, and once Apple has taken the brunt of the fallout, others won’t be far behind.

While the changes in ITP 2.1 will ultimately be good for security and privacy, the way this has been executed will also negatively affect site owners who use analytics software legitimately. The ability of businesses to anonymously recognise their loyal users – on a single domain – in order to better serve them should not be unduly obstructed.

As such, I would encourage browser vendors to consider the collateral impact on legitimate analysis when tackling nefarious tracking practices, and encourage developers to educate themselves on their responsibilities when it comes to tackling the (frequently nefarious) problem of cross-domain tracking cookies. As John Wilander remarked on Twitter, “Hopefully we can get to a place where devs help prevent cross-site tracking.”

Until analytics vendors respond, I’d start looking at HTTP cookies (that’s what we’re doing). If you feel you could be adversely impacted by this change and want to discuss it with us, get in touch here.