Apple recently released another update to Intelligent Tracking Prevention (ITP), which brings it up to ITP 2.2. What exactly is ITP, what does this latest update mean, are you ITP 2.2 compliant, and how do you keep your marketing safe from any negative side effects? Let’s take a look.
Remind me, what is ITP again?
Apple created ITP in the name of privacy. Essentially, the original ITP made it harder to use third-party cookies to track Safari users on iOS and MacOS. The big target here was not ad attribution, but rather the creepy ads that seem to follow users around the internet. The original ITP 1.0 added a 24-hour window to cookies in the domains it flagged so they could be tracked cross-domain, after which access to third-party cookies was blocked. This posed problems for many tracking providers since a good deal of tracking is done with third-party cookies.
A common workaround for marketers was to switch to first-party cookies. However, in later ITP versions (2.0, 2.1, and now 2.2), Apple began limiting the use of first-party cookies as well. (Impact spelled out ITP 2.0’s big changes last August.) ITP 2.2’s biggest change from 2.1 and 2.0 limits the duration of some first-party JavaScript-set cookies to one day—down from the seven days that ITP 2.1 implemented.
For a cookie to be capped at one day by ITP 2.2, three conditions must be fulfilled:
- The cookie is set via JavaScript (or in their words, “set through document.cookie”)
- The site that sent the user to the landing page has been classified by ITP as “having cross-site tracking capabilities”
- The link uses link decoration (it uses query string parameters and/or a fragment identifier)
What’s the potential impact of ITP 2.2?
Enterprises using tracking that does not comply with ITP 2.2 may be at risk of losing attribution whenever the last click before a purchase on Safari occurred more than 24 hours earlier. In other words, if the last click occurs more than 24 hours before the conversion, a partner will not be credited for the conversion.
Apple’s Safari browser accounts for 15% of all web traffic and 21% of mobile web traffic globally. Safari’s market share is even higher in the United States, where Safari accounts for 31% of all web traffic and 49% of all mobile web traffic.
Impact’s own benchmarking shows that roughly 87% of Safari conversions occur within 24 hours after the last click. This means that ITP 2.2 could cause lost tracking for 13% of conversions within Safari. Globally, that’s only about 2% of conversions (13% of 15% of total web conversions). However, that number gets higher in the United States, where 4% of all web conversions and 6.4% of mobile conversions could be lost (13% of 31% and 49%, respectively).
How do I know if my tracking is compliant with ITP 2.2?
Warning: this will get a bit technical (and long), but we think it’s important to talk about exactly what is happening here. Let’s look at the three main categories of tracking integrations available today: 1) gateway-pixel tracking, 2) JavaScript tags, and 3) server-side tracking.
1) Gateway pixel tracking: This is the old-school affiliate way to track, which involves tracking links and an HTML code snippet that loads on the thank-you page to track the final conversion—it has not been recommended since ITP 2.0 came out in 2018. There are workarounds that allow some degree of post-ITP Safari tracking, but we have encouraged all our clients to upgrade from pixel tracking.
2) JavaScript tags: A more modern (and very popular) way to track, this method can be (but is not necessarily always) compliant with ITP 2.2.
In the past, JavaScript tags have been a good solution to the ITP problem, because cookies set by JavaScript on the advertiser’s site are considered first-party cookies, rather than third-party. Early versions of ITP only targeted third-party cookies, so JavaScript tags were a good solution.
However, these “first-party” cookies are still being written and read by a third party like Impact. Thus, from a cross-domain tracking perspective, there is very little difference between these first party cookies and the third party cookies ITP originally set out to manage.
As a result, ITP 2.2 specifically targets cookies set via JavaScript., as opposed to cookies set via HTTP. If the other two requirements are fulfilled (domain is flagged as a cross-site tracking domain and the link uses link decoration), then cookies set by JavaScript tags are going to be capped at 24 hours by ITP 2.2.
For the sake of transparency, let’s talk about how Impact is addressing this. Many of our clients use a JavaScript tag to do their tracking. We call it the Universal Tracking Tag, or UTT. The UTT sets cookies via—you guessed it—JavaScript. Our tracking servers are rightfully classified by ITP as having cross-domain tracking capability, and all tracking links use link decoration to identify the partner who referred the traffic, the ad that was clicked, and so on. These three factors combined mean that cookies set by the UTT will be affected by ITP 2.2.
Fortunately, this is pretty easy for us to solve. We already offer clients custom tracking environments, which include a unique tracking domain. By providing these custom tracking environments to each user of our UTT, we can take our cross-site tracking domains out of the equation; the domain that sent the user to the page will only be used to direct users to one site. The resulting cookies now only fulfill two of the three requirements to be capped, and are thus exempted.
We expect that others in our space will have similar solutions, but as you may have already realized, there is a big problem at the heart of not only JavaScript tracking, but cookie-based tracking in general. Namely, the goalposts keep moving. Solutions that are compliant for ITP 2.2 may or may not be for 2.3, 4, 5, and so on. We will continue working to keep our clients ITP-compliant in the least-intrusive way possible, but we are also advocating adoption of the only tracking method that cannot be interfered with by browsers, privacy and ad-blocking extensions, or even operating systems. That method is….
3) Server-to-server tracking: This has become something of a buzzword lately, so it will be helpful to debunk some myths and explain exactly what we mean. Server-to-server tracking has been around for a very long time, and simply means that an advertiser is passing conversion (sale or lead) data back to a tracking provider via API or FTP. That is, the advertiser’s server is sending data directly to the vendor’s server.
This is often called “cookieless tracking”, but the truth is that no tracking method on the web is truly cookieless. At the very least, the advertiser will need to use their own cookies to identify the user and process cart events. Historically the way server-to-server tracking was done was to require advertisers to capture the ID of the tracking link click and then pass that value back when they reported the conversions. The way advertisers typically did this was by storing the Click ID in a cookie and picking it back up when the conversion occurs. They then could send that value in their API call or FTP file to the tracking provider, allowing them to attribute the conversion to an earlier click.
This approach is usually going to be fine, but there’s still a potential weak spot in that the advertiser is required to capture the Click ID that the tracking provider creates, and then preserve that information until a conversion happens. If that Click ID cookie is set via JavaScript and the user arrived on the site after clicking a tracking link, then that cookie will be capped at 24 hours by ITP. The API can’t prevent that cookie from being deleted, and thus that partner’s contributions being erased. Essentially this type of “cookie-less” solution just punts the cookie logging off to the advertiser rather than truly remove the need for cookies altogether.
Our approach to API’s is a bit different. Like others, we receive conversion data from advertisers via API. However, we eliminate the need for a Click ID cookie by also receiving data from the advertiser via API on click. Each time a user clicks a tracking link, the advertiser directly sends us anonymized data about that user. Then we can simply compare that click data with the conversion data we receive – and use that to attribute the conversion to the right partner. And because we use a deterministic identity graph, we can traverse a large set of identifiers to make sure we are finding every relevant match for that consumer journey.
Our tracking methodology does not require any new data to be collected by the advertiser for our purposes and is therefore not vulnerable to current or future changes that Safari, Chrome, or Firefox may make. This is why we can confidently call our API suite a future-proof tracking solution: it only relies on information that advertisers are already collecting, and it does not require any new cookies to be saved in a user’s browser (which means that browsers can’t delete them).
Afraid of ITP 2.2 derailment? Keep your tracking on track
From Impact’s earliest days, tracking has figured as a central part of our mission. Impact provides a robust tracking technology platform—whose sole job is to make sure your program continues to work no matter what challenges come up.
Consequently, Impact already offers solutions for marketers’ various tracking challenges—ITP 2.2 or otherwise. Make sure your tracking (and thus conversions and overall program growth) stays on track:
- If you’re an Impact client, please contact your client success manager.
- If you’re interested in upgrading your current solution, contact a growth technologist at sales@impact.com.
- If you’re not sure whether your tracking is ITP-compliant, you can test your Safari tracking using these steps.
