How Apple’s Intelligent Tracking Protection (ITP) Changed Marketing Data Tracking and Analytics

In a previous blog post, I covered what the end of third-party cookies means for marketers. 

In the year since first writing that post, things have changed dramatically, and Apple’s Intelligent Tracking Protection (ITP) has become even more disruptive.

To quickly recap, Apple created ITP to make it harder to track user behavior across sites. The biggest change was shortening the life of cookies and effectively blocking third-party cookies.

What are the impacts of ITP on marketing?

Ad tech and MarTech is less effective

In doing so, ITP decimated remarketing ads and made the measurement of ad performance on Facebook and Google much less accurate. Before ITP the Facebook pixel could measure and identify people across multiple devices, leveraging third-party cookies, whereas after ITP this became much less accurate because these cookies expired in as little as one day and at most seven days.

Attribution is more difficult

Shortening cookie lifetimes has also made marketing attribution more difficult. If a user returns to a site more than seven days after their last visit. Any analytics tools relying on using cookies to identify returning users will see the user as a new user even if they have been to the site before.

If you’re selling a high-consideration product where a purchase journey in which the time between website visits is larger than seven days, the returning user will be seen as “new” in Google Analytics and other analytics tools.

First touch and last touch attribution almost devolves into just last touch attribution with ITP.

What exactly is Intelligent Tracking Protection (ITP)?

To quickly recap, Apple created ITP to make it harder to track user behavior across sites. The biggest change was shortening the life of third-party cookies. This made it much harder for Facebook or Google to track a single user’s behavior across multiple sites and devices and use this to profile user behavior.

What exactly is a first-party vs. a third-party cookie?

First-party cookies are domains set on the domain of the website the user is on. For example, when you’re on Amazon.com, it sets a cookie on “amazon.com” to keep you logged in and to track your viewing habits.

Third-party cookies are cookies set on a third-party domain. These are frequently set by ad tech vendors like Meta, which sets a “facebook.com” cookie when you visit any site with their pixel. These are used largely to track your behavior across multiple sites.

Third-party cookies present an obvious privacy challenge

This ability to track users across multiple websites is precisely why third-party cookies present a privacy challenge. Having a third-party cookie allows Meta and Google to know what sites you’re visiting and build an ever larger profile of your likes and interests, which makes their ad targeting ever more effective.

The rise of Apple ITP

To address this obvious problem, Apple rolled out ITP to block third-party cookies, but in doing so they largely changed the definition of what a first-party cookie is.

Not only does ITP take action against third-party cookies, but it has also started treating first-party cookies more like third-party cookies. Essentially, any cookie set by JavaScript will automatically expire seven days after the last time a user visits the website, even if the cookie has an expiration date longer than that.

iOS 17 has escalated the war on tracking technology

In the new ITP that is rolling out with iOS 17 devices and with Safari 17 on Mac, ITP has escalated things.

Blocking trackers that map subdomains to third-party IP addresses

With ITP blocking cookies set from third-party trackers, especially ad tech platforms, a popular way to get around this was to simply use a CNAME DNS record to change the script to load from a site’s subdomain.

This is something done by many platforms, including Marketo, Pardot, Segment, Google Tag Manager, and most other modern analytics tools.

Instead of the tracker loading and setting cookies on “x.tracker.com,” it would load at “tracker.yoursite.com” and would set a “first party” cookie on “yoursite.com.”

Now, Safari 17 identifies that you have “masked” the name of the tracker, and it will treat the cookie as third-party cookie and set its expiration to only seven days.

Blocking for known tracking query parameters in links

This feature strips away tracking parameters in links, such as click identifiers such as “gclid” (from Google Ads) and “fbclid” (from Facebook), from being passed when users click on links in emails. It also applies to links when using Private Browsing Mode or when “Advanced Tracking Protection” is enabled on all browsing, which I will be covering below.

This means that a click on a Google ad that would generate a link such as “yoursite.com?gclid=1234” will have that value stripped, and the analytics code would not see it.

This fundamentally breaks Google Ads and Google Analytics attribution, as this is used to determine what ad a user clicked on.

Moreover, having a query string with any ad tech identifier, such as Google Ads gclid causes all cookies set by the browser with JavaScript to expire in one day, not just the cookie for the ad tech platform.

Example: The cookie Segment sets is called ajs_anonymous_id and when loading a page without a gclid in the URL, the cookie is set to expire in one year (although in reality, it expires in seven days after the last interaction on the site).

But when the user comes back with a referrer from a known tracking domain, like Facebook or Google, and a click identifier from that platform, such as gclid or fbclid, all cookies expire in less than 24 hours.

This has huge implications because having a click tracker reduces the effectiveness of the entire MarTech stack. This means that even the most innocent cookies, such as cookies used to keep users logged in, will get cleared after 24 hours if they are set via JavaScript and a user clicks on a link from Facebook.

“Advanced Tracking Protection” escalates the stakes of ITP by blocking tags entirely.

This is where iOS 17 and Safari 17 have dramatically changed the way ITP works. The big change is that Safari on iOS 17 and Safari 17 on Mac have introduced a new privacy setting called “Use Advanced tracking and fingerprinting protection.”

ITP Advanced Tracking Protection also blocks tags for CDPs like Segment or analytics systems like Amplitude even if they are loading outside of Google Tag Manager by blocking their respective script CDN domains (i.e.: “cdn.segment.com” or “cdn.amplitude.com”)

While this feature is now opt-in, it could very well become opt-out in the future, much like Apple’s changes to mobile ad attribution.

Consider that, in the US, iOS devices account for 56% of the smartphone market. The impact of this is potentially catastrophic for tracking if you are using Google Tag Manager to handle your tagging.

What can you do about this?

Collect your own data

Fundamentally, marketers are going to have to shift from relying on third-parties to handle attribution and will need to collect attribution data themselves.

This means collecting users’ email addresses and setting static identifiers when a user signs up or logs in so that multiple visits are tied back to a single user.

A good example of this in action is Amazon, which keeps its users signed in, which means that ITP isn’t a problem for Amazon at all. 

For some businesses, it’s natural for their users to remain logged in or log in each time they come to the site. For others, this is less easy, but it’s critical to find ways to continuously sign in each time they visit the site.

Work with advertisers that let you use first-party data

Many ad tech vendors let you upload first-party data to improve match rates on ads and build “custom audiences” to improve targeting.

Facebook and Google allow marketers to send users’ email addresses and phone numbers on conversion events, which gives them another touchpoint to measure conversions, even if tracking is completely blocked on a website. 

Own your user journey

ITP largely kills remarketing campaigns. Nurturing customers in your own ecosystem via email, SMS, push notifications and other “owned channels” becomes critical and completely sidesteps this issue.

The upshot of all of this is that you get better analytics and you can measure the effectiveness of your campaigns at a 1:1 level vs. the shot in the dark that comes with remarketing.

This requires providing strong incentives to have users opt-in and remain opted-in to your content so you can continue to market to them.

Technological fixes to mitigate ITP

With these radical changes in ITP, marketers need to take steps to mitigate the potential loss in tracking and site functionality by updating their marketing tech stack to take these changes into account.

Use a CDP for data acquisition and activation

Using a CDP like Segment is a way to build a full picture of a user’s journey because it can combine multiple customer touchpoints using deterministic data to tie together sessions.

Furthermore, it helps leverage your first-party data to do things like sync audiences with marketing automation systems like Braze and with ad tech vendors like Facebook and Google to create powerful, multichannel campaigns.

Self-host all your tools to mitigate ITP and Advanced Tracking Protection

While ITP is always going to be an arms race, self-hosting or proxying your analytics stack will help mitigate a lot of the impact of Advanced Tracking Protection and ad blockers in general, both of which block scripts entirely. Some examples of ways you can do this include:

1. Migrating to Google Tag Manager server-side tagging to load GTM from your own domain.
2. Using domain proxying with Segment.

Reduce dependence on tag managers and third parties

Ultimately, the less client-side surface area you have on your analytics and marketing stack, the more resistant it will be to ITP and other tracking blocking. Some things you can do here include:

1. Implementing client-side tracking code directly into your site’s front-end code

In some cases, tag managers may be blocked. By loading your most critical tags directly on your page, you can still track things if your tag manager is blocked. (Although if those scripts are also blocked, this will not help.)

2. Set “server” cookies

ITP impacts all cookies that are set by JavaScript, whether they are set on your domain or not. But cookies set by a server that handles things like keeping you logged in, are not affected by ITP and remain set even after seven days.

This is why you can come back to Amazon weeks later, and you’re still logged in; they are using “server” cookies that are not subject to ITP blocking.

By using specialized server-side coding in your tracking, you can set tracking cookies with a server-side function, which can be more durable than the JavaScript cookies.

One version of this is Segment’s “Edge Functions,” which uses Cloudflare workers that can do, among other things, set “server” cookies, remove the source write key from the browser, and retrieve user traits from Segment Engage and include these in the event context.

3. Use your own database as an event stream via reverse ETL

You’re probably capturing a lot of data in your own systems and storing it in either a data warehouse or a data lake. For example, if you’re running an e-commerce business, you’ll have complete data on order events and customer PII, which can be used as a trustworthy “source of truth” for revenue.

Being able to leverage this data with ad platforms and your analytics stack is a matter of ETL’ing the data out of your internal tools into a data warehouse like Snowflake with Fivetran. And then using a Reverse ETL product like Segment to move the data from Snowflake to your marketing stack and to ad platforms to create remarketing audiences.

Conclusion

Mitigation of tracking block is always going to be an arms race

While all the mitigations outlined above offer a path to mitigating the impact of ITP right now, the unfortunate truth is that every fix marketers take to mitigate blocking will, sooner or later, result in the opposite reaction from the WebKit developers to mitigate the “fix.”

For this reason, it’s always important to remember that marketing analytics is directional and should not be your only source of truth. Marketing analytics has always been about proving which channels are generating the most revenue, or “what Y actions does a typical user take to complete action X”.

You don’t need to know what 100% of your users are doing, you only need to know “what Y actions” users are taking in aggregate.

But regardless of this being an arms race, it is still prudent for marketers to take whatever steps they can to mitigate the changes.