station10
Typewriter-blog.png

Blogs

our views and our knowledge in analytics and other releveant topics


our blogs


ITP2 - The biggest, and best kept secret announcement of the year

 
secure-lock.jpg

ln mid-March, a few weeks before the originally planned Brexit day of March 29th, a small announcement was made on a highly influential, if not-widely known, web site.  For digital marketers and for most digital analysts, this announcement will be by far the most important and business-impacting change of 2019.  And yet, even within the digital marketing industry, most people are blissfully unaware of the change.

The WebKit web site announced, with immediate effect, the implementation of the ITP 2.1 release.  WebKit is the developer of the Safari browser, and the Intelligent Tracking Protection (ITP) initiative is Safari’s programme to limit the impact for how cookies from different domains can be used on its browser.

ITP 2.1 changes the cookie window for analytics cookies to 7 days.  From 2 years.  And the more recent ITP 2.2 release changes the cookie duration to 1 day.  From 7 days.  I repeat, the changes mean that analytics cookies on Safari will only last for 1 day, unless the user interacts with the site.  So, if someone looks at the site on 1 April, and then looks again at the site on the 10 April, they will not be recognised, as the previous cookie has been timed out.  This applies to both Google Analytics and Adobe Analytics cookies (or indeed, any others for that matter). 

This will cause challenges for any attribution modelling across channels, because Safari is so commonly used by visitors on mobiles (iPhones, of course), so if you want to understand what an individual customer does across channels, and mobile traffic is an important part of the journey, this will cause significant data capture issues.

Why have Apple and WebKit decided to pick on the humble hard-working analytics cookie?  Well, to be fair, it’s not really analytics cookies they have taken umbrage with.  The official reason is that it’s part of Apple’s ongoing attempt to eliminate cross-domain tracking.  Cross-domain tracking is the way in which most ad networks track and record their users, and enables those ads that follow you round the internet.  There are also legitimate concerns about how this technology can be used for more nefarious purposes, including data leakage and hidden data breach attacks.  But really it’s about limiting cross-domain tracking and limiting how ad networks and cross-device personalisation can work.

There are technical reasons for this, in that many of the standards that could be used by developers to make cookie setting more secure are not being adopted widely.  And that’s how most of the changes are being positioned and justified.  But it’s something of a sledgehammer approach, and those legitimate uses of cookies across domains for site owners who have set up tools across domains (say, www.blah.com and www.blahinvestors.com) are just collateral damage.  And analytics tracking, using cross-domain tracking, is first in line to take the hit of that collateral damage.

Apple’s strong “sorry, not sorry” approach to this change indicates there is more to this than just privacy concerns.  It’s hard not to see this in the context of wider device wars, with Apple taking a swipe at the other big players in the space, principally Google and Adobe, but also the range of ad networks, to weaken their offering, whilst Apple’s own ability to know where you are at any one time through features like Find My Phone remain curiously untouched.  Google, Adobe and Salesforce are all picking various fights with each other, so this can be seen as Apple’s particular battle to be picked with the other main players in the wider market.

That said, there are legitimate concerns around privacy, so let’s return to the main details.  What does this mean for analytics and insight teams?

Firstly, assess the extent to which this will affect you.  If Safari is not a significant platform for you, or if you are in the luxurious position of having a single domain, then you have longer to plan.  However, you should still plan a strategy to address this; once Apple have taken the flak, it’s very likely that the other browser companies will follow suit, and Mozilla, the makers of Firefox, are already intimating they have their own plans in this area, and are moving to a 7 day window. So, doing nothing is not a strategy.

Secondly, if you haven’t already, move your analytics tracking to first-party tracking.  If you are an organisation with multiple domains (the friendly third-party cookies), which in truth is probably the majority of organisations directly affected, you should also start investigating how you can move your infrastructure onto a single domain, so that you won’t need to pass any cookies across domains in the first place.  However, I appreciate that for some organisations, there are either legitimate reasons for this set-up, or making such a change would be a vast undertaking.  As a second-best alternative, you should look to adopt some of the recommended standards that have not been widely used to set cookies.  This is in essence WebKit’s stated aim in this initiative, so you should look to avoid using the document.cookie Javascript function to set your cookies.  The recommended method would be to set them via the HTTP response (that is, server side).  Alternatively, for Adobe, you can use the CNAME certification.  As this moves away from the Javascript function, this should therefore be a long-term solution to these issues, as it uses the standards that Apple is wanting to drive.

Having said that, the major analytics vendors are currently looking into this, and at workarounds that will maintain their capability.  So, don’t rush to change all of your analytics implementations quite yet, but do keep talking with the experts, and with the analytics vendors.  At the moment, these responses don’t seem fully formed.  Google’s approach is to encourage everyone to implement GTM or GTag to turn everything into a first party cookie.

Adobe’s latest update is as follows, and their solution focuses on using the CNAME to get round this issue.

Thirdly, this has wider ramifications than just analytics.  It raises the question about how you might do things like attribution modelling or customer recognition and personalisation at the back end, rather than through the browser and cookies.  If you don’t have a single customer view, or are using a service like Adobe’s Experience Cloud ID, you should start looking into this.  This turns this into a more strategic, long-term solution.

Finally, though, this is in effect the next stage of legislation around cookies and privacy.  Although this is not the EU Directive around PECR, which is the much delayed and long-awaited “sequel” to the GDPR regulations, much of what the original draft PECR plans wanted to do was to get the browser companies to “regulate” how cookies are handled.  It was always unclear how the EU and governments would manage to get the browser companies to become the policemen of the Internet, but it would appear that, in relation to cookies at least, they have already started doing this.  So, whilst we still await the PECR regulations, it may well be a moot point, and if you follow what WebKit are asking you to do more universally, then you will do at least what the legislators may ask for in the foreseeable future.

 
BlogsDavid Ellis