Intelligent Tracking Prevention 2.1 and Google Analytics
Apple recently announced version 2.1 of Safari’s Intelligent Tracking Prevention (ITP). ITP is a feature built in to the Safari browser. In short, it protects user privacy by restricting how cookies can be used and for how long they can stay active in the browser.
The first iterations of ITP focused intensely on third-party cookies. And rightly so. Third-party cookies are what ad tech companies have used to track individual users across different websites (cross site tracking). They have done so in order to build profiles of individual person. Mostly with the goal of targeting advertising.
Facebook - for example, because they’re far from the only one - responded by replacing their usage of third-party cookies with first-party cookies. That’s why you may have noticed that a lot of referral traffic from Facebook suddenly displayed a fbclid parameter on landing pages. So they basically made a workaround and continued their practice of cross site tracking.
It’s that type of practice, which ITP 2.1 addresses now by further restricting the usage of cookies - this time around, the restrictions are just applied to first-party cookies. Apparently because big ad tech haven’t gotten the message.
Your traffic is about to increase
By targeting first-party cookies, ITP will - for the first time - directly impact data collection and data quality in Google Analytics.
The new restrictions now limit first-party cookies (which are used by Google Analytics) in a manner that will delete them after seven days of inactivity on the site.
In other words, Google Analytics will no longer be able to recognise users as returning users if the returning visit occur more than seven days from the previous visit.
This might sound like a small thing. And for many sites it will be. But regardless, this means that you’re likely to see an increase in the number of users, more new users and - on an aggregated level - probably a larger share of mobile users (since a lot of Safari traffic is from mobile).
However, one of the most significant implications is on attribution. Since a lot of conversions often occur after many days and many visits, it will become difficult, and in some cases even impossible, to analyse the journey in terms of paths to conversion.
In general, several metrics are affected by ITP 2.1, but suffice to say that this will have major impact on sites with larger shares of Safari users.
One important thing to notice is that the ITP update only affects cookies set with javascript through document.cookie. HTTP cookies are not affected.
A/B testing is affected too
You’re likely in some sort of danger zone too, if you run A/B tests on your website. Specially if you’re using third-party tools such as Visual Website Optimizer (one of the most popular A/B testing platforms). These tools often use first-party cookies to ensure that users are consistently exposed to the same variation on each visit.
Imagine how the validity of your test results will be damaged if users are likely to see both a control version and a treatment version of a landing page before converting?
One short term solution might be to simply exclude Safari users from your experiments. But in many cases that will also mean that you’re excluding a significant portion of your mobile traffic in general.
A better, but obviously more complicated solution, would be to make a switch towards server side testing; i.e. where developers setup variations on the server, identify users who should participate in an experiment and how to expose those users with a specific varition.
Many A/B testing platforms do not support that - at least, Visual Website Optimizer doesn’t. But it is possible to setup in Google Optimize or Conductrics - and likely some other tools.
What should I do?
First of all, find out if this is a problem. Identify how many of your users that use Safari at all. You’ll find those numbers in Google Analytics below Audience → Technology → Browser. Is is most of your users? Is it most of your mobile users?
Next, open up the Audience → Active Users report. With this report open, setup a segment that includes all users with the Safari browser. Now, if most of your users (+90%) fall within the categories 1 Day Active Users or 7 Day Active Users, then just breathe and relax. It’s unlikely you will notice any differences - most of your Safari users are on your site frequently and will renew their cookies on each visit.
However, if most of the users are in the 14 Day Active Users or 28 Day Active Users categories, then you have a problem. Your Safari users simply don’t visit you frequently enough to renew their cookie, but will get a new cookie on each of their visits.
And no, there’s not a lot you can do about it. Unless you have the possibility to do server configurations. Well, it is possible to use localStorage in order to preserve the Client ID, but that solution is far from perfect (read this post by Simo Ahava).
A better solution would be to make a switch to Measurement Protocol entirely, generate Client IDs yourself, and set your own HTTP cookies. But that’s a process that is complicated, costly and simply too much for many companies.
There are other workarounds too. I recently wrote a Composer (PHP) package that will make Google Analytics use HTTP cookies. It’s not perfect either, and doesn’t support cross domain tracking, for instance.
The last option is simply to wait. Perhaps Google will come up with some guidelines or new implementation rules, or perhaps the Analytics community itself will find a good solution.
What not to do?
Don’t clap your hands in excitement when you see your traffic and mobile share increasing when ITP 2.1 rolls out. That would be fake news if you reported it.
Don’t immediately purchase or implement another Analytics platform. Unless it’s server side based. Several other analytics platforms out there use the same cookie technology.
Adobe Analytics, though, use HTTP cookies by default, so it should not be affected. Matomo (formerly Piwik) actually uses javascript cookies, but can be configured to use HTTP cookies too.
My view - at the moment, because my view tends to shift - is to wait. Perhaps Google is working on new guidelines or implementation options, they might even be working on a server side SDK or something else. If not, I’ll put my trust in the Google Analytics community. A lot of clever people are discussing the best way to tackle this.
So consider yourself warned now :)