How does Safari ITP and CNAME Cloaking affect marketing and analytics?
Are you seeing an increase in new visits from Apple browsers/products? Concerned about Apple’s ITP and CNAME cloaking updates? How does this affect Google Analytics?
You’ve probably heard rumblings about the latest update Apple has made in ITP to limit cookies set through CNAME cloaking. It’s less straightforward to understand compared to prior Safari’s privacy protection updates, but we’re here to help you out.
What is happening?
As a quick refresh, ITP (Intelligent Tracking Prevention) is what Apple calls the features they build into Safari to protect your privacy. This latest feature is designed to block 3rd party cookies that are trying to act like 1st party cookies.
(Left: 1st party cookies are accepted by default | Center, 3rd party cookies are blocked by default | Right: the 1st party domain request is redirected to a 3rd party domain, “cloaking” the true requestor.)
With 3rd party cookies being blocked by default, CNAME cloaking was invented.
Now the script initially sends a request to cookie.mysite.example but that request is redirected to mysite.3rdparty.example. So for the basic observer, the script is handing out 1st party cookies, but these cookies are actually coming from somewhere else. There are plenty of reasons to do this, most aren’t malevolent, but as with nearly every tool humans invent, it has been weaponized.
The folks working on ITP have figured out how to quickly discover this redirect, and label the cookie as a 3rd party cookie, which means Safari will automatically delete it after 7 days, regardless of the defined lifespan.
This leads to the question: how widespread is CNAME cloaking? Why did Apple (and others) think this particular technology was common enough to make blocking it a priority?
As it turns out, some mighty big names are employing this. The folks at Next DNS have found (and published) a list of 6 vendors using this at length:
- At Internet
- Commerders Act
Adobe Analytics and the related Marketing Cloud uses CNAME cloaking to set the ECID — Adobe’s universal ID for visitors. This is core to their visitor and device stitching capabilities (recognizing multiple devices as the same visitor) which fuels the value of multiple tools within the Experience and Analytics Clouds, Adobe Analytics, Adobe Audience Manager most obviously, but also the Device Co-op. The Device Co-op allows companies to participate in sharing the anonymous ECID device maps they have which means visitors can be recognized on different devices, even if they never visited your site on that device before – basically their answer to Google’s nearly universal login.
The others use CNAME cloaking for similar purposes — audience discovery and mapping — though with less emphasis on analytics and behavioral understanding than Adobe.
What is the problem this will create for organizations?
For orgs using any of the vendors mentioned above, the primary result will be an increase of new visitors from Safari browsers: iPhones, Macs, and iPads. Since this is a Safari feature (at the moment) each time a Safari users returns to a site, outside the 7 day cookie deletion, and doesn’t authenticate during the visit, that user will be a New Visitor and without an authentication, even repeat visits will not be stitched to other devices the user may use.
The race for privacy protection means the rest of the browsers won’t likely be far behind making this an option at least, if not even a default protection. Several ad-blockers already actively block CNAME cloaking.
For now the greatest impact will be on those sites that:
- visitors regularly frequent from multiple devices
- but don’t visit at least weekly from each device and
- don’t require authentication of some form (or some other method of identifying known visitors) at each visit
This is will especially impacts Adobe products:
- Analytics will lose attribution data points and Unique Visitors will be less unique
- Target can’t display consistent experiences to visitors across devices
- Audience Manager will lose unity for visitor profiles, both for individual orgs, but also for the marketplace of profile based segments
- Media Optimizer will lose ability to precisely target ads across device platforms
This actually might put Adobe at a disadvantage to Google for user tracking. Because the Google Login is so nearly universal, that allows for more robust device and profile stitching without needing to rely on CNAME cloaking, because Google can get all these IDs from first party cookies shared with them.
What can you do to mitigate the negative impact?
The only real solution is to require authentication (which is where most of the web will wind up, we are very nearly there as it is between Facebook and Google). The user’s logged in ID needs to be synced with the platform’s uui (e.g. Adobe’s ECID) which will allow for cross cookie/device stitching.
In lieu of requiring login you can also utilize email capture as a pseudo authentication, creating a unique identifier based on the email, this can be used similar to a login generated ID. This can be deployed at any point an email address (or representative) is provided, from clicks from link within emails to forms that capture a user’s email address.
Server side tagging offers some benefit since the cookies remain truly 1st party because all the requests and responses are server to server, distinct from the client, but also introduces complexity, and is outside the capacity for many organizations at this point.
It’s great to see the web offering more options for consumer privacy while still allowing analysts and marketers to understand & offer outstanding digital experiences. This is an incredible opportunity to deepen customer relationships with hyper relevant experiences – let’s talk about what it means for you, or drop us a comment below to discuss!