Apple’s latest ITP updates: What marketers need to know

  •   December 12, 2019

Apple’s WebKit team is out with another update to Intelligent Tracking Prevention (ITP) for Safari that targets potential tracking workarounds.

In a blog post titled “Preventing Tracking Prevention Tracking,” WebKit’s John Wilander laid out three updates to fight detection of “which content and website data is treated as capable of tracking” and “improve tracking prevention in general.”

First, some background on Safari, ITP and cookie blocking. Safari has long restricted entities from setting third-party cookies if they don’t already have first-party relationships with users. Then ITP came on the scene in 2017 to identify and limit cookies of any type that have the ability to track users across sites. This severely limits cookie pools for audience targeting, including retargeting campaigns. Furthermore, it limits analytics and attribution data from Safari, which means marketers lose visibility into how their campaigns are performing with typically high-value iOS users.

If you thought Safari and ITP’s previous iterations had pretty well done in third-party cookies, you’d be right, but there are more holes to plug. The updates below apply to Safari on iOS and iPadOS 13.3, Safari 13.0.3 on macOS Catalina, Mojave, and High Sierra.

Cross-site request referer headers

The change. “ITP now downgrades all cross-site request referrer headers to just the page’s origin. Previously, this was only done for cross-site requests to classified domains.”

What is a referer header request? When a user clicks on a link from one web page to another, the referer header request on the new page contains the web address of the previous page. That can be used for analytics, logging or optimized caching. It can also be used for tracking (and poses other potential security risks which we won’t get into here),

What the change means. Of the updates, this is the one that will have analytics implications. If a user clicks from one web site to another, Safari will strip out the URL details contained in the request referer header.

This means your analytics will only show the referring domain, not the referring page.

Example. A user navigates to https://images.example from https://store.example/baby/strollers/deluxe-stroller-navy-blue.html. In Safari, the referrer header will not contain that entire URL. It will only include the root domain https://store.example/.

In this case, your analytics would record only https://store.example as the referrer and not the full referrer path of /baby/strollers/deluxe-stroller-navy-blue.html.

(More) third-party cookie blocking

The change. “ITP will now block all third-party requests from seeing their cookies, regardless of the classification status of the third-party domain, unless the first-party website has already received user interaction.”

What the change means. This is really aimed at preventing attackers from “seeing their cookies.” It is minor from a marketer’s perspective but further reinforces the need for first-party relationships with users. If you have widgets placed on other sites, it doesn’t matter what your domain classification is, you will need to have a prior first-party relationship with a user in order to see your cookies on those sites. This has been the case in most contexts already.

Example. A user clicks on a YouTube video embedded on a news site. If that user has not previously logged into or visited and accepted cookies at YouTube.com, YouTube will not be able to track engagement from that site.

If you’re not a heavily trafficked site like YouTube and count on tracking from widget embeds, you have little to no visibility into Safari users.

Storage Access API update

The change. “As of this ITP update, the Storage Access API takes Safari’s cookie policy into consideration when handling calls to document.hasStorageAccess().

Now a call to document.hasStorageAccess() may resolve with false for one of two reasons:

  1. Because ITP is blocking cookies and explicit storage access has not been granted.
  2. Because the domain doesn’t have cookies and thus the cookie policy is blocking cookies.”

What is the Storage Access API? This API enables third-party embedded content to gain access to storage that is typically only accessible in a first-party context. With the Storage Access API, embedded items can determine if they have access and request it from the browser’s user agent.

Typically browsers will not give third-party embedded resources access to the same set of cookies and site storage. And document.hasStorageAccess() indicates whether the document has access to its first-party storage.

What it means. This, too, is aimed at attackers and will have little marketing implication. Detlef Johnson, Search Engine Land’s resident technical SEO expert, explained it this way, “The Storage Access API change is about closing a gap of a false positive API response pertaining to the third-party cookie policy of a given website. For example, an attacker could conceivably figure out if you’re a YouTube user or not by making a malicious request for storage access.”

Why we care

It’s important to understand how Safari and ITP affect your ability to target and measure ad campaigns.

Apple is not an ad-driven business and has staked its branding on protecting user privacy. As ITP’s restrictions have evolved, advertisers have had to continue to adjust expectations as Safari becomes a bigger black hole. Publishers and third-party adtech firms have felt the pinch. A recent report by The Information (subscription required) found CPMs for Safari users have plummeted as a result of not being able to sell ads based on cookied browsing behavior, while CPMs for typically less-valuable Google Chrome users have ticked up.