Understanding ITP and its effects

6 min readAug 3, 2021

What is covered in this article?

ITP overview
Browser treatment of cookies and Adobe cookies’ lifetime
How to see what ITP is blocking in your browser
Next steps and thoughts on future of tracking
References

Note: the details in the article are my thoughts based on the articles I have read and the research I have done, this is not an official Adobe statement on ITP and its effects on Adobe solutions.

ITP — what is it?

ITP stands for Intelligent Tracking Prevention, the underlying concept has been introduced by the webkit.org, this is a nonprofit institution that defines the core behavior of browsers. Safari and all major browsers running on iOS platform comply with these principles. The main goal of tracking protection is to remove user fingerprinting and scripts silently tracking user data without appropriate consent.

In safari this is implemented based on algorithmic model that trains on the user’s browser locally, hence is most effective for that user.

Browser restrictions based on the latest release — ITP 2.3:

1st party context: if I am browsing adobe.com, all the assets and links with adobe.com as the domain are considered first party context.

3rd party context: if I am browsing adobe.com and it is loading an image from google, then the url for that asset is considered third party context while on adobe.com.

Kinds of storage available in a browser:

Cookies
indexedDB
localStorage
sessionStorage

Below table provides an understanding of the how each browser treats a cookie and classifies trackers. I have taken information available on various blogs to compile this table, details of the referred sites are given in the references below. One additional thing that I have added in this table is to provide the details on how each browser treats the Adobe Experience Cloud cookies, User scenario: user visited adobe.com home page from browsers, e.g. chrome, firefox and safari.

To make complete sense of the below table, you ll need to know the definition of each cookie set by Adobe solutions, which can be found here: https://experienceleague.adobe.com/docs/id-service/using/intro/cookies.html?lang=en

ITP release timeline:

ITP 2.1 — Safari — Cookie 7 days (first party JS cookie) (only for those sites identified as having cross tracking capabilities)
ITP 2.2 — Safari — Cookie 1 day (first party JS cookie) (only for those sites identified as having cross tracking capabilities)
ITP 2.3 — Safari — All data capped to 7 days (script writable — from JS)
CName Cloaking — Blocked in Firefox and Safari and Brave (rollout on the way)

Seeing what ITP blocks:

There are a few ways of seeing the ITP classification on a browser, since the algorithm runs locally, the restriction is not uniform for all users on safari, below are the ways to look at the ITP restrictions:

Step 1: The privacy report: you can look at the privacy report for any site by clicking on the small shield icon to the left of the address bar, it is not necessary that all the domains shown in the privacy report are being blocked, since the blocking happens via the algorithm.

If you want to see more details, click the (i) button on the right side of the dialog box.

Step 2: There is a feature in iOS 14+ to see the domains that are classified as. trackers. To see that, follow the instructions below which are based on Mac OS big sur 11.4 and Safari 14.1.1.

a. Open Safari

b. Open ‘develop’ option in the main menu

c. Click on ‘intelligent tracking prevention debug mode’

d. Go to any website: e.g. adobe.com

e. Open the web console on Safari by going to develop and select ‘show javascript console’

f. Filter the messages by ‘ITP’

g. 3rdpartytestwebkit.org is set by default in ITP messages, so you should see. at least that entry

Impact of ITP on Adobe solutions:

Any ad tech or mar tech solution leveraging visitor identification via browser cookies would get affected. Below is a possible list of issues that could be seen in the Adobe solutions due to the cookie restrictions:

ID service — Visitor identification is set to 7 days in Safari, as opposed to 2 years in other browsers. When a visitor comes back after 7 days, the visitor gets a new ecid value.
Analytics — Since Analytics depends on ECID for visitor identification, the visitors in Analytics are counted as new visitors if they visit the site after 7 days gap. More details on ITP effects on Analytics and method to build ITP affected visitors report on this link: https://experienceleague.adobe.com/docs/analytics/technotes/cookies/cookies.html?lang=en
Target — The active tests that run over 7 days are affected. When a user comes back to the site any time after 7 days, the user is identified as a new visitor and would be evaluated for the test again. More details on the effects of ITP on target in this link: https://experienceleague.adobe.com/docs/target/using/implement-target/before-implement/privacy/apple-itp-2x.html?lang=en
Audience Manager — Profile merge rules across devices get affected when the last authenticated profile option is used. The segments the user qualified for in the existing device would work, given that the user comes back in 7 days. If the segment is written against the user profile, then the segments would be returned in authenticated state only.

What Next:

Any cookies that are set on the browsers with HTTP response, i.e. using the Set-Cookie header in the HTTP response from a first party domain are not affected by the ITP 2.3 rules, as long as there is no cname cloaking being done. In the below screenshot from apple.com, you can see that there is a cookie called ‘dssid2’ that has around 2-year validity:

We should be able to leverage first party cookie set using a response header method for visitor identification and mitigate the 7 day cookie drop issue. However, this method would work currently only for Analytics, when the data is sent to Analytics via bulk data ingestion API. Audience Manager and Target cannot consume a client side first party identity as the solutions’ primary identity just yet.

To set this First-party Cookie, client-side IT teams need to develop and implement a visitor identification service that would ID the users in a first-party cookie context, and Adobe solutions need to develop the capability to ingest data from the clients’ server side based off the client maintained first party identity.

I have seen some posts talking about using a first party domain as a proxy to route the Analytics data eventually to Adobe servers, however this route is implementation heavy, since we are talking about setting up a first party proxy to be scaling to process all the requests from the client, once all the hard work is done, it’s a matter of time before the safari ITP engine picks up the proxy as a tracking domain and cuts the cookie lifetime. Remember, we are up against an ML model that runs on the individual browsers, so the domain exclusion is specific to each individual’s browsing behavior.

I am hoping the capability to capture data on a client specific first party identifier using the server-side launch methodology is launched soon, so that we can enable Adobe clients to capture their first party data securely.

References:

Following articles were referenced during writing my article, please go over these articles for further knowledge on ITP impact in general: