This article won’t recount the history of Safari’s Intelligent Tracking Prevention (ITP) initiative, nor will it offer explicit guidance on implementing one of the many workarounds that are now proliferating. Instead, my goal here is to provide you with a digestible summary of what the forthcoming update to ITP means for you, as a site owner, and what you need to be doing to prepare for it.
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.
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
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
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:
- Using localStorage to persist the unique identifier (i.e. the client ID) instead of relying solely on the
- Setting the
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
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.
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.