Everything you should know about safari’s ITP 2.0 rollout

By now, you already have noticed all the fuss about the emergent release of Apple’s Safari ITP (Intelligent Tracking Prevention) 2.0 rollout for iOS12 and macOS Mojave in Q4.

This was already announced in late 2017. So at Kwanko we were already working in some improvements to our technology to limit any eventual impact this might have on the business.

What’s safari’s intelligent tracking prevention (ITP)? 

The main purpose is to give much more privacy and control to the user. That’s the main goal. It places some restrictions on cookies based on how frequently a user interacts with the website that dropped them. That’s basically it.

However, for the Affiliate Marketing community, this can be a new challenge since it can affect how we track the customer journey and conversions.

How can it impact our performance tracking?

The ITP is constantly evolving so, there will be even more changes in the future. For the time being, what 2.0 has changed from its previous versions, is the removal of the 24-hour window for which a pixel from a third-party can access cookies. This means that when the ITP 2.0 is launched, the usual tracking will not work at all if we’re flagged as a tracker. Moresome, existing cookies will be purged after 30 days if there’s no “real” interaction with the user again.

The second biggest change is that if it sees a tracker collusion to have redirects to identify the user through several trackers, it will block that info also. Which means that when a user clicks on a Publisher ad by Kwanko, as always, it will first redirect to Kwanko’s tracker and only then to the Advertiser’s site. With this restriction, this feature will prevent cookies from being dropped or read on a user’s browser during these tracking redirects.

In other terms, if there are redirects before our click domain, we will only see the last redirect as the referrer instead of the original Affiliate source.

The third change is what it’s called Origin-Only Referrer. Pretty much truncates the referring URL’s down to the root domain. Which means that if it was coming from publishersite.com/article it will arrive at the destiny as just publishersite.com without more information than that.

As the report states, this is currently just for mobile and desktop versions of Safari. Even though the desktop Safari browser is kind of small compared to other browsers, in the mobile realm, it’s quite massive if we consider almost all of the Apple devices out there. So, it’s not something we should take lightly.

What can we do about it?

There are a few changes to be made to our tracking tags. But pretty much, what would happen with the ITP 2.0 is that it adds a prompt to WebKit’s implementation of the Storage Access API. So, if the user allows access their choice is persisted.

Here’s a graphic example of what a prompt message would look like.

This warning box is displayed when using the Storage Access API to allow a user to confirm his consent. If a 3rd party JS tag tries to write a cookie without this API (with the conventional method) the notice box will not pop up BUT, if this 3rd party is considered a “tracker”, its cookie will be “partitioned”.

Still, we have a cookie lifetime for just 30 days, but if the user keeps interacting, for what Safari considers to be a “real” interaction with our domain name it will keep this alive for an additional 30 days. If not, it erases automatically.

All explanation can be found right here at the source.

Also, we already have a “cible” tracking method which we’re adapting to convey with these new requirements and it will be ready for the time Safari launches its new version.

Any question or doubt, do not hesitate to contact us.