Key points:
- Safari browsers will set most analytics cookies to a 7 day expiry
- Visitors with >7 days in between visits will be seen as new visitors
- Attribution of traffic sources will be reset unless the visitor comes to your site every week until conversion
- Snowplow users can overcome this if their site domain matches their collector domain
Apple has dropped another big change into the browser market with their latest Intelligent Tracking Protection 2.1 blog post. Apple started working on ITP in 2017 to protect user privacy which triggered an arms race with ad tech and social media developing workarounds to continue tracking users.
Each ITP change has taken away some of the tools used for pervasive tracking across large swathes of the Internet and has restricted tracking that was clearly not in users’ interest.
Thus far most of the changes have had limited impact on digital analytics platforms because you could still track individual browsers over time within a single domain. This was good enough for most companies. When Apple first started blocking third-party cookies, companies with sites over different domains lost the ability to get a deduplicated network view, that is a reasonably reliable way of knowing the number of unique browsers across all their sites.
This latest change is the first to have a direct impact on digital analytics platforms. This change is going to be felt by users of Google, Adobe and Snowplow Analytics and pretty much all analytics vendors.
In Australia, Safari makes up at least a third of browsers, probably a little more depending on your sites’ target market. An important economic aspect of this is that iOS users trend towards the higher socio-economic portion of Australians. Makes sense really: only relatively wealthy people can afford to drop over a grand on a phone or incur the monthly fees to get one “free” on a plan. So Safari is important.
What’s the change
This change, expected to roll out through March 2019, changes the way Safari treats first-party cookies. First-party cookies are used by analytics tools to track a user across multiple sessions. The first-party refers to the fact that the cookie is set in the same domain as the web page.
For example a first-party cookie set on this page is defined for poplindata.com and will only be available in future for web pages on that domain. A third-party cookie is for a completely different domain and is already blocked in Safari by earlier iterations of ITP.
Client-side JavaScript cookies
You can create a first-party cookie using JavaScript inside the browser. The change means that these cookies will expire after seven days.
That’s a big change for digital analytics! Typically these tools set a two year expiry cookie in JavaScript to identify a user over multiple visits. You can use the cookie identifier to stitch together all the behaviour of a single browser across multiple sessions, for example the user arriving from a search ad and reading some content then coming back another time and making a purchase.
Server-side cookies
The other way to set cookies is as an HTTP header response to a request. This was typically how third-party cookies were set before ITP made them less useful:
- Adobe Analytics uses this technique to track users across a network of sites, though this hasn’t worked in Safari browsers for a fair while.
- Snowplow Insights also sets a cookie from the collector designed to be used for similar purposes and shows up in the network_userid column out the other end.
- Google Analytics doesn’t set any server-side cookies that you can use.
The new ITP rule is that a first-party cookie set using an HTTP header response will persist for the expiry time specified in the HTTP response as usual, in contrast to how client-side JavaScript cookies are treated. So server response cookies aren’t limited by ITP but client-side ones are.
What’s the solution?
For digital analytics tools that set a cookie in the HTTP response, such as Adobe Analytics and Snowplow Insights, you might be okay.
If your site and the data collection endpoint for your analytics platform are in the same domain, you should be fine. The cookie set in the HTTP response will have a long lifetime and continue to be sent as normal.
So for example on this site which is poplindata.com, our data collection happens on d.poplindata.com and should set a first-party cookie that will be honoured by Safari. However we also collect data on contractorpermie.com where the d.poplindata.com cookie will be rejected by Safari as a third-party cookie. The first-party cookie set by the Snowplow library will expire in Safari browsers after seven days.
So if you’re setting a cookie for the same domain as your site via an HTTP response from your data collection server, the cookie will be accepted. So if your data collection domain is the same as your site domain, you’ll be okay.
Snowplow users
In Snowplow data the client-side cookie is recorded as domain_userid and the server-side cookie is stored in network_userid. When this change becomes active you’ll want to start using the network_userid for Safari users, but only for sites that are within the same domain as your data collector.
Other reading
- Simo has written in great detail about this and has some workarounds for Google Analytics
