This is the subhead for the blog post

In yesterday’s post, we detailed ITP 2.1 – the context, the new restrictions, and the practical effects of them. ITP 2.1 has left marketers, and web developers generally, with several options, none of which completely obviate its effects. Which solutions you implement will depend on what you’re trying to do. In this post, we’ll break down your options – and the caveats that come with each.

Storage Access API

WebKit’s own solution for browser storage can handle many of the functions assigned to traditional cookies. If you’re running a federated login system, or embedding content that relies on persistent user preferences, the Storage Access API provides a workable solution.

Storage Access’ downsides derive from the difficulty of its implementation. As opposed to traditional cookies, Storage Access requires a good deal of development work (with which 3Q is ready to assist) to implement correctly. For a good tutorial about how to use Storage Access, check out WebKit’s own documentation.

Storage Access also explicitly prompts the user for permission whenever a third-party is trying to access its cookies for the first time. Needless to say, this interrupts the user experience flow and creates a strong likelihood that the user will deny cookie access to your app. You can engineer your app to make its essential functions dependent on third-party cookie access, thereby compelling the user to grant permission, but by doing so you further increase the risk that users will simply tune out.

Storage Access, per its stated goals, does not provide a workable solution for cross-site tracking.

The localStorage workaround

Cookies are not the only option browsers provide for persistent storage. Developers can also employ localStorage and sessionStorage to save values across user navigations. These APIs work a bit differently from cookies. Their data limits are much larger (10 megabytes per domain in localStorage’s case) and are used primarily for storing sizable resources such as images and stylesheets in order to decrease website load times. LocalStorage can be manipulated to provide a “kitchen sink” workaround for browsers that restrict cookie access.

WebKit has as of yet placed few restrictions on localStorage, so you can persist values in this “bucket” indefinitely. This can help with determining repeat rates, linking conversions across time frames of longer than seven days, and keeping track of new vs. repeat site visitors.

Using localStorage to persist cookie data will require some development work. The technique will differ depending on the type of cookie you’re trying to preserve, but any setup will have to include:

  1. Using a piece of Javascript to identify the cookie you want to preserve as it’s being set, then copying that value to localStorage;
  2. Using a second piece of Javascript that reads the correct cookie value from localStorage when needed and overwrites the incorrect cookie value being set by a marketing script

As you may have intuited, using localStorage requires a good deal of dev work. It also comes with a variety of caveats

  • No cross-subdomain tracking. Say you own and you push users onto a subdomain in order for them to complete their purchases. Localstorage treats and as completely different websites, meaning the values set on will be inaccessible once the user navigates to
  • No support for multiple user identifiers. If you’re tracking user interactions on your site via multiple Google Analytics accounts, or if you want to analyze two different journeys for the same user by employing different click IDs, the localStorage solution won’t be able to help you. This solution overwrites user identifiers, allowing for only one identifier per user, per domain.
  • User transparency. Not only is having a transparent cookie policy a matter of good form, in large swathes of the world it has become a legal necessity. Users have come to expect that clearing (or blocking) cookies protects them from most forms of tracking. Using localStorage as a workaround behooves you to state that you’re doing so and to give your reasons.

For a fantastic guide about how to implement this solution, check out this blog post from Simo Ahava.

Server-side solutions

Developers have proposed a number of solutions for cookie storage that involve server-side programming. These include setting cookie headers in server-side scripts, employing edge caches, and reverse-proxying your server with a third-party service. If you’re interested in these solutions, you can check them out here, but we’re not going to go into these in depth for a couple of reasons:

Complexity and access. As you may have intuited, server-side solutions are resource-intensive. Not only do they require extensive dev work, but several also require the purchase of new server technologies. Needless to say, they require access to a website’s complete back- and front-end code base as well. Employing one of these solutions is going to be a major effort that may require a fundamental redesign of your web application.

Lack of insight into cross-site browsing. Regardless what you do server-side, user identification will have to involve some sort of info from the front end. Only on the front end can you tell if someone visiting site A is the same person who visited site B earlier in the week. Many of the server-side solutions simply offer a variation on the localStorage solution described above — where cookie values are stored in a different persistent context — but use more resources in order to achieve that same effect.

Neither localStorage nor the Storage Access API will provide complete transparency into user activity on Safari, nor are they the slightest bit future-proof. As our brief history of ITP demonstrated, WebKit is moving rapidly to close loopholes in its anti-tracking tools. The solutions we’ve just discussed will work for the moment, but going forward it will be imperative to have someone on your team, or an agency partner, who keeps abreast of current trends in analytics and can respond as new challenges emerge.