It’s time to upgrade your tracking to ensure accurate, persistent performance tracking with Partnerize. Be better prepared for a cookie-less future by visiting here!

What You Need To Know About Safari ITP 2.2 and Upcoming Chrome Changes

Jun 03, 2019

Head of Deployment

At Partnerize, we know it’s important to keep our clients and the industry updated on changing browser policies and how they might impact partnership tracking. This blog post is designed to update you on:

  • Safari ITP 2.2
  • Announced Changes to Chrome Tracking Policies

In both cases, we will carefully explain the changes, and then outline all we know about how these changes will affect tracking for our clients. By way of background, most of our clients have moved on from third-party pixel tracking to either our server-to-server (S2S) or first-party cookie tracking solutions. Because of this, we’ll focus our commentary on those use cases.

SAFARI ITP 2.2

Let’s start with Safari. The Safari team has just announced an update to Intelligent Tracking Prevention. The newest version is called ITP 2.2.

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 clients 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.
  • Then, the Safari team announced ITP 2.1, a revision to ITP that deprecates FIRST-PARTY client-side cookies after 7 days.
  • Now, Safari has announced ITP 2.2, which deprecates FIRST-PARTY client-side cookies after just 24 hours.

Like its predecessor, ITP 2.2 only impacts persistent cookies created via the Javascript library document.cookie that meet the criteria as outlined by Safari :

  1. A domain classified with cross-site tracking capabilities was responsible for navigating the user to the current webpage.
  2. The final URL of the navigation mentioned above has a query string and/or a fragment identifier.

For both S2S and first-party cookie-based Partnerize implementations, we have identified two approaches to mitigating ITP 2.2. While they may sound a little complicated at first, they are both actually quite straightforward. Our team can help you or your dev person work through the implementation.

SET COOKIE WITH HTTP RESPONSES

ITP 2.1 and 2.2 apply to client-side cookies created via document.cookie. Using an HTTP response header to create a cookie will mitigate this as it is actioned on the server-side versus the client-side. The Partnerize click id (we refer to it as a  “clickref”) is created and stored using the Set-Cookie HTTP response header by the advertiser, 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

Once again, this is not as complicated to implement as it may sound. If you have questions, please get in touch with our support team or your Customer Success lead for more information. We can help you address this issue quickly.

ANNOUNCED CHANGES TO CHROME TRACKING POLICIES

At the Google Developers Conference this month, the company announced some changes to the upcoming Chrome browser editions that relate to cookies and user tracking. The company did not announce specific dates for these changes, but they are worth reviewing just the same.

By way of background, Chrome has approximately 63% market share globally. Its closest rival is Safari, with about 16%. In the US, Chrome’s share is about 50%.

ANNOUNCED CROSS-SITE COOKIE CHANGES

When the Chrome team announced these upcoming policy changes, they said it was to enable “transparency, choice and control when it comes to data privacy on the web.” The idea was that it would be valuable to give consumers the choice of limiting tracking cookies while still allowing cookies that improve user experience in ways like enabling automatic login or customized user experiences.

The Chrome team pointed out that currently it’s difficult to distinguish between a single site cookie (e.g., one automatically logs a user in) versus a multi-site cookie (e.g., a tracker.)

In order to enable people to control tracking while retaining single site logins and settings, Chrome will require that companies identify their cross-site cookies so that they can easily be differentiated from single site cookies. To do this, developers will be required to use something called the SameSite cookie attribute and identify their cookies as either single-site or cross-site cookies. Once cookies are identified, the user will have the option to turn off cross-site cookies while allowing single site cookies.

With the SameSite attribute, a cookie can have the following values  ”Lax” , “Strict” or “None”. Lax indicates that the cookie can be sent along with cross-site data — because it is a cross-site cookie. Strict indicates that the cookie cannot be sent along with cross-site data — because it is a single site cookie. Where developers do not set the attribute, Chrome will assume that the cookie is cross-site, and categorize it accordingly. By reading the SameSite cookie attribute, Chrome will be able to distinguish between single-site and cross-site cookies, and thereby enable users to turn off some cookie types.

The team also said that there will be a new browser extension available to let users know more about the companies that are placing cookies, and the reasons for those placements.

From Tech Crunch:

In a related announcement, the Google Ads team today said that it is “committing to a new level of ads transparency.” The first step in actually providing users with better insights into how ads are personalized for them, Google will launch a browser extension that will disclose the names of the companies that were involved into getting these ads in front of you (including ad tech companies, advertisers, ad trackers and publishers) and the factors that were used to tailor the ad to the user.

This extension is going live in the coming months and will work for all of Google’s own properties and those of its publishing partners. The company is also making an API available to other advertising companies that want to feed the same information into the browser extension.

We believe Chrome is unlikely to default block cross-site first-party cookies — as Safari did with some types of cookies and data. Rather, we expect that they will give the end user the choice to block cross-site cookies if they so choose. The option to opt-out of tracking has traditionally been Chrome’s approach.

From the Chromium blog:

This change will enable users to clear all such cookies while leaving single domain cookies unaffected, preserving user logins and settings. It will also enable browsers to provide clear information about which sites are setting these cookies, so users can make informed choices about how their data is used.

CHANGES TO FINGERPRINTING

Many partner marketing programs use fingerprinting as a fallback means of identifying users impacted by partner marketing, when cookie-based matching fails. With fingerprinting, other means of identifying people who have clicked on partner messages are deployed in an effort to ensure that partners are correctly compensated for their efforts.

For example, fingerprinting often uses IP address as one of the approaches by which it identifies a clicker at the moment of conversion. If someone uses the same IP address, and has other characteristics in common with the conditions at click, the user is identified as a probable match.

Partnerize clients have the option of using fingerprinting or foregoing its use. The vast majority believe that fingerprinting offers an important supplement to ensure that partners are adequately compensated.

The Chrome team says that it will implement measures to reduce the effectiveness of some forms of fingerprinting – that they intend to apply some restrictions to the data that can be passed to the client or solution provider. Which data will be affected are not yet announced.

CHANGES  TO PRIVACY CHOICE

According to the announcement, future editions of Chrome will make it easier for users to turn different types of cookies off and on. By enabling people to block cross-site cookies but not single site cookies, the user will be able to benefit from on-site experiences, like automatic site logins, without permitting some forms of user tracking. Dates are as yet unspecified. They will preview the changes later this year.

IMPLICATIONS FOR PARTNER MARKETERS

Requiring developers to set a SameSite status will not, by itself, have an immediate effect on data you receive from Partnerize. Further, it is easy to set a SameSite status with either Partnerize’s S2S or first-party cookie-based solution.

Whether there will be long-term impact will depend on if large numbers of Chrome users suddenly decide to block cross-site tracking cookies. The Chrome team has promised to make it easier to block such cookies, but the details of how they will offer that easier solution and whether users will avail themselves of that opportunity is unknown.

From the Chromium blog:

We announced at I/O that we will be updating Chrome to provide users with more transparency about how sites are using cookies, as well as simpler controls for cross-site cookies. We will preview these new features later this year.

Fortunately, the Chrome team tends to make changes of this import at a considered pace, which enables advertisers to prepare. Similarly, it is possible that future changes to fingerprinting rules will have a material impact for customers, but Chrome has not outlined what sorts of information they will limit,  and when.

From the Chromium blog

This is why Chrome plans to more aggressively restrict fingerprinting across the web. One way in which we’ll be doing this is reducing the ways in which browsers can be passively fingerprinted, so that we can detect and intervene against active fingerprinting efforts as they happen.

Until they do, and then until they implement any changes that they announce, we don’t expect an impact on conversions.

An important thing to remember here is that Chrome has always acted in ways that are aligned with a free and open, ad-supported web. Therefore, we expect that they will provide significant lead time and guidance on how to prepare. We recognize that you will need greater clarity on possible impacts, and will provide it as soon as more details are announced.

Subscribe to our content