The Privacy Sandbox is Google’s proposed solution for marketers reacting to the announcement that third-party cookies in Google Chrome are set to become obsolete.
One role of third-party cookies is to correlate user actions on external websites (i.e. ad clicks and impressions) with conversions on your website. This reporting enables campaign attribution reporting, campaign reach reporting, impression capping, and campaign optimization.
To measure campaign effectiveness without third-party cookies, the Privacy Sandbox includes multiple purpose-built Application Programming Interfaces (APIs) to address.
The two primary APIs in development are the Event Conversion Measurement API and the Aggregate Measurement API. Let’s explore the current status of each, along with what this means for you.
Event Conversion Measurement API
Goal
To measure when an ad click leads to a conversion without using cross-site identifiers. Ultimately, the long-term goal is a solution for counting and attributing conversions to optimize ad spend without cross-site identifiers.
Traditional “Pre-Privacy” Solution
Currently, ad click and impression measurement relies on third-party cookies. When a user loads a page on a publisher’s website, ads are loaded. The scripts responsible for loading these ads also set a third-party cookie containing a unique identifier associated with the user (the browser loading the ad). In addition to these behaviors, data is sent to the advertising network which contains information about the ad rendered (an ID for the ad), as well as the ID associated with the user. Even if the user does not click, the fact that the impression happened is registered and associated with that user.
Say the user is then shown the same ad on another page. Again, the third-party cookie ID is read and collected along with the ad information, registering another impression. In this case, the user then clicks on the ad—taking them to the advertiser’s website. When this click happens, data is sent to the ad network registering the click event and containing the ad information and user ID (from the third-party cookie). A user then purchases that product on the advertiser’s website. A conversion tag for the ad technology will be executed on the purchase to collect information about the purchase, the product purchased, and again the ID of the user (from the third-party cookie). Now the ad technology vendor has events for the ad impression, the ad click, and the conversion—all associated with the same product and the same user ID. This allows for a correlation and attribution of the conversion to those advertising events.
All of this relies on the IDs stored in the third-party cookie across domains in order to join the data together and associate conversion with the click and impression data.
How the “Post-Privacy” Solution Works
Under the Event Conversion Measurement API, click and conversion activity are stored in the browser where they are correlated. Correlated conversion data is then reported to ad tech platforms after set intervals with minimal contextual information (enough to optimize campaign performance but not enough to identify a user).
A user loads a webpage on the publisher website, embedded in the page is an ad. The ad element includes some contextual information such as the conversion destination (domain), reporting origin (domain of the adtech provider for report sending), impression data, and expiry duration.
The user then clicks on the ad and navigates to the advertiser (destination) domain. Following the confirmed navigation, the click data is stored in the browser. This includes the click ID, conversion site (where the user navigated to), report location (adtech domain to which reporting will be sent), and expiry for associating/sending the conversion information.
Later on, the user buys the item featured in the ad on the advertiser’s site. A conversion tag for the adtech platform registers the conversion for the adtech platform and defines conversion data. The adtech platform then sends a special request with the conversion data to the browser. This request orders the browser to schedule a conversion report. The browser matches the conversion data with the click ID which it still has stored from earlier to be included in the conversion report. The conversion report contains the click data (from publisher’s site) and the conversion data (from advertiser’s site). The browser then schedules a conversion report to be sent.
Reports are sent by the browser to adtech platforms on defined intervals and include the click data from original ad click, data associated with the conversion, and conversion credit attributable to the click.
Helpful notes:
- Browser makes the conversion associations using the defined ‘conversiondestination’ defined in the ad element which it stored when the click occurred.
- Several ad clicks can match the same conversion. If the same ad is clicked on multiple websites by the same user within the impressionexpiry limit of each, then each click will be associated with the conversion.
- API follows a last-click attribution model for the assignment of conversion credit attribution: 100 for the most recent matching ad click and 0 for the rest.
- Impression data (click ID) is a 64-bit identifier.
- Limit of 3 impressions per conversion event.
- Conversion data is limited to 3 bits (integer 0 to 7).
- In effect limited to associating clicks with just 8 conversion events on your site.
- Conversion data is noised.
- 5% of the time the API will report a random 3-bit value to protect from user privacy. Protected case here is someone trying to create a unique identifier based upon data from several conversions.
- Is possible to determine the correct conversion count at an accurate level.
- Impressionexpiry is limited to 30 days—this is default value.
- Conversion report scheduling/sending happens at intervals of 2 days, 7 days, and impressionexpiry.
- All intervals are the duration of time after the ad was clicked.
Current Status of the “Post-Privacy” Solution
The API is at an early experimental stage. The origin trial is the first iteration and many things could change moving forward. The current iteration is in active origin trial through July 14, 2021.
Current support:
- Measure click-through conversions with coarse information about the conversion
- Gather data to optimize ad selection (train machine learning models)
Not supported:
- View-through conversion measurement
- Multiple reporting endpoints
- Web conversions that started in a native application
- Conversion lift measurement / incrementality
- Attribution models beyond last-click
- Use cases requiring larger amounts of conversion event data (i.e. purchase values or product information)
What This Means for Advertisers
Put simply, the days of granular, real-time campaign conversion reporting are over. A core component of this new method for conversion measurement is aggregate, time-delayed reporting. Conversion information is stored within the browser until it reaches adequate levels of aggregation in order to protect the anonymity of the user. This means that conversion reporting will be delayed and the ability to optimize campaigns in real time will be reduced.
This new reality needs to be embraced by advertisers and targeting strategies will need to be adjusted accordingly. You can begin building some of these new strategies and approaches to reporting, analysis, and optimization today. A further reliance on your own first-party campaign reporting will be necessary. This means things like properly appending campaign parameters to landing page URLs and having reliable first-party conversion data will be more important than ever.
In addition, multi-touch attribution modeling will be impacted. Right now, only ad clicks are supported for conversion reporting with this API. Top-of-funnel activities like ad impressions can’t be included in attribution models. The intention as the proposal and technical solution evolves is to add this support. It is important to stay on top of the current status of this solution to understand implications for your reporting moving forward. We’ll update these resources as those updates are made.
Further Reading
Aggregate Measurement API
Goal
To provide ads measurement data without the need to use cross-site identifiers such as third-party cookies. The critical functionality of this API is to measure the reach of a particular ad campaign (how many times unique users viewed an ad across multiple sites). APIs should also help with per-user impression capping for ads and campaigns.
Traditional “Pre-Privacy” Solution
When an ad is displayed to a user, a third-party cookie is being read (and if not present, set) to associate a unique identifier with the impression. This unique identifier (third-party cookie ID) is collected via a tag for the ad technology serving the ad, along with context of the ad. This information is aggregated and then reported on by the advertising technology vendor to show how many unique users have viewed a particular ad, as well as the frequency of those impressions.
How the “Post-Privacy” Solution Works
A record of an impression of a given campaign is added as an entry in a browser storage area (JS layer similar to localStorage) on each impression. Each entry supports simple key-value pairs for things like demographic slices (‘country’ as an example). These entries are encrypted and sent to a reporting origin in an encrypted format. A write-only, per-origin data store flushes data to a reporting endpoint after aggregation thresholds are met across many clients.
Current Status of the “Post-Privacy” Solution
Aggregate Measurement APIs are still in development. Chrome’s plan is to open the Aggregate Measurement API for testing via public origin trials in the first half of 2021.
What This Means for Advertisers
The traditional methods reporting on top of funnel activities across the web will be limited. There are similar implications for the delays in reporting information as with the Event Conversion Measurement API and alternative methods for impression capping will also need to be explored. As this API is in a very early stage, it is too soon to make any broad conclusions or provide tactical recommendations for preparation. We will update as the solution becomes more fully developed.
