With the release of Safari 11 and ITP (Intelligent Tracking Prevention) last September, Apple drastically altered how cookies and attribution on the web function. The new restrictions made it significantly more difficult to track users as they travel between sites on the web, and placed a much greater focus on user privacy and anonymity. This past June, Apple doubled-down on this focus with the announcement of ITP 2.0 and the more stringent restrictions it will bring. With Safari accounting for nearly 50% of mobile web traffic in the US, these policies have and will continue to change how web attribution works at the most basic level, but what does the update for ITP actually change—and, more importantly, what does it mean for the mobile world?
The Wide World of Web Cookies
Before diving into the changes to ITP, let’s take a quick step back and look at web attribution and how it’s evolved over the years. Web attribution has traditionally revolved around using cookies as a primary means of tracking users and their behavior as they travel around the Internet. These cookies are essentially collections of information that are stored on a website—or, more specifically, a web domain.
Cookies fall into two primary categories: 1st party and 3rd party, depending on where they’re stored. A 1st party cookie refers to a packet of information stored by a domain on its own web site, for example Google saving your username on gmail.com so that next time you try to log in, it is filled in automatically.
A 3rd party cookie functions in the same way, except it’s created or accessed by a domain separate from the one a given user is on currently. For example, say an ad network drops a cookie that stores information about where a given user came from as that user browses The New York Times’ website. These 3rd party cookies are traditionally used to track users as they travel between sites, which allows some larger ad networks and attribution companies to develop a stronger picture of each user. If you’ve ever looked a particular shirt on one site, and then seen ads for that same shirt on a bunch of different sites, you’ve seen 3rd party cookies in action.
Safari 11 and Intelligent Tracking Prevention
Safari 11 and Intelligent Tracking Prevention are designed to limit this type of ad by identifying common tracking domains and limiting their access to cookies. Apple uses a machine learning algorithm to determine whether or not a specific domain is being used to track user behavior based on factors like the number of unique domains redirected to by that domain, and the number of resources present on that domain. With the updated ITP 2.0, this algorithm has been expanded to identify domains that are used to quickly grab some information about a user and then immediately redirect to the user’s intended destination. Apple refers to these types of domains as First Party Bounce Trackers.
Once a domain has been classified as a tracker, it has to play by a stricter set of cookie rules. 1st party cookies are still accessible, but only for a max of 30 days after a user has interacted with that domain.
As an example, xyz.com has been designated as a tracking domain under ITP:
-
- Day 1: User visits xyz.com, and xyz.com drops a cookie with that user’s info.
-
- Day 5: User visits xyz.com. Their username is automatically populated from the cookie dropped on Day 1. Cookie refreshes.
-
- Day 15, 16: User does not open Safari. These days are not counted against the 30-day cookie lifespan.
- Day 40: User visits xyz.com. The cookie has expired and they need to re-enter their information.
Things get more interesting when 3rd party cookies come into play. With the first iteration of ITP, 3rd party cookies operated in the same way as above, only with a 24-hour expiration period as opposed to a 30-day one. Then from day 2 to day 30, they could only be accessed in a 1st party fashion. However, beginning with ITP 2.0, this system has been replaced by the Storage Access API. This new API is used by domains to request access to cookies on another domain, which then in turn prompts users to grant this access.
An Exploration of Cookie Lifecycles
Here’s an example of what a possible user journey would look like using this API:
-
- Day 1: User visits example1.com.
-
- Day 2: User visits example2.com. Example2.com uses example1.com as an attribution vendor. Example1.com calls the Storage Access API to gain access to cookies on example2.com. ITP notes that this user has never granted example1.com access to cookies on example2.com, so it prompts the user. User grants access.
-
- Day 15: User visits example2.com. Because they’ve previously granted example1.com access, no prompt is shown. Example1.com’s 30-day cookie lifetime is reset as a result of the user interaction.
-
- Day 35: User visits example3.com, which also uses example1.com as a tracker. User is prompted to grant access for example1.com to access cookies on example3.com. User denies access, and example1.com’s 30 day-cookie lifetime is not reset.
- Day 45: Example1.com’s cookies are purged as a result of no user interaction for 30 days.
Storage Access API prompt displayed to user.
There’s a lot going on in that example, however the key things to point out are the new user prompt that occurs when trying to access 3rd party cookies for the first time on a site, and the 30-day lifetime of any domain’s cookies. Both of these changes make it much harder to consistently track users across multiple domains.
Real World Effects
Now that we’ve reviewed how web attribution and cookie-tracking work under the hood, what does this actually mean for companies in the mobile space? All in all, this makes it much harder for companies to track users across multiple sites. For the Google’s, Facebook’s, and Amazon’s of the world, things don’t look quite as dire, since the popularity of these sites mean that users are frequently interacting and refreshing the 30-day lifespan of cookies. However, larger and smaller companies alike will have to present the new user prompt that appears when cookie access is first requested on a new domain. In fact, smaller networks will have to account for both issues, and the effects will be strongly felt. Criteo, a large retargeting ad network, predicted up to a 22% decrease in revenue, and that was before the more stringent requirements of ITP 2.0. In addition, the changes prompted a collection of six ad trading groups to state in an open letter that “Apple’s unilateral and heavy-handed approach is bad for consumer choice and bad for the ad-supported online content and services consumers love.”
How to Prevent a Domain from Being Classified as a Tracking Domain
The announcement of ITP 2.0 this past June means that these restrictions are not going away or loosening, so the question becomes what can you do about them?
If you’re a developer looking to comply with these regulations, the number one approach is to do everything possible to prevent your domain from being classified as a tracking domain. There are a few ways to accomplish this, with one possibility being Apple’s recommendation of using link decoration, or query parameters, to pass information between various different pages. If that’s not a possibility, you’ll want to familiarize yourself with the Storage Access API, and start fine-tuning solid messaging to users covering why your domain would access cookies on another site.
If you’re on the marketing side of things, you’ll want to familiarize yourself with how your chosen web attribution solution deals with the issues presented by ITP. Depending on the approach they’ve chosen, it may have an effect on the accuracy of the data you’re seeing.
Perhaps the best solution, however, would be to utilize Branch for your web attribution needs. We’ve opted to utilize Apple’s recommendation of link decoration to comply with ITP. Additionally, our attribution engine allows for more accurate, deduped attribution across your web and native properties, giving you a truly cross-platform, cross-channel view of your marketing campaigns and users.
The reality is, a significant chunk of brands’ direct and organic campaigns today have been inaccurately measured. By revealing the true digital journey of your users, Branch enables you to answer such questions as, “Who gets credit for this revenue?” and “Which search keyword drove this user to visit our mobile site, then install our app, and then convert?”
If you would prefer to feed the Branch-tagged data into your own warehouse or product analytics tool, Branch’s Data Integrations make it extremely easy to pipe the data out to the tool of your choosing.
With Branch’s attribution, you can protect your app from the continual threat of being classified as a tracking domain while simultaneously treating your users like people instead of like cookies.