The latest version of Safari limits the ability for Google Analytics (and any other marketing tags) to track users across domains, and between visits more than a day apart. Here’s how to get this fixed for your site.
This article was updated 12th June 2019 to clarify changes for ITP 2.2.
How does this affect my analytics?
Safari’s Intelligent Tracking Prevention (ITP) dramatically changes how you can attribute marketing on one of the web’s most popular browsers, and ITP 2.1 makes this even more difficult.
How will the changes affect your analytics?
Currently your marketing attribution in Google Analytics (GA) relies on tracking users across different visits on the same browser with a first-party user cookie – set on your domain by the GA tracking code. GA assigns every visitor an anonymous ‘client ID’ so that the user browsing your website on Saturday can be linked to the same browser that comes back on Monday to purchase.
In theory this user-tracking cookie can last up to 2 years from the date of the first visit (in practice, many users clear their cookies more frequently than that), but anything more than one month is good enough for most marketing attribution.
ITP breaks that user tracking in two major ways:
- Any cookie set by the browser, will be deleted after 7 days (ITP 2.1)
- Any cookie set by the browser, after the user has come from a cross-domain link, will be deleted after one day (ITP 2.2)
This will disrupt your marketing attribution. Let’s take two examples.
Visitor A comes from an affiliate on Saturday, and then comes back the next Saturday to purchase:
- Before ITP: sale is attributed to Affiliate
- After ITP: sale is attributed to ‘Direct’
- Why: 2nd visit is more than one day after the 1st
Visitor B comes from a Facebook Ad to your latest blog post on myblog.com, and goes on to purchase:
- Before ITP: sale is attribute to Facebook
- After ITP: sale is attributed to ‘Direct’
- Why: the visit to the blog is not linked to the visit on another domain
The overall effect will be an apparent increase in users and sessions from Safari, as the same number of user journeys are broken in down into more, shorter journeys.
How big is the problem?
This is a big problem! Depending on your traffic sources it is likely to affect between a quarter and a half of all your visits.
The update (ITP 2.1) is included in Safari version 12.1 onwards for Mac OS and Safari Mobile. It does not affect Safari in-app browsing.
Apple released iOS 12.2 and Mac OS 10.14.4 on 25th March 2019, and at the time of writing around 30% of all web visits came from these two browser versions on a sample of larger sites.
The volume for your site may vary; you can apply this Google Analytics segment to see exactly how. The affected traffic will be greater if you have high mobile use or more usage in the US (where iPhones are more popular).
Why is Apple making these changes?
Apple has made a strong point of user privacy over the last few years. Their billboard ad at the CES conference in Las Vegas earlier this year makes that point clearly!
Although Google Chrome has overtaken Safari, Internet Explorer and Firefox in popularity on the desktop, Safari maintains a very dominant position in mobile browsing due to the ubiquitous iPhone.
Apple develops Safari to provide a secure web interface for their users, and with Intelligent Tracking Prevention (ITP) they intended to reduce creepy retargeting ads following you around the web. Genuine web analytics has just been caught in the cross-fire.
Unfortunately this is likely not to be the last attack on web analytics, and a permanent solution may not be around for some time.
Our belief is that users expect companies to track them across their own branded websites and so the workarounds below are ethical and not violating the user privacy that Apple is trying to protect.
How to fix this
There are three outline fixes I would recommend. I’m grateful to Simo Ahava for his research on all the possible solutions.
The right solution for your site depends on your server setup and the development resources you have available. If you’re lucky enough to use our Shopify app the next version of our script will include solution 1 below. Contact our support team if you’d like to test the private beta version.
For each solution, I’ve rated them out of three in these areas:
- Quick setup: how much development time it will take to solve
- Compatibility: how likely this is to work with different domain setups
- Longevity: how likely this is to work for future updates to Safari ITP
Solution 1: Local storage
Quick setup *** Compatibility ** Longevity*
To solve the one day cookie expiry, you store the GA client ID in the browser’s local storage (which does not expire), along with the cookie. So before we allow GA to set a new client ID we first check if the Safari browser has a local storage.
Here are the full technical details.
Solution 2: Common iFrame plus local storage
Quick setup ** Compatibility*** Longevity *
The problem with solution 1 is that local storage is only available to an individual subdomain. Let’s imagine a user journey that goes:
- Day 1: Visits blog.mysite.com
- Day 8: Visits shop.mysite.com
In this case, the two visits cannot be linked because after 7 days the cookie has expired, and shop.mysite.com cannot access local storage on blog.mysite.com.
Solution 2 fixes this by setting up a page on the top level domain (e.g. www.mysite.com/tracker.html) on which that local storage is set, and the page can be accessed from any subdomain.
What makes it longer to setup is it will require a new page on your web server, not just script changes on the existing pages (or via GTM).
Solution 3: Server-side cookie service
Quick setup * Compatibility *** Longevity ***
In the long term, ITP may target the local storage API itself (which is already blocked in Private browsing mode). So solution 3 securely sets the HTTPS cookie from your web server itself, rather than via a browser script.
This also has the advantage of making sure any cross-domain links tracked using GA’s linker plugin can last more than one day after the click-through with ITP 2.2.
The downside is this requires either adapting your servers, proxy servers or CDN to serve a cookie for GA and adapt the GA client-side libraries to work on a web server.
If your company uses Node.js servers or a CDN like Amazon CloudFront or Cloudflare this may be significantly easier to achieve. If you don’t have direct control of your server infrastructure it’s a non-starter.
What about other marketing tags working on Safari?
All other marketing tags which track users across more than one session or one subdomain are going to experience the same problem.
With Google Ads the best solution is to link your Ad account to Google Analytics, since this enables Google to use the GA cookie to better attribute conversion in Google Ads reporting.
Facebook will no doubt provide a solution of their own, but in the meantime you can also attribute Facebook spend in GA using Littledata’s connection for Facebook Ads.
Are there any downsides of making these changes?
As with any technical solution, there are upsides and downsides. The main downside here is again with user privacy.
Legally, you might start over-tracking users. By resetting cookies from the local storage that the user previously requested to be deleted, this could be violating a user’s right to be forgotten under GDPR. The problem with ITP is it is actually overriding the user’s preference to keep the cookie in usual circumstances, so there is no way of knowing the cookie was deleted by the user … or by Safari supposed looking out for the user!
Unfortunately as with any customisation to the tracking code it brings more complexity to maintain, but I feel this is well worth the effort to maintain marketing attribution on one of the world’s most popular browsers.