How Intelligent Tracking Prevention Will Affect Web Analytics, And What Google Analytics Users Can Do About It

by Pat Cooney

No doubt, by now you’ve heard that WebKit released a blog post in February that introduced the latest version of the Intelligent Tracking Prevention (ITP), which Apple has included in the latest beta releases of the Safari browser for both the macOS for desktop and iOS. I’m sure there are many questions around what ITP is, how it may affect your reporting in Google Analytics, and what, if anything, you’ll be able to do about it.

First off, let’s talk about what it is.  ITP is a feature that has been developed by WebKit, which is the web browser engine used by Safari, as well as Opera and Chrome.  At the time of writing, only Safari has been using the ITP feature and, as WebKit announced about the latest releases from Apple, will be using the latest version of this feature.  The first version of this feature was announced in June of 2017, and the subsequent ITP 1.1 update was released in March, 2018.  That version of ITP targeted third-party cookies that were used by domains for tracking user behavior, directly affecting advertisers who rely on the ability to build audience profiles of their users by tracking the sites they visit. Any cookie that behaved like this had a 24 hour window to get approved by the ITP feature.  Approval was granted if the user visited the domain of the cookie within 24 hours of the cookie being set.  If this condition was met, this cookie was allowed to go about its business for 30 days before the browser would remove it.  This didn’t really affect the website measurement capabilities Google Analytics (GA), which work in a first-party context, but it did cause a lot of headaches for advertisers and marketers trying to build quality audience profiles.

Shortly after ITP was released, WebKit released the Storage Access API.  This was WebKit’s attempt to make some concessions to third-party services that embedded content into sites – think embedded video content or social media login forms.  To use this API there was a list of rules that needed to be followed but zero prompting of the user was required so it remained seamless for the user’s experience.

ITP 2.0 was released in Mid-2018.  In this update the 24 hour grace period was eliminated and use of the Storage Access API required a user prompt, asking them to agree to have this cookie set.  If the user agreed, then the cookie would be set and would be allowed to persist for 30 days, after which it would be removed and a new cookie would need to be set.  This still didn’t affect first-party web analytics in GA.

TL;DR – Let’s Recap The ITP Releases

Date What released? Who was happy? Who was mad?
June 2017 ITP 1.0 Anybody that likes privacy online Anybody that relies on 3rd party trackers, and, to a much lesser extent, anybody who relies on 1st party trackers.
March 2018 ITP 1.1 Anybody that likes privacy online Anybody that relies on 3rd party trackers, however, those relying on 1st party tracking tracking saw no change since 1.0
Mid-2018 ITP 2.0 Anybody that likes privacy online Those relying on 3rd party trackers are even angrier now (they lost their 24 hour grace period), however, those relying on 1st party tracking saw no change since 1.0
Soon ITP 2.1 Anybody that likes privacy online Well … let’s take a look.

So, What’s Going On With ITP 2.1?

ITP 2.1 was released with the beta releases of iOS 12.2 and Safari 12.1 on macOS High Sierra and Mojave on February 21, 2019 and it’s only a matter of time before these beta releases become full releases and ITP 2.1 is fully released into the world.  In fact, it appears that the features that are now bundled as ITP 2.1 have actually been quietly rolling out since the beginning of 2019.

ITP 2.1 has made further changes to third-party cookies and how they are being managed when they are set by domains that engage in cross-site tracking, but the big thing with ITP 2.1, the reason why everyone is talking about it now, is the changes that are being made to first-party cookies.  Up until this point, first-party cookies have been largely left alone, which has meant measurement with a tool like Google Analytics has been untouched.  Well, that has changed.  ITP is now targeting first-party cookies that are set with client-side JavaScript.  They will have a strict 7-day life span (the Google Analytics cookie is set with a 2-year expiry normally). If the user goes back to your website within 7 days of the cookie getting set the 7-day expiry will get reset for another 7 days.  However, if the user takes longer than 7 days, their cookie is thrown out and a new one is set. This, of course, will give them a new GA user ID and, by default, GA will treat them as a new unique user to your site.

How Will ITP 2.1 Affect My Google Analytics Reports?

Now that we’ve discussed what ITP is, how it’s been working historically, and what the changes are for this latest version, let’s talk about what we expect to see in GA under these new conditions.

First off, it’s important to remember that this will only affect a portion of your visitors.  This is only an issue for Safari users. On top of that, it’s going to affect these users the most if they don’t regularly visit your site.  If you have high numbers of Safari users and you have a site where users take longer than 7 days between visits you are going to experience a greater shift in GA data than if you have low numbers of Safari users, or a site where users tend to visit regularly with less than 7 days between visits.

I’m by no means trying to suggest we shouldn’t be worried, but the amount you need to be worried is going to be dependent on these factors to begin with.

User Metrics and Attribution

The most obvious change will be a volume increase in the ‘user’ metric in GA, due to the fact that if a Safari user takes longer than 7 days to return to your site, they will be marked as a new user.  This means that user-based measurement, like transactions per user and attribution models that focus on the early customer journey (like First-Touch) , will be affected.

For example, pre-ITP 2.1, if a user first hit your website via email on Day 1, reviewed your content and left, but then returned 2 weeks later and triggered a goal completion, that preceding email session would be completely visible.  Now, due to the cookie getting reset, that example wouldn’t allow you to attribute that goal conversion to the same visitor that showed up two weeks ago or the email that brought them to the site on Day 1.

Advertising Reporting

In addition to user-related metrics and attribution beyond 7 days, we expect to be seeing changes around the Google Advertising features in GA.  Audience Interest/Demo reports, View Through reporting in CM360 and DV360 reports, CM or GDN Ad Impressions in MCF reports, Remarking, and Cross-Device reporting & remarketing inclusion will all be affected by ITP. It is difficult to predict exactly how these features will be impacted, but keep in mind that these changes will have an impact proportional to the number of Safari users they are serving ads to.

It is important to remember, however, that measurement without acquisition dimensions, such as country, session quantity over a given date range, session duration, bounce rate, etc., will not be impacted.

Hypotheses To Solve ITP 2.1 Challenges In Google Analytics

Unfortunately, there’s no simple solution to this issue.  There are a couple of tech-heavy workarounds, as well as some changes in how we view and process the data.

It should be noted that these suggested workarounds are (from the scientific perspective) hypotheses. They make sense logically, but until the official rollout of ITP 2.1 these methods are not battle-tested and you should scrutinize your digital partners if they claim these methods will be reliable. In summary, there is a big difference between a solution that is “hypothetically true” and a solution that is “battle-tested”.

User ID Hypothesis

The simplest work around is to track users via a User ID set by the website and tracked in a custom dimension.  If the user signs into your website, and you track their unique User ID, even if their tracking cookie gets reset, you can still see the activity of that user by using their unique User ID.  Any user-based report can be rebuilt using the site’s User ID rather than GA’s User ID. Since this User ID won’t get reset by ITP every 7 days, your user-based reports will be significantly more accurate.  The downside is that it will require users to log into the site in order to set and track this User ID. This is obviously not going to solve the issues of understanding user behaviour in all instances, but it can resolve some issues and unlock other reporting options like lifetime value.

If you want to proceed with the User ID option, it would be prudent to start conversations in your organization about “What incentivizes our clients to log in?” or to make the same point more abstractly, “Why should our clients agree to give us their data every time they come to our website/app?”.

Another thing to look at, especially if you have a large Safari user base, is the impact in performance in Safari and how it has changed over time relative to other browsers.

Analytics Implementation Hypothesis

The biggest issue with ITP is that it is making it increasingly more difficult to get trustworthy, user-related metrics into GA from Safari. Because of this, we need to consider some technical changes to our implementation to get around these new first-party cookie restrictions in ITP.  There is a rather complicated solution being pitched using localStorage, an iframe, and the postMessage API to get and set persistent cookie values on your site.  This could mean a bit of a restructure of your current website configuration though and that’s never fun. Also, since you’ll be using localStorage, we highly recommend you consult with your legal and privacy teams before considering this option.

Server-Side Cookie Hypothesis

Another idea is to set the cookie server-side rather than client-side.  ITP is targeting client side-cookies (set with the JavaScript document.cookie) only, so if you set the cookie using the HTTP response instead, this will bypass the ITP issues and your User ID will persist for as long as you choose to set it.  Some further work will need to happen to get this solution to work if you have any cross-domain tracking needs.

Google Cloud Hypothesis

Another option is to host the content of the GA tracking cookie in a virtual machine running in Google Cloud, with a CNAME record in your DNS to point to that virtual machine.  You would create the endpoint there and when a page loads on your site, it would call the endpoint, which in turn would grab the cookie from the HTTP headers and use Set-Cookie in the response to write the cookie to your virtual machine.  This biggest problem with this solution, currently, is the amount of overhead it will put on the web service providing the response.

Our Brave, New, Cookieless World

ITP and its disruption to the traditional use of client-side cookies in Safari is new, but it may not be unique for long.  There are already rumours that Firefox is going to implement a similar type of feature as we move into an online world that focuses more heavily on individual privacy.

As we move into this cookieless world, changes like adopting a site User ID that can persist with the user will provide the same level of measurement as just using the GA User ID (assuming all users log in of course) and looking at alternative methods to store the GA User ID, outside of the client-side cookie, are the two main focuses right now.

Ultimately, however, it’s time we start to rethink our data, and how we collect it, as this trend isn’t likely going to go away, at least not anytime soon.

What do you think about these ideas? Need help? Give us a shout. 

Pat Cooney

Manager, Service Delivery

Pat has nearly 20 years experience in web development and team management in corporate, non-profit, NGO and political sectors. Before joining Napkyn Analytics, Pat focused on helping clients improve digital experiences for customer usability and accessibility, having built more than 60 websites in his career. In his free time, Pat frequently takes the stage as accomplished bassist and sax player in Ottawa.

See more posts from Pat