Understanding & Reacting to Apple’s Safari Browser Tracking Changes

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:

1. 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.
2. 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.)

 

IMPLICATIONS:

The move by Apple eliminates a major method of establishing a consistent, cookie-based identity for use by third-party advertising systems and ultimately depreciates the value of cookies in match tables. Broader implications could include:

1. Publishers that have both (a) frequent first-party engagements with users and (b) their own advertising ecosystems are poised to be less affected than average publishers. While any off-property (“network”) business will be affected by the new tracking limitations, these revenue streams tend to be peripheral relative to ad revenue from these large publishers’ own direct ecosystems, and thus the impact will be smaller. This change may allow companies with strong first-party relationships to become even more powerful relative to their competition that are more reliant on third-party tracking.
2. Efforts by the industry to create a standard ID may be further challenged, at least to the extent that such ID is cookie-based.
3. Industry opt-out may be further challenged.
4. There is minimal impact on short-term conversion tracking (cookie remains available for 24 hours after it’s been set during click), web analytics (these systems generally depend on first-party cookies set by JavaScript), and other local or short-term analytics processes.

 

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).

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

1. Develop first-party data strategy by leveraging first-party cookies in combination with ID matching to protect and activate data assets.
   • Because advertisers’ data assets are deprecated by the blocking of third-party cookies (third parties tend to warehouse both custom and syndicated data), advertisers can drop first-party cookies from their own sites, warehouse this in a first-party location, and onboard as much data as possible from external sources to enrich it. These first-party cookies will still have a shortened lifespan, but a longer one than third-party cookies in a Safari environment. This will allow advertisers to continue measuring their conversion funnel over a 30-day lifespan for each given user.
   • ID matching services are necessary for advertisers to track conversions to ads delivered on a publisher’s page (matching the advertiser’s ID from the conversion event to the ID the publisher had on the user for the pageview). They will also be necessary to onboard their data assets to an ID that they can be read and activated against in programmatic bid streams.
2. Apply non-cookie-based technologies for user identification and impression valuation.
   • Probabilistic and statistical approaches are the most common, but buyers need to weigh the costs and benefits of these solutions to reduce the possibility for false positives during matching and activation. In order to do so, buyers need to develop and enforce strict standards in partner accuracy, activation potential, and coverage.
   • Networks and carrier-based approaches can be explored for the purposes of targeting and measurement on devices that have carrier connectivity. Buyers can request carrier IDs from carriers to handle decisioning in house, or buyers can purchase pre-populated segments defined by the network for use across exchange or network ecosystems.
3. Focus reach and targeting efforts in Safari environments on companies that have consistent first-party relationships with consumers, leverage that relationship for custom targeting and measurement solutions within confines of their owned-and-operated (O&O) properties.

PUBLISHERS

1. Re-prioritize contextual signals to value impression opportunities.
2. Develop first-party data strategy by collecting and activating first-party cookies to enrich inventory value in open exchange and private marketplace (PMP) contexts. This would broadly require three steps:
   1. Publishers need to build data assets against first-party cookies and store them in a way that retains first-party relationships with users (warehousing could be done via white labelled DMP, or a bespoke/custom DMP). A publisher would need to rely on its core audience to visit the domain regularly, meaning behavioral data and potentially offline data sets with login information could be quickly logged against these IDs.
   2. Publisher develops integration with SSP and/or exchange partners to request that they are given ability to pass this data into the OpenRTB data object. Because publishers have the first call opportunity to any browser visiting their site – before their Exchange, SSP, and DMP partner’s tags load – the publisher can load resources and affect the bid stream to enrich impression value.
   3. Publisher agrees to consistently use the same ID matching service as buyer and DMP partners. This allows buyers to decision on publisher first-party data (first-party cookie data assets used outside the single domain) by mapping that data to the identity vendor’s user ID for un-fragmented activation. Note that not all identity vendors develop their own ID, which should factor into partner selection in this scenario.
      1. While this approach requires publishers to build data assets for monetization first against the identity vendor’s ID, a publisher can simultaneously maintain a secondary profile building against their own first party cookies for security. This will allow them to more directly monetize data vs ad sales: collecting and selling segments against the common ID vendor currency, and selling inventory to the buyer of the vendor’s ID segment.

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:

1. Develop first-party data strategy by establishing an ID syncing vendor to activate assets under an ID other than the DSPs own third-party domain. Even before the supply side adopts an identity vendor, DSPs can use the ID matching service to warehouse data in preparation for iOS 11 removing their current cookie pool from effective coverage. By associating their existing IDs to an identity vendor’s IDs, the disappearance of the DSP’s IDs will not mean the loss of all data assets.
   • Pursue sell-side partners to pass chosen identity vendor’s ID as buyerUID parameter. The DSP can either replace its third-party cookie with its identity vendor’s IDs in syncs or have the SSP/Exchange integrate a third-party common ID with its tag and directly pass that ID into the bid stream.
2. Leverage publisher-side files. These are often used for rich media or iFrame breakout but could be repurposed for probabilistic ID matching.
3. 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 often are able to deploy JavaScript to the parent page on their publisher partners’ sites. This is a key advantage that publisher-facing DMPs have over buy-side DMPs and the buy-side in general – direct access to the parent page gives them the ability to adjust technically more efficiently to Safari changes than platforms without that direct and reliable page access.

1. Leverage both owned first-party cookies and publisher first-party cookies for data storage.
   • Any JavaScript tag can drop a first-party cookie associated with the domain it is dropped from. DMPs should drop first-party cookies immediately and begin storing segment data against these cookies collected from each site their JavaScript is deployed on.
   • These first-party cookies will have a long lifespan but smaller coverage than third-party cookies, and for the short time remaining where the DMP can redirect and gain some third-party coverage in Safari, they should – and they should store the third-party data assets against each first-party cookie they are dropping on each site, so that as those redirect cookies are dropped, the first-party cookies act as a temporary store for at least a portion of that data.
   • Pub-side DMPs can also release products to help publishers manage data assets against their own cookie pools in addition to the DMP managing data assets against their own “first-party cookies”. The DMP may have data enhancements that the publisher does not have which can help ensure less duplication in the data object (the publisher passes some segments, the DMP enhances) and the DMP may also have relationships with more buyers than the publisher, enabling the use of that publisher collected data for better monetization through RTB.
   • By collecting data against their own first-party cookies and helping publishers manage data assets against the publisher’s first-party cookies, publisher-facing DMPs can quickly transition, and potentially open up new revenue, as Safari/iOS11 adoption ramps.
2. Utilize own ID matching service or contract out to identity vendor to map first-party cookie data assets.
   • Similar to publishers, pub-side DMPs can leverage their own internal ID matching products or an external vendor’s to map their own (and their publisher partners’) first-party cookies together. This acts as a stopgap, although for the DMP, with a substantial footprint across a number of publishers, this can be extremely valuable as mapping hundreds of domain-level cookies together delivers the same value as a single third-party cookie but with better defensibility as the ID is federated out to hundreds of domains rather than at one blockable third-party domain.
   • This will let DMPs continue to activate data through the data object of the bid stream, as well as sell data across clients as they would with third-party cookies were they an option.
3. Leverage an identity vendor’s common ID for the sale of publisher-sourced data directly to buyers outside of the bid stream.
   • Similar to publishers, without looping in buyers, publisher-facing DMPs will have a hard time building revenue through just the data object and pub-to-pub data sales. Enabling buy-side purchasing of segments and data assets will require a common ID not only between the DMP and the buyer, but also between the DMP, buyer, and ad exchange (so that the ID is passed directly as part of the bid request).
   • Publisher-facing DMPs should look to utilize a common, sustainable ID with their largest strategic platform partners (SSPs and DSPs) so that they can move towards selling data against a common ID instead of relying on cookie syncs.
   • It is unlikely but possible that a DMP may try to position itself as the common ID – this would require the DMP to create an RTB-activatable ID and gain acceptance for that ID from a large portion of the programmatic ecosystem. The caution in pursuing this route is that it is highly unlikely that any other DMPs will adopt a common ID owned by another DMP, which limits the market for that common ID to a single chain of partners associated with the DMP. A centralized identity management company will offer stronger open activation reach than any single DMP, even if that single DMP has the perfect technical solution for identity.

 

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:

1. Consolidate Exchange ID into federated first-party cookies.
   • Like publishers and publisher-facing DMPs, many ad exchanges and SSPs have header bidding tags or other ways of directly accessing the top-level domain via JavaScript. And like those companies, exchanges would likely benefit from deploying first-party cookies from publisher pages for use as the repository for the Exchange ID. This will preserve at least some of the data assets the exchange has against its own ID, enable the exchange to continue to service the Exchange ID parameter of the User object, and facilitate transitioning to a centralized ID.
2. Utilize identity vendor to ID-match first-party cookies and provide that identity 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 identity vendor’s ID)
   • Ad Exchanges can utilize ID matching to graph their first-party cookies together enabling cross-domain Exchange IDs and cross-domain identity to be functionally part of the bid stream for all buyers. Then, by switching to passing the identity vendor’s ID directly in the bid stream the ad exchange can enable its buyers and sellers to utilize that ID rather than syncing first-party cookies both internally and externally for monetization. This will dramatically improve efficiency for all parties – rather than hosting a sync on the exchange side (which is expensive and inefficient), the exchange will outsource identity management to at least one vendor that buyers and sellers can both leverage outside the exchange for data sales and purchasing. In addition to covering Safari, this will also increase the efficacy of the exchange’s targeting outside Safari, where sync issues and sync costs will become less of a concern.
3. Utilize more than one identity vendor to ensure wide coverage of DSP partner’s chosen identity vendors
   • Given the buy side does not have the same access to the page that the sell side does, they will need identity vendors more immediately than the sell side. Rather than require a switch-over of all buyers to one ad exchange chosen ID, ad exchanges can pass the ID of choice to each vendor in the Buyer UID parameter. Rather than that parameter representing the best effort of the exchange to sync IDs, it can represent the chosen centralized ID for that buyer, as opposed to other buyers on the ad exchange. This ID should be directly activatable without hashing and should be managed by the identity vendor so it is available as part of the bid request for 95% + of requests to the buyer.
4. Work with publisher partners to communicate audience characteristics in a structured way for buyers to evaluate. Examine:
   • Use common audience taxonomies and the implementation of publisher-driven classification against these, including determining methods of consistent, cross-publisher classification, and a trustable / tamper-resistant process of assignment.
   • Develop content adjacency signals for audience segment inference. Similar to above, establish methods to evaluate trust of these signals.
   • Develop consistent audience survey methods for publisher partner execution and leverage the resulting partner-specific data for follow-up targeting.
   • Leverage publisher partner CRM data for additional targeting insight, with the appropriate methods of validation.
5. Explore “link decoration” (or URI-Query) options as a way of communicating information necessary to achieving the above scenarios
   • Without HTTP cookies, user-identity, audience segment, and other information may need to be transferred on the URL.

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:

1. 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.
2. 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

• Buyers: Evaluate in-house and external commercial modelling options so impression valuation and measurement strategies within Safari environments are not as reliant on third-party cookie relationships. This could include reliance on a dedicated cookie ID matching service throughout a chosen technology stack, use of non-cookie -based information to decision against impression opportunities, or prioritizing publishers that have predictable and consistent first-party relationship with consumers.

 

• Publishers: Work with technology partners to examine how site audience data can be captured and communicated in a first-party context, and how centralized identity syncing solutions could advance monetization approaches. Also consider sales strategies that return to an emphasis on contextual alignment with premium content vs. audience addressability.

 

• Platforms: Re-examine buyer and seller integrations – and syncing strategies, specifically –– to find practical ways to communicate first-party device, audience, and context-based information for the purposes of cross-screen measurement and impression valuation.

 

• Everyone: 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.