The Long Term Solution to Cookie Limitations with Apple’s ITP 2.2

With each release of ITP, Apple manages to shake things up just as marketers and data analysts get comfortable. Instead of bouncing from short-term solution to short-term solution, today I’ll talk about how you can create a long-term strategy through authentication. But first, let’s take a look at where we are today in the ITP rollercoaster ride. 

Immediately after the dust settled around Intelligent Tracking Prevention (ITP) 2.1, ITP 2.2 showed up on Apple’s blog. Is there a strategy here? With ITP’s regular and consistent updates, Apple gets ongoing privacy-related press. However, in the latest iterations, Apple is not simply angling to get good press. In the ITP 2.2 update, Apple gets a branding boost while simultaneously reducing the data available to Google, Facebook, and others in the ad business. There may also be some collateral damage as well that impacts anyone using first-party cookies.

On the surface, Apple claims to protect us from those “evil” ad networks and social media sites. Apple is watching out for us when we are not smart enough to watch out for ourselves. A quote from their blog:

“Our impression is that many developers never understood it was happening; in many cases, changes to third-party JavaScript embedded on websites introduced link decoration without web developers’ knowledge.”

Apple wants us to believe that Google or Facebook (or others) did something “in secret” or behind-the-scenes here. While it may be true that the web developer building a home business has no idea what the Facebook pixel is doing, the big-spending online brands are very aware of what is happening. And they were probably somewhat happy with the Google and Facebook workarounds.

Google, Facebook, and other ad vendors implemented a solution using IDs appended to the URLs of links that go out from an ad to a website landing page. This solution referred to as “link decoration”, helped workaround previous issues with third-party cookies being blocked by Safari and other browsers.

For more information on link decoration checkout Tealium’s previous blog post here.

After these ad networks developed a sufficient workaround, Apple made the change to block this. Is someone playing games here?

Ad networks are looking to help you understand the effectiveness of your ad spends. Apple uses “social.example” in their blog that describes the benefit of this feature blocking social media sites from invading your privacy. Apple claims to be going after social sites (translation: Facebook), but as collateral damage, everyone using JavaScript and document.cookie is affected. That means your website usability features are no longer going to work.

Technically, you only need a cookie to last one day if your visitors click-through an ad and then purchase in the same visit. For most click-throughs, a one-day cookie set by JavaScript is probably fine. If you have an ad that gets a lot of clicks, but no one purchasing, you can reduce or remove your spend from that ad. However, the issue arises that now ALL your other cookies set client-side (for example, storing your visitor’s recent search filters, or nearby store zip code, or anonymous visitor id for analytics purposes) are impacted — these are now also restricted to one day duration — simply because the visitor came to your website through an ad on Facebook. 

Digital Marketers now must choose if it is more important to measure their website and ad performance or provide a quick and seamless experience for their frequent visitors.

There are still client-side workarounds not yet blocked by Safari (specifically, copy cookie information into browser local storage), but the current momentum of ITP means these workarounds are short lived.

The long-term solution is to get your visitors to authenticate on your site (possibly even using Google or Facebook for authentication). Does that mean Apple’s plans will backfire? The only way to now persist user preferences is to actually have them log in and then store their preferences server-side. The irony is that websites were previously using first-party cookies to help protect the visitor from having to give up their identity (authenticate) and still be able to store their site settings and preferences. The benefits that first-party cookies provided to anonymous visitors are now gone in Safari. In order to provide a similar benefit, authentication is now required. I expect more websites to require authentication sooner (2nd page of a website visit?) as a result.

Here’s how this plays out in practice. Let’s say I have a favorite weather site and I have 3 favorite cities. I enter in the zip codes of these cities and my browser stores them. If I come back in a week, these are still there. But my favorite cities would not be there if I used Safari and found out about the weather site from a Facebook ad. 

To Keep These “Preference” Type Settings Around, Websites Will Need To:

1. Detect the user is on Safari
2. Determine if the user came from an ad click-through
3. After a few page views, prompt the user to authenticate with Google/Facebook ID
4. Store their favorite cities in a server-side database with the Facebook ID lookup to use later
5. Retrieve their favorite cities by their Facebook ID when they return in two days

Previously, steps 1-5 above were simply one step:

1. Use document.cookie to store their last three city codes

If the use case is that the visitor will go directly to the site the second time they visit, then this restriction (I think) would not apply. That means the scenario is this:

1. User arrives from clicking on a Facebook ad or the top paid search ad in a Google search
2. They find out the weather in their two favorite cities
3. They return 2 days later directly to the site (from a bookmark)
4. The user has to re-enter their cities, but they are now saved for their 3rd and subsequent visits from their bookmark

Key Things to Remember: 

1. Copy data from cookies to LocalStorage to persist longer than the 1-day limit (NOTE: This is likely only a short term solution).
2. Use your analytics data from Chrome browser users to optimize your ad spend or website design. 
3. If you’re using Tealium Collect for data collection, ask your Account Manager how to create a CNAME (data collection alias) to store a server-side unique ID in your domain. For now, these server-side cookies are not blocked.
4. Move your website to become an “App” where authentication is normal/easy/expected with every visit. More details on Progressive Web Apps can be found here.

To learn more about ITP check out some of our recent posts on the topic here and here.  Stay tuned for more blog posts on ITP and other data privacy stories!