What's New in ITP Two Point Two
What is ITP
ITP stands for Intelligent Tracking Prevention - it’s a feature of the Webkit engine, used by the Safari browser, which is aimed at preventing tracking and retargeting Safari users. There is a number of ITP versions already out there - ITP 1.0, ITP 1.1, ITP 2.0 & ITP 2.1. You can find a comprehensive historical overview of the ITP development at Simo’s blog. In this article, we'll focus on ITP 2.2 that will be released in autumn 2019. More specifically we'll look into:
- Upcoming ITP 2.2
- Issues with the cookies due to the ITP 2.2
- Impact of ITP 2.2 on you from the marketing standpoint
- What you can do about it
Release of ITP 2.2
As you may already know, previous versions of the ITP banned the use of 3rd-party cookies from the websites identified as “having tracking capabilities” and the 1st-party cookie's lifespan, for those set by document.cookie, was limited to 7 days.
Big AdTech players as Google and Facebook did some workarounds and shifted their retargeting and tracking focus from 3rd-party cookies towards 1st-party cookies. This worked for some time, but with the ITP 2.2, 1st-party tracking cookies are going to have a 24-hour lifespan.
How does it affect tracking - technical side
As an outcome, we get that all of the cookies set by the document.cookie (tracking scripts) are being removed within 24 hours, which is a simple and elegant solution.
How does it affect tracking - marketer side
This is an easy one - data consistency will be messed up. ¯_(ツ)_/¯
How bad it is going to be? It depends on what solutions, that rely on the document.cookie method, you are using. ITP 2.2 will dramatically affect:
- Analytical solutions (Google Analytics, Facebook, etc.)
- Conversion tracking solutions (Google Ads, Bing Ads, etc.)
- A/B testing solutions (Google Optimize, Optimizely, etc.)
- The number of new visitors for Safari browsers is likely to skyrocket due to the fact that if users visit the site with a 24h break between the sessions - they will be recorded as new users.
- Attribution models will be disrupted as, due to the previous point, it will be impossible to construct a chain of visits for Safari users.
- The conversion rate for returning users will be impossible to calculate as there simply will be little to no returning users.
- The number of recorded conversions will drop as only the conversions that happen in the first 24h will be recorded, while usually, conversion tracking has a 30-day lookback window.
- The conversion rate will decrease dramatically due to the previous point.
- You won’t be able to assign users to variation or control groups consistently, thus, probably, harming the user experience.
In this section of the article, we'll look into solutions listed in Simo Ahava’s blog, describing the benefits and drawbacks of each solution and suggesting a solution that we've preferred ourselves.
In short, most of the solutions have issues with:
- Scalability - resource-intensive implement of the same solutions for anything apart from Google Analytics.
- On-page events - most of the solutions don't take into consideration events that happen without page reload, while these events do overwrite the cookie values.
The idea is pretty simple - store data within the local storage instead of cookies.
If you have no subdomains - it works pretty well for Google Analytics. In case you have sub-domains - you'll need to configure a page that will serve as an iFrame for accessing localStorage on the pages of the subdomain.
All in all - a pretty efficient solution for Google Analytics as you can configure Google Analytics tags to stop setting cookies and use the clientID from the localStorage.
However, the solution is not easily applicable to other tracking scripts as you will need to configure each one of the scripts to set & retrieve the equivalent of the clientID to & from the localStorage each time the script is executed, which could be pretty burdening task if you are using GTM together with the featured tags.
In this case, you are avoiding ITP restrictions by setting a cookie from the server instead of document.cookie. There is a variety of possible implementations, but all of those rely on a server in one way or another.
Need to keep in mind that not all of the events on the page make calls to the server, therefore, you will either be required to set up a function which will trigger the server-side solution each time the script is executed, or you will need to get rid of events that don't result in a call to the server.
In addition to that you need to be ready for:
Handling N number of requests. For Google Analytics each hit sent by the script updates the cookie and you'll need to reset the cookie from the server-side for each of those hits. You can approximate the number of requests to be handled by servers by looking into how much hits your Google Analytics view receives - that is the number of requests for re-setting the cookie that you will need to handle for Google Analytics alone.
Cookie value. Setting an empty cookie from the server side is pointless. You have two options here: either you wait for the script to set the cookie with the value and pass that value to the server, or generate your own value in the server (in case there was no cookie before). In the first scenario, you need to be sure that the cookie value is there before passing it to sever. In the second one - you probably will have to look into how each of the cookies of your interest is generated and implement a unique way of generating a cookie value for each solution provider.
What else we have at our disposal?
This will help you to avoid dealing with the huge number of server requests for cookie updates, handling cookie generation and preventing scripts from updating cookies during on-page events.
How does it work?
The main thing to note about the cookie interceptor is that it can be used to “catch” the moment when there is an attempt to set a cookie with the document.cookie, and what happens next is absolutely up to you.
We have come up with the following sequence:
How does it solve the issue with “N’’ number of server requests for resetting the cookie?
The answer is - fairly easy because you have full control over re-setting the cookie from the server-side, for example, you can proceed with re-setting the cookie if the expiration date is in less than 1 year.
How does it solve the issue with cookie values?
That's also not a problem as each time there is an attempt to write the cookie by the tracking script - you intercept it and thus, you already have a cookie value at your disposal. No need to worry about generating specific cookie values for each of the tracking scripts out there.
Cookie interceptor works on the latest browser version, but, this should not be an issue as the ITP 2.2 will work on the latest Safari browsers which are supported by cookie interceptor. Also, you could take a look into the “returning some fake cookie from interceptor callback” step as, probably, there is a way to avoid that, thus, simplifying the setup.
Let us help you!
Got more questions about ITP? Feel free to contact us via email firstname.lastname@example.org or click the orange chat bubble. Learn more about our analytics services and how we can work together to improve your eCommerce website!