Data insights
7. juni 2019
Get ITP 2.2 under control and avoid losing valuable user data
The day all marketers have dreaded has arrived: Apple has launched the ITP 2.2 update. Or rather, it is a day that all serious marketers should take seriously.

What does ITP mean?
First things first. ITP stands for Intelligent Tracking Prevention and is a software solution designed to make it increasingly difficult for Apple’s browser (Safari) to access user data via cookies.
The purpose of ITP is to limit what data can be collected about users through their cookies. With the 2.1 update, cookie data (web activity history) from Safari visitors could only be stored for 7 days. With 2.2, we are now down to just 1 day.
That means if your visitors’ customer journeys last more than 24 hours, you will have a problem with your Google Analytics data.
And unless you are a 24/7 emergency locksmith, your visitors’ customer journeys will always extend beyond 24 hours.
What does this update mean for me?
ITP 2.2 is a problem because cookie data from Safari users is now only stored for 24 hours. And that completely undermines the way Google Analytics attributes conversions to different channels.
Google Analytics uses a feature called “Last non-direct click”, which in plain terms means: “the conversion is attributed to the last channel the user interacted with before converting, as long as it was not a direct visit to the website by typing the domain into their browser”.
This attribution made sense before, when cookie data could be stored for many days. But now you lose data on your Safari users, because when they complete a converting action, going forward it will be credited to ‘direct traffic’.
Why does this matter to me?
Because your Google Analytics data is now incorrect. And your marketing channels—Facebook, Google Ads, and organic traffic—will suddenly lose a lot of traffic and conversions, because ‘direct traffic’ now gets the credit for them.
And then there is the fact that Safari users only make up somewhere between 20–30% of your visitors. In other words, you will be looking at data that is not representative for up to one third of your website’s traffic.
You will see that your SEO efforts no longer deliver the same return as they have so far. And that may lead you to make the wrong marketing decisions, because Google Analytics will now tell you that certain channels are no longer profitable.
Okay, but what does Apple even want with this?
At first glance, we thought ITP was created to mess with search engines. Apple makes nothing from the search market, whereas their biggest competitors do. On closer inspection, it actually turns out to be an initiative introduced for the benefit of users.
Because cookies are old technology. The original intention was that, as a user, you could allow a website to collect basic information about you and a bit of history. That is simply not the reality anymore.
Today’s reality looks like this:
- Second and third parties collect more and more data for resale, etc.
- Likewise, it has become easier for hackers to intercept data, as your data is shared with more and more parties.
What Apple is trying to do with ITP 2.2 is remove the middleman between websites and users. You have given a specific website permission to know something about you as a user—not various third parties.
Because cookie technology is outdated, and because data security is constantly in the spotlight, it is only to be expected that other browsers will soon follow Apple’s good example.
But there is a solution to all of this
The solution has actually always existed, and it is called ‘localstorage’. The point is not for this post to become heavy and overly technical, so here is a very brief explanation of localstorage:
- Cookies are user data stored in your browser (Chrome, Safari, Mozilla, Edge, etc.). This data can be accessed by third parties, e.g. Google Analytics.
- Localstorage is the same user data, also stored in your browser—but the data cannot be accessed by third parties.
So what needs to be done is to create a JavaScript that stores the user’s cookie ID in localstorage. When the user returns to the website in, for example, 10 days, we move their localstorage data into their cookie data. This way, we can continue to track Safari users correctly.
That sounds great… but is it legal?
The short answer is: YES.
The more detailed answer is that it is both legal and more secure, because cookies can effectively be accessed by anyone, including servers and, unfortunately, a lot of unnecessary third parties.
Unfortunately, there are also many “script hijackers” who hack into scripts, from which they can inject a lot of cookies so they can harvest data from you.
These people will now only be able to access your data for 24 hours before it is deleted.
The localstorage setup protects users’ data better, as only websites with specific permission have access to their localstorage data.
The solution we have come up with is quite straightforward in practice. We insert a piece of JavaScript on your website, which then asks users’ browsers for permission to access their localstorage data. The default setting in browsers is to grant access. The clever part, however, is that it only grants access if the request comes from the expected host.
For example, if you visit morningtrain.dk, the request for access to your localstorage must come from morningtrain.dk. If it comes from somewhere else, access to the data will not be granted.
This way, unnecessary third parties, hackers, and other bad actors do not gain access to users’ data.
At the same time, as a marketer you can still track all Safari users correctly. And because this is actually a good security measure, the other browsers will most likely follow suit before long.
So how do you solve it?
You need a bit of programming know-how to solve this task. You can Google complete guides, but you cannot avoid having a developer fix it for you.