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:
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?
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 to Apple's ITP is to get your visitors to authenticate on your site (possibly even using Google or Facebook for authentication). Click To Tweet
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:
- Detect the user is on Safari
- Determine if the user came from an ad click-through
- After a few page views, prompt the user to authenticate with Google/Facebook ID
- Store their favorite cities in a server-side database with the Facebook ID lookup to use later
- Retrieve their favorite cities by their Facebook ID when they return in two days
Previously, steps 1-5 above were simply one step:
- 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:
- User arrives from clicking on a Facebook ad or the top paid search ad in a Google search
- They find out the weather in their two favorite cities
- They return 2 days later directly to the site (from a bookmark)
- 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:
- Copy data from cookies to LocalStorage to persist longer than the 1-day limit (NOTE: This is likely only a short term solution).
- Use your analytics data from Chrome browser users to optimize your ad spend or website design.
- 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.
- 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.