Industry

What Apple’s Intelligent Tracking Prevention 2.0 (ITP) Means for Performance Marketing

Alex Dent

ITP 2.0 HasOffers cookie solutions

November 2018 update: The September release of ITP 2.0, on Safari for iOS 12 and macOS Mojave has severely impacted the tracking capabilities of traditional performance and affiliate marketing platforms. Not so for HasOffers. As we invented postbacks, server-side postback tracking is natively built into our platform, and therefore tracking on HasOffers using this method has not been affected by ITP or related updates.


User privacy on the internet is a growing issue with policymakers and companies across the globe. The most recent example: In the latest update to the Safari browser, Apple is taking a stand against applications that seek to track users as they move across the web. While this update will make Safari one of the most secure places to browse the internet, it will also make Safari one of the most troublesome browsers for performance marketers, as ITP 2.0 interferes with mechanisms that are foundational to how the industry works today.

Sounds serious, right? It is, especially with Safari representing around 17% of all web traffic in recent months. But don’t panic yet. In this post, we’ll walk you through the expected implications of ITP 2.0 for performance marketers, the mechanisms affected by the update, and steps you can take to mitigate any negative impacts on your business.

(To be clear, the content in this post relates to web-to-web advertising. Traffic that goes web-to-app or app-to-app is not affected by this update.)

Are You an Advertiser?

Here’s what ITP 2.0 means for you: On Safari, your tracking cookies will be blocked — unless you’re using a subdomain of your site’s primary domain. For instance, track.tune.com would be an acceptable subdomain of tune.com.

Additionally, all of your affiliates will need to use postback (server-side) tracking to receive conversion notifications from you. This can be difficult if you are currently using a tag manager, as server-side tracking requires storage of identifiers on click. Using a solution like HasOffers can solve this issue. However, without a solution or workaround you’ll risk facing discrepancies of up to 40% with affiliates as well as possible loss of interest in your program.

Are You a Network or Publisher?

Here’s what ITP 2.0 means for you: Your tracking cookies will never be accepted on Safari, and your domain will likely be flagged by the ITP algorithm. Reality check: this is unavoidable. However, you can mitigate the impact with the following steps:

  1. Immediately switch to server-side tracking to prevent traffic loss.
  2. Additionally, work with your advertiser to make sure they use a tracking platform that can support first-party cookie-to-server-side notification tracking.
  3. Make sure that your advertiser is using a first party domain for all of their tracking pixels.

You will see less referral data as a side effect, but this is frequently masked, so it shouldn’t have too broad of an effect. Besides taking the aforementioned steps, network life should not be too broadly affected by this update.

Apple’s Intelligent Tracking Prevention 2.0: Under the Hood

Now that we’ve covered the implications for performance marketers, let’s break down Apple’s most recent blog posts to understand what’s happening in the newest ITP release. If you have the time and the inclination, you can read the full blogs here:

We’ll skip over the iterative nature of these releases and instead look at the cumulative results of ITP 1.0 through 2.0.

Step 1: Classification of Domains

Domains will be dynamically classified by a machine learning algorithm. Details are understandably sketchy as to the decisioning process, but a few criteria have been made public:

  1. First Party Bounce Tracker Detection. Detects when a domain is used for redirect tracking only. This will be applied recursively for all domains in the redirect chain.
  2. Sub Resource under number of unique domains. Related to the number of paths available under a domain. Tracking platforms currently have a very small number of these.
  3. Sub Frames under number of unique domains. Related to the number of page frames available under the domains.
  4. Number of unique domains redirected to. If you’re still reading, this one probably doesn’t need any explanation.

There is no whitelist or blacklist built into the system, each device will build its own tracking prevention list based on web usage. Apple seems to suggest that this can be reset by clearing cookies.

Step 2: Eat All the Cookies

That’s right: the third-party cookie is dead — on Safari, at least. If a domain is classified as a tracking domain via the machine learning-based classification engine described above, Safari will prevent the storing of cookies. To persist cookie data, Apple will require three things:

  1. The cookie must be from a first-party domain.
  2. That first-party domain must have user interaction. This definition isn’t totally clear, but it seems to suggest that the user must actually browse the site and click on something.
  3. That first-party domain must receive repeat user interaction. Cookies will persist for only 30 days. After 30 days, data will be blackholed until the next user session.

Step 3: Limit Referrer Data

For domains classified as possible trackers that have not received user interaction, the referrer will be truncated to just the fully qualified domain name, therefore dropping any additional path information. This will prevent trackers from gaining access to user information contained in the path that may have required cookie access to obtain.

This action will make it impossible for most tracking domains to store and recall cookies. It will also make it impossible to obtain user interest information from referrer collection. It would seem the target of many of these enhancements are the “like” and “+1” buttons that track user interactions across the internet, but it’s obvious there will be collateral damage in performance advertising as well.

So Where Does This Leave Performance Marketers?

In addition to the above, Apple has said that link decoration (query string parameter-based tracking) and server-side notifications (i.e., postbacks) are the preferred methods of tracking in Safari going forward. This is good news for performance marketers, as it still allows for the standard tracking people have come to expect from mobile campaigns.

However, there is one problem with that: unless the advertiser is using an attribution SDK, or is already tracking their offers with HasOffers, the chances are slim that their platform (if they even have one) is able to support postbacking. The HasOffers platform was built to solve challenges like ITP 2.0, as our history of mobile and web tracking has allowed us to develop tools that turn client-side tracking into server-side notifications. If your advertiser could benefit from HasOffers, let us know by emailing [email protected] for more information.

We believe this is a great opportunity for affiliate networks to take a step toward improving the user experience of performance advertising and apply the learnings from millions of mobile offers to the world of web. Gone will be the days of waiting minutes for pages with thousands of tracking pixels to load. Gone will be the days of having to clear cookies and cache every few weeks so hard drives don’t fill up with garbage. Gone will be the days of inaccurate tracking. Welcome to the mobile age, web. We’re ready for you.

 

To learn more about ITP 2.0 and how the HasOffers platform can future-proof your tracking capabilities, see our next article, “The Future of Performance Marketing: An ITP 2.0 Update and Tracking FAQ,” or contact [email protected].

To learn more about TUNE and user privacy under the new General Data Protection Regulation, visit our GDPR page.

Never miss a thing!

Want the goods delivered straight to your inbox?
Sign up for our blog recap emails to stay in-the-know about digital marketing, analytics, and optimization.

Author
Alex Dent

As the Director of Innovation at TUNE, Alex plays a variety of roles: team manager, product manager, and future-thinking agitator. He spends most of his time learning and turning his learnings into confluence documents. He is a recovering entrepreneur, and occasional Canadian. Alex holds a Computer Science degree from the University of British Columbia.