Understanding & Reacting to Apple’s Safari Browser Tracking Changes

By Dennis Buchheim

With its most recent Safari browser release for iOS and MacOS, Apple introduced “Intelligent Tracking Prevention”, which immediately and significantly reduces the value of ad impression opportunities in Safari mobile/desktop browser and in-app webview environments. Safari will now block sending cookies to third parties determined to be “trackers”. This will be highly disruptive to buyers, sellers, and technology platforms, given the role third-party cookies play in audience addressability, segmentation (and thus targeting and personalization), and measurement. It will also negatively impact consumers, as ads will be less relevant and publishers may struggle to provide content and services. To help minimize this disruption, IAB Tech Lab and its Identity Standards Working Group developed the following short-term mitigation options for the industry to consider, along with thoughts on longer-term mitigation.

To start, we should level-set on how cookies have been used in the digital advertising ecosystem. First, there are three types of relationships between entities that store cookie-based user information (the data collector) and the web user: first-party, second-party, and third-party (see IAB’s Data Techniques and Lexicon Primer for details). Second, an individual website or other entity can only read and understand cookies set by its own domain. So, for a publisher or ad platform to capture and associate user information across other websites that a consumer might visit (for addressability/segmentation/measurement and to support consumers’ advertising opt-out preferences), those publishers and technology partners have to maintain integrations to map cookies via large matching tables. Although this has always been a lossy process, these integrations have sufficiently enabled first-party cookies (set by abcd.com) to be read in third-party contexts (when the abcd.com user visits 1234.org).

So, what changed? The “Intelligent Tracking Prevention” feature described by Apple aims to close the possibility of a first-party event to establish a long-lasting cookie that can be read in a third-party context. First, Safari will determine algorithmically whether a domain has the ability to track a user across sites. Second, when a domain is flagged as being able to track a user across sites, two new rules are applied to cookies from that domain:

Twenty-four hours after the most recent first-party interaction with the domain, the cookie payload for that domain becomes unavailable in a third-party context.
Thirty days after the most recent first-party interaction with the domain, the cookie payload for that domain is purged. Days are only counted while Safari runs.

While full details have not been provided, the expectation is that first parties will have read/write cookie permissions, third parties will have read-only cookie permissions, and third parties that are algorithmically determined to be “trackers” will have limited read access for only 24 hours after a first-party interaction. (The window between 24 hours and 30 days may be intended to reduce the impact on single-sign-on systems and other user interactions.)

SHORT-TERM MITIGATION PROBLEMS

We have identified some approaches that should be explored – by buyers, publishers, and platforms – as short-term solutions to mitigate impact on reach, targeting, and measurement within browser-based and in-app webview Safari environments. These solutions are based on the assumptions that (1) we need to account for interoperable measurement and activation of data assets across channels and formats and (2) user-level path-to-conversion tracking remains central to effective attribution and campaign optimization. For these reasons, short-term mitigation will likely have to involve establishing a first-party asset and continually refreshing that first-party asset (as opposed to current reliance on third-party syncing). Additional assessment information on each option can be found here.

Because syncing relationships will need to change, techniques going forward will likely be based on: (1) a short-interval sync leveraging first-party assets available within 24 hours; (2) a passively executed sync using HTTP header fields, on-page script, or other probabilistic approaches to develop IDs for devices; or (3) an actively requested sync through user-provided data such as email address or via an explicit authentication. While data syncing will likely need to persist in some form, it’s unclear how effective it will be relative to current third-party syncing methods.

Note that the value and longevity of specific ID syncing and management solutions and offerings is not considered here, but needs to be evaluated based on individual constituents’ needs and scale, and weighed against impact on user experience and audience fragmentation. Additionally, competing commercial interests and adherence to emerging standards (IAB Tech Lab and its members are working on the latter) should be considered.

BUYERS

Develop first-party data strategy by leveraging first-party cookies in combination with ID matching to protect and activate data assets.
Apply non-cookie based technologies for user identification and impression valuation – probabilistic, network/carrier-based, and statistical approaches are most common.
Focus reach and targeting efforts in Safari environments on companies that have strong first-party relationships with consumers, leverage those relationships for custom targeting and measurement solutions within confines of their owned-and-operated (O&O) properties.

PUBLISHERS

Re-prioritize contextual signals to value and price impression opportunities for buyers.
Develop first-party data strategy by collecting and activating first-party cookies to enrich inventory value in open exchange and private marketplace (PMP) contexts.

DSPs

Demand-Side Platforms (DSPs) see the vast majority of their traffic through the bid stream, which means their technical options are minimal with regard to how they can navigate new Safari environments. However, they do generally have page-level access to their advertiser customers’ sites, and so they see at least some direct web traffic. Short-term mitigation options could include:

Develop first-party data strategy by establishing an ID syncing vendor to activate assets under an ID other than the DSP’s own third-party domain.
Leverage publisher-side files. These are often used for rich media or iFrame breakout but could be repurposed for probabilistic ID matching.
Leverage non-cookie-based information, including statistical identifiers, to value impression opportunities.

DMP – DEMAND SIDE

Data Management Platforms (DMPs) don’t have as much room to maneuver technically, but what room they do have is determined by the amount of data they directly source online and how they onboard offline data against third-party cookies. For the most part, these vendors can consolidate their online presence against IDs that will be unaffected by Safari changes and then move to one or more common IDs used by their DSP partners (see DSP guidance).

DMP – PUBLISHER SIDE

Publisher side DMPs sit one-step removed from the publisher and so are often able to deploy JavaScript to the parent page on their publisher customers’ sites. This is a key advantage that publisher-facing DMPs have over buy-side DMPs and the buy-side in general. So, short-term mitigation options include:

Leverage both owned first-party cookies and publisher first-party cookies for data storage.
Utilize own ID matching service or contract out to identity vendor to map first-party cookie data assets.
Leverage an identity vendor’s common ID for the sale of publisher-sourced data directly to buyers outside of the bid-stream.

SSP / AD EXCHANGES

Given the costs and inefficiencies associated with their current role as facilitators of cookie syncing for DSPs, Supply-Side Platforms (SSPs) / Ad Exchanges arguably have the most structural leverage to address Safari-related changes to identity activation. Many mitigation options reflect a mounting buy-side imperative to change the underlying exchange mechanisms for activating identity and audience data in Real-Time Bidding (RTB) environments, and simultaneously highlight the cost-savings rationale for exchanges to restructure their operating models:

Consolidate Exchange ID into federated first-party cookies to help preserve existing data assets against their own IDs.
Utilize identity vendor to ID-match first-party cookies and provide that vendor’s ID in the User Object of the Bid-Stream (as an extension, as the Exchange ID, or as the Buyer UID for buyers also using that vendor’s ID).
Utilize more than one identity vendor to ensure wide coverage of DSP partners’ chosen identity vendors.
Outside of ID and audience syncing, explore options with publisher partners to communicate audience characteristics to buyers in a structured way. Examine common audience taxonomies, content adjacency inference, applicability of survey data, use of CRM data, etc.
Explore “link decoration” (or URI-Query) options as a way of communicating information necessary to achieving the above scenarios.

LONG-TERM MITIGATION

In a fluid marketplace and unpredictable regulatory environment, the following may be the most viable long-term options to mitigate the impact of Safari changes and other impending changes while maintaining valuable data-driven marketing strategies — though both could be challenging to execute given competing commercial interests:

Develop a common, consolidated ID routed through a single domain. This could be accomplished via a redirect, a platform approach aimed at establishing a sign-on experience across many logged-in users across domains, or it could be client-mediated/browser-based. This approach could allow sufficient refresh frequency within the 24-hour cookie window for first-party cookies to remain somewhat persistent, reduce fragmentation, reduce the need for resource-intensive ID syncing services that would likely enter the fray during short-term mitigation, and better position the industry to navigate GDPR (European General Data Protection Regulation) compliance and consumer opt-out controls via deterministic cross-device matching.
Work with browsers on standards for ID similar to advertising IDs (IDFA/AAID) on mobile devices that could be used in place of cookies to identify a consumer endpoint and to replace cookies to mark the user. Browsers would also need to provide interfaces for resetting IDs. This would provide better control in the hands of users to manage their privacy while supporting the advertising ecosystem and solution providers, including support for opt-in and opt-out by users for specific service providers.

IMMEDIATE NEXT STEPS

In addition to considering the summarized short-term options, we urge industry participants to collaborate with partners/vendors to develop new, sustainable, consumer-friendly approaches to identity resolution and management. We also ask interested parties to work with IAB Tech Lab to (1) define and evolve identity standards for the industry as a whole and (2) engage with key players in the ecosystem on effective long-term strategies.