Analytics Blog
Intelligent Tracking Prevention May Cause You to Collect Faulty Data
Alex Molineux
In the analytics industry, we have had some time to come to terms with Apple’s Intelligent Tracking Prevention (ITP) and its impact on our ability to track Safari users across multiple sessions. The WebKit team continues to push forward in their efforts around consumer data privacy to protect users from cross-domain tracking, with their latest update targeting a potential ITP workaround: CNAME cloaking.
The cloaking method is used fairly frequently throughout the industry, particularly by Adobe, meaning this update is certainly something to take note of and to consider in relation to your current analytics tools and data. The limits imposed in Safari’s ITP make tracking users across sessions much more challenging: IDs stored in cookies will only persist for seven days (sometimes less), meaning your analytics data could already be faulty. (Note: we’ll get to how to mitigate these impacts in a bit!)
Apple’s Intelligent Tracking Prevention Recap
We don’t want anyone wasting time working with faulty data, so before we dive into the CNAME cloaking and potential solutions, let’s briefly recap the state of play in regard to ITP.
Apple’s Safari ITP 2.1 release is where the bigger impacts on the analytics industry started to be felt, so for now, we’ll ignore the releases prior. We’ve covered ITP and the impacts on analytics tools in some detail before, but in summary:
ITP 2.1
In February 2019, ITP 2.1 was announced and limited the lifespan of first-party cookies set via client-side JavaScript. Up until this point, first-party cookies had been considered “safe,” but now they’d have a lifespan of only seven days on Safari browsers (think of all the iPhone users!).
ITP 2.2
In April 2019, ITP 2.2 was released and focused on closing certain loopholes that companies, such as Facebook and Google, had been using to mitigate the initial impacts of ITP. The lifespan of first-party cookies was reduced from seven days to 24 hours if the following were all true: the cookies are set via client-side javascript, the user reached your site from a website classed as having “cross-site tracking capabilities” (all major ad networks including Google and Facebook), and the link the user clicked on to reach your site contains link decorators.
ITP 2.3
The game of “whack-a-mole” continued in September 2019 with the release of ITP 2.3. Instead of using cookies, companies had been able to leverage browsers’ localStorage to store data previously kept in cookies and not be subjected to Intelligent Tracking Prevention limits. With ITP 2.3, a website was marked for non-cookie data deletion if a user reached the site from a domain deemed to have cross-domain tracking capabilities and arrived via a link containing link decoration. Non-cookie data (i.e., localStorage) would then be deleted after seven days if the user does not revisit the site.
All these updates limit the ability of analytics tools to track the same user across sessions if their site visits are more than seven days apart. This impacts reporting in a number of ways, making New/Returning User counts highly suspect and causing inaccuracies in attribution modeling, among other issues we’ll touch on later.
Recent ITP updates impact reporting in a number of ways, making New/Returning User counts highly suspect and causing inaccuracies in attribution modeling.
As you can see, as each Intelligent Tracking Prevention version is released, companies pivot and find workarounds, only for another Safari ITP update to be released targeting these workarounds. In recent updates, ITP has targeted CNAME cloaking.
How CNAME Cloaking Works
For web browsers, “first party” is typically defined by the registrable domain of a site. Therefore, a site (www.yoursite.com) and its subdomain of blog.yoursite.com are considered the same site and same (first) party. Being considered the same party allows first-party cookies to be shared between these sites, meaning login cookies and user identity cookies can be shared and set by these sites in a first-party context. Cookies such as these are not impacted by Intelligent Tracking Prevention rules, as they’re created by the website itself, and are seen as unrelated to third-party ad tech or tracking technologies.
CNAME, or canonical name records, map one domain name to the other as part of the Domain Name System (DNS). This means a subdomain could be configured to resolve to a third-party domain before resolving to an IP address.
So far so good, but how does this fit in with Intelligent Tracking Prevention?
In practice, it means that a site owner could configure a network request to a subdomain of their own site, say analytics.yoursite.com, that ultimately resolves to a third-party domain used for data collection, such as an Adobe domain. This third-party domain could then set a cookie, containing a user ID, via the Response Header. This cookie will appear to the browser to have been set from the original same party subdomain the network request was sent to, meaning the cookie is not subject to ITP lifespan limitations.
This is, in effect, the CNAME cloaking method and has, up until recently, allowed for the creation of persistent cookies from third parties, including analytics and experimentation tools such as Adobe.
WebKit’s CNAME Cloaking Defense
In the name of consumer data privacy, Intelligent Tracking Prevention continues to expand to counteract any technology that would potentially allow cross-site tracking. On the blog post outlining their “CNAME Cloaking Defense,” the WebKit team highlights that “cross-site trackers have convinced site owners to set up CNAME cloaking in order to circumvent tracking protection,” leading to WebKit’s new data protection efforts to defend against CNAME cloaking.
As with all ITP updates, we view these efforts as being mostly focused on ad tech that, if left unchecked, will aggressively track user journeys across the web, monetizing this data by using it to serve purchase and content recommendations to users across multiple sites. The impact on analytics tools, used by companies themselves to better understand and serve their users, appears to be an unfortunate byproduct of the efforts Apple is making to combat invasive ad tech.
The Safari ITP updates taking aim at CNAME cloaking are built into Safari 14 on macOS Big Sur, Catalina, Mojave, iOS 14, and iPadOS 14. For context, as of October 2020, Safari 14 browser market share stood at 7.4%, up from 2.7% in September 2020. Safari 13 still has 8.3% of browser market share, showing Safari 14 is likely to continue increasing market share in the near term.
On these operating systems, Intelligent Tracking Prevention is now able to detect CNAME cloaking requests and caps the lifespan of any cookies set within the HTTP response to seven days. This update means ITP is closely aligned in how it handles cookies set via client-side JavaScript, localStorage, and cookies set server-side after CNAME cloaking.
The End Of CNAME Cloaking And Its Impact
Much as ITP 2.1 started to clamp down on the use of first-party cookies set client-side, this latest Safari ITP update signals the end of developers and analytics tools being able to set cookies with long lifespans via CNAMEs.
This ultimately means that problems for analytics tools associated with ITP restrictions will now start to impact you if you use third-party tools that rely on setting cookies containing user IDs via CNAMEs. My previous ITP post covered a number of these issues in some detail, so I recommend reviewing that article if you haven’t already. I’ll also highlight some of the bigger issues here:
- Increasing New User counts and decreasing Returning User counts as cookie lifespan restrictions mean user IDs don’t persist across user’s sessions.
- Attribution modeling inaccuracy — It is more likely that conversions are going to get attributed to first-touch if users are not accurately tracked across sessions causing smaller look-back windows.
- A/B testing data quality concerns — With a decreasing ability to track users across sessions, there’s a risk A/B testing tools may bucket the same user into different test variations through the course of a test, thinking they’re a different user each time.
- Decreasing impact of personalization campaigns — If your personalization campaigns rely on user IDs in cookies set via CNAMEs, then tracking users over time will be less accurate, meaning any historic data associated with an expired user ID may be lost once the user is assigned a new user ID. In practical terms, this means it’ll be challenging for your personalization efforts to meet customer expectations, given the difficulty you may encounter in identifying users accurately.
How To Limit The Impact of WebKit’s “CNAME Cloaking Defense”
…ultimately a server-side setup appears to be the most robust approach for long-term user ID tracking.
While mitigating the impact of this update can be tackled on a number of levels, there is no one-size-fits-all solution here, and we recommend reviewing approaches on a case-by-case basis — something we’d be happy to support you and your team on if you fall into the category of those impacted.
A lot of initial responses have pointed toward moving from CNAMEs to A Name registration — using “A records” to resolve to third-party IPs used for tracking. As mentioned earlier, Adobe makes frequent use of CNAMEs, and they noted this A / AAAA record approach in a response to the Apple update to say that they don’t recommend it, given the ease that WebKit could identify IPs associated with Adobe and other tracking tools and then release an update to limit cookies set from HTTP responses associated with those IPs. If the recent history of Intelligent Tracking Prevention is anything to go by, we’d expect WebKit to crack down on this approach if a significant number of companies and vendors switched to it.
The approach we’d most likely recommend would be to adjust how cookies containing user IDs are set. Rather than relying on client-side JavaScript (hopefully you’ve been avoiding this since ITP 2.1) or CNAMEs, work toward setting cookies server-to-server. Doing this for all analytics and measurement tools and ensuring the IDs persist may be time-consuming, and each tool will have different challenges, but ultimately a server-side setup appears to be the most robust approach for long-term user ID tracking.
In the second half of their CNAME response, Adobe highlights a number of services they provide that’ll allow Adobe customers to configure their own first-party IDs, highlighting how the Adobe Experience Platform can be used to stitch together a selection of disparate user IDs into one user record. Customer data platforms (CDPs) such as Adobe Experience Platform or Tealium AudienceStream are designed to effectively stitch multiple user IDs to one user, thereby pulling data from multiple data sources into one user record. In some cases, leveraging a CDP and user IDs that aren’t impacted by Intelligent Tracking Prevention may allow for better tracking of all users across the tools you use, even if the user IDs set by some of your tools are impacted by ITP.
…leveraging a CDP and user IDs that aren’t impacted by Intelligent Tracking Prevention may allow for better tracking of all users across the tools you use…
At the non-technical level you have options as well. Check how much Safari traffic your site receives. Question whether you could continue to do the analysis you need with this traffic excluded. If you have a rich historic data set, you may be able to model Safari traffic behavior based on past trends and use this to inform future analysis without relying on more recent ITP-impacted data. If you’re able to keep Safari ITP impacts in mind and appropriately account for the impacts to your current data set, you could certainly keep working with it to draw accurate and impactful insights.
Privacy and ITP Forecast: Continued Change
Consumer data privacy rules and regulations are a hot topic and won’t be going away anytime soon. The landscape is constantly shifting, and we do our best to guide our clients through these changes. This recent CNAME update is one that likely warrants different responses for different companies depending on existing setups, tools used, technical resources, and plans for how to leverage user data. If you utilize CNAMEs in your analytics implementation and are looking to mitigate the impact of these recent changes, let us know and we’d be happy to help!
Related Insights
Digital Analytics
User Privacy
If you have questions or you’re ready to discuss how Blast can help you EVOLVE your organization, talk to an Analytics Consultant today.
Call 1 (888) 252-7866 or contact us below.
Check out our other articles on BlastX!