As you know, Safari has introduced a set of features over the past 20 or so months, designed to provide greater privacy to its users. It does this, in part by reducing the flow from third-party tracking cookies to vendors and brands. This feature set is called Intelligent Tracking Prevention.
Third-party cookies have long been the workhorses of the partnership and affiliate industries, but over the past several years, changes in both consumer behavior and browser policies have impeded their ability to capture complete tracking data.
Intelligent Tracking Prevention from Safari was arguably the most significant hindrance to the use of third-party cookies to date. Globally, Safari has about 16% market share. But in some parts of the world, and on mobile devices, Safari has a far higher market share. Prior to ITP, the biggest impediments to cookie tracking came from far less popular browsers like Firefox.
Here’s a timeline of ITP versions and developments.
First, there was ITP 1.0, launched in September 2017, which (among other things) was developed to deprecate the ability of third-party cookies to track conversions, beginning 24 hours after their placement. Many brands lamented the change but chose to keep third-party tracking cookies either out of convenience or because tech resources in their companies were very limited. The rationale was that the majority of conversions come in the first 24 hours anyway, so while there would be some loss, it would be manageable.
Second, there was ITP 2.0, launched in September 2018, which eliminated the 24-hour window provided in ITP 1.0. With ITP2, many brands took the important step of implementing alternatives to third-party cookies. Partnerize’s recommended solution is called “server to server”, which creates a direct connection between client and Partnerize and mitigates the threats to complete data collection posed by ITP. We also offer a first-party-cookie-based tracking solution. Most of our competitors offer some sort of first-party-cookie-based solution as well.
Now, Apple has announced ITP 2.1, a revision to ITP that deprecates FIRST-PARTY client-side cookies after 7 days. This might sound daunting, but it’s important to note the following to allay initial concerns. ITP 2.1 only impacts:
- Cookies created using the document.cookie method will only be valid for 7 days (we call that a “look back window.”)
A 7-day look back window means that after a week, tracking cookies will no longer be able to collect the data we need to associate conversions to partners. For perspective, most leading partner marketing programs use a look back window longer than 7 days. The most common lengths we see are 28 days, 14 days, and 10 days. Look backs differ on a client per client and vertical basis.
WHAT SHARE OF YOUR SALES COULD BE AFFECTED
From our analysis across the vast client footprint of Partnerize, we’ve established clients on average generate 89% of conversions within the 7-day period. That means that, for the average client, ITP 2.1 would cause a drop in credited sales of 1.76%. See calculation below.
Actual results by client will vary based on their conversion patterns, location, and percent of sales that come from mobile devices.
And you don’t.
WHAT DOES PARTNERIZE RECOMMEND?
At Partnerize, we offer two robust tracking solutions that avoid the issues of ITP 1.0 and 2.0:
- Server to Server (direct interaction with client->Partnerize server)
- First party cookie based tracking solution (compatible with tag management solutions for traffic analysis / channel attribution)
For each of these tracking solutions, we have identified two approaches to mitigating ITP 2.1. While they may sound a little complicated to a generalist, they are both actually quite straightforward. Our team can help you or your dev person work through the implementation.
SET COOKIE WITH HTTP RESPONSES
As noted earlier, ITP 2.1 impacts client-side cookies created via document.cookie. Using an HTTP response header to create a cookie will mitigate this as it is actioned server-side versus client-side. The Partnerize click id (we refer to it as a “clickref”) is created and stored using the Set-Cookie HTTP response header, which bypasses ITP. Once a conversion takes place, details are retrieved and populated into the Partnerize tracking solution.
STORE CLICK ID IN LOCAL STORAGE
Today’s browsers offer two areas for data storage, one for cookies and one called “local storage”. Local storage is a place to store items that are not expected to be passed back and forth to servers constantly. Instead of writing the Partnerize “clickref” to a browser cookie, the content is stored in local storage. You can manage this with an instruction in the tag manager. At point of purchase, the contents are retrieved and returned within the Partnerize tracking solution along with all transactional information.
It really is pretty straightforward to implement. No doubt you may have more questions, so please get in touch with our support team or your Customer Success lead for more information. We can help you address this issue quickly.