ITP 2.1 & Adobe Analytics - 70% Of Sites Are Still Exposed

published on
Our research shows that just 30% of websites using Adobe Analytics are correctly set up to mitigate the cookie restrictions laid down by Apple's ITP 2.1 update 

Update: A previous version of this post stated that 90% of sites were exposed, this figure has been revised down to 70%.

Apple's Intelligent Tracking Prevention 2.1 update was a big one for the Analytics industry. It rewrote the rules for how 1st party cookies behave on Safari, creating a distinction between 1st party 'client-side' cookies - those set by the JavaScript document.cookie API, and 1st party 'server' cookies - those set from the HTTP header of a resource from your domain.

Along with this distinction, ITP 2.1 also placed heavy restrictions on 'client-side' cookies, limiting their lifetime to just 7 days. The effects of these restrictions on Adobe Analytics setups were substantial - at this point they relied on the following cookies to correctly identify users:

Cookie NameAdobe ID TypeCookie Type
AMCV_###@AdobeOrgMarketing Cloud / Experience Cloud ID1st Party 'client-side'
s_viVisitor ID1st or 3rd Party 'server-side'
s_fidFallback ID1st Party 'client-side'

Adobe Analytics setups using the s_vi cookie in a 1st party context were safe from the change. For Experience Cloud ID users and others, where previously these cookies would not expire for a minimum of 2 years (or 5 years for s_fid), they would now be purged after 7 days.

The net result was this: A Safari user who last visited your site 10 days, or 3 months, or 1 year ago - where before they could be identified as that same user when they returned, ITP 2.1 meant it was now as if you had never seen them before. The implications? Increased Unique Visitor count, broken Marketing Channel attribution, human sacrifice, dogs and cats living together, mass hysteria.

The solution for setups not using Adobe's Experience Cloud ID service is simply to sign up to the Managed Certificate Program. This is a service offered by Adobe, at no extra cost, that enables use of a subdomain belonging to your own site as your Adobe Analytics tracking server. So on your website example.com, instead of analytics requests being routed to Adobe's 3rd party 2o7.net or omtrdc.net endpoints, you'd see a call to something like metrics.example.com. This allows the s_vi cookie to be set as a 1st Party 'server' cookie from the HTTP header of that call. Without this service, the s_vi cookie is blocked by Safari (being set from 2o7.net or omtrdc.net makes it a 3rd party cookie - blocked by default), and so the s_fid fallback cookie comes into use, which as a 1st party 'client-side' cookie is subject to ITP 2.1

Adobe also came up with a solution for Experience Cloud ID users. Three months after the initial ITP 2.1 announcement, they released v4.3.0 of their Experience Cloud ID (VisitorAPI.js) library, in which a fix was implemented that completely nullified the restrictions set by ITP 2.1 on their 1st party cookies.

As a prerequisite, users still had to be signed up to the Managed Certificate Program. Adobe's updates then allowed for a brand new s_ecid cookie to be set as a 1st party 'server' cookie (from the HTTP header of metrics.example.com). This new cookie supplements the 'client-side' AMCV_###@AdobeOrg cookie, ensuring it stays up to date. The s_ecid  cookie does not fall foul of ITP 2.1, so we're back in business.


Now, almost six months on from Adobe's solution, we polled the top websites in the world (as defined here by Quantcast) to find the state of Adobe Analytics implementations across the web with regards to ITP 2.1.

Of the 310 sites we tested, 50 used Adobe Analytics. The results:

1st Party Tracking Server, No ECID Service

20%

20% - 10 of the 50 sites tested were correctly using their own 1st party tracking server and had not implemented the Adobe Experience Cloud ID service.
Outcome: s_vi set as a 1st party 'server' cookie

1st Party Tracking Server, Correct ECID Version

10%

10%5 of the 50 sites we tested were correctly using their own 1st party tracking server and were using an updated version of the Experience Cloud ID service.
Outcome: s_ecid set as a 1st party 'server' cookie

1st Party Tracking Server, ECID Version Too Low

46%

46% - 23 of the 50 sites tested were correctly using their own 1st party tracking server, but were not using an updated version of the Experience Cloud ID service.
Outcome: s_ecid set as a 1st party 'server' cookie, but not being used

3rd Party Analytics Tracking Server

24%

24% - 12 of the 50 sites tested were using either 2o7.net or omtrdc.net endpoints, rather than their own 1st party metrics.example.com.
Outcome: 
s_vi blocked as a 3rd party cookie, s_fid set as a 1st party 'client-side' cookie

 

In total, just 30% of Adobe Analytics users have taken the proper steps to ensure correct data hygiene. Of those using the Experience Cloud ID service, that figure drops even further to 18% (5 out of a total 28).

You can refer to our full breakdown below to find out who didn't make the cut, but amongst those correctly set up was of course adobe.com, using a 1st party tracking server, and a recent Experience Cloud ID version. Also, unsurprisingly compliant - apple.com, who were not utilising the Experience Cloud ID service at all. 

So what's the hold up for everyone else? Are analytics owners not aware of the implications or ITP 2.1? Are internal processes preventing them from pushing their changes through in a timely manner? Whatever the reason, the integrity of their Adobe Analytics data continues to suffer.

We've published our working for the figures and sites shown above - you can find it here.

Comments