Background

Ad-tech providers have historically used third-party cookies for conversion measurement, and for attributing conversions to ad interactions. Conversion measurement is critical for evaluating the performance of ad campaigns and automated bidding strategies. Now, with technology changes and privacy regulations on the rise, traditional ad-measurement systems must change in order to remain effective while protecting user privacy.

Chrome’s Attribution Reporting API (ARA), part of the Privacy Sandbox initiative, offers a new path to conversion measurement after Chrome’s planned third-party cookie deprecation in the second half of 2024, subject to addressing any remaining competition concerns of the UK’s Competition and Markets Authority (CMA). Google's ads teams plan to use the ARA for measurement, including on Google-owned inventory such as Search and YouTube, as well on third-party inventory available via our advertising technology products. We have made significant investments in learning to use the ARA more effectively for both, to help advertisers achieve more accurate measurement.

In a previous post, we provided a high-level overview of the approach Google’s ads teams are taking to effectively blend the ARA event-level and aggregate summary reports to maximize accuracy. A key point is that your configuration determines what data you query, and how you query it. It’s crucial for ad-tech providers to effectively configure the ARA for their use cases. Google’s ads teams have found that configuring specific ARA settings can lead to notable accuracy improvements. We encourage other ad-tech providers to integrate with the ARA to retrieve the conversion data they need, and process the ARA's output to help maintain accurate measurement in a post-third-party-cookie world.

The ARA is flexible to support various use cases. Google’s ads teams use this flexibility to configure unique ARA settings for each advertiser. This way, ARA-based measurement adapts to each advertiser’s specific needs. For example, we’ve noticed that when advertisers differ in conversion volume, it’s better to have advertiser-specific configurations related to the granularity of aggregation keys and the maximum observable conversions per ad interaction.

Google’s ads teams’ approach

Here's how Google's ads teams use the ARA to ensure the raw data we receive is as useful as possible for downstream blending. We configure ARA settings as explicit mathematical optimizations by defining objective functions to represent data quality, then choosing settings to optimize those functions. Ad-tech providers can choose their own approach. Google’s ads teams plan to continue sharing insights we learn from our own optimizations with the ad-tech community.

Please see our detailed technical explainer for more information about our approach to ARA configuration.

- Harikesh Nair, Senior Director, Data Science, Ads Measurement

Overview

Historically, ad-tech providers have used third-party cookies (3PC) as a mechanism for conversion measurement, and for attributing conversions to ad interactions. Conversion measurement provides critical ad performance data to advertisers, and helps optimize auction-based bidding strategies.

Currently, the online advertising ecosystem is pivoting towards improved ways to protect user privacy. Chrome’s Attribution Reporting API (ARA), a part of the larger Privacy Sandbox initiative, offers an alternative for measurement after the third-party cookie deprecation in 2024. Ad-tech providers, including Google’s ads platforms, should consider adopting the ARA to maintain high-quality conversion measurement and support the pivot toward user privacy protection.

Google Ads has made significant investments to use the ARA more effectively and to help advertisers achieve more accurate measurement. We encourage other ad-tech providers to integrate with the ARA, configure the integration to retrieve the data they need, and process the ARA's output to help maintain accurate measurement after the planned third-party cookie deprecation in 2024.

Goals of the ARA

The ARA has two goals:

• Protect users’ cross-site and cross-app identities from ad-tech providers, advertisers, publishers and other entities by using differential privacy techniques, such as aggregation, or adding an element of noise to the data.
• Provide useful measurement information to ad-tech providers, advertisers, and publishers.

The ARA represents a change to both the format and granularity of conversion data available to ad-tech providers. As a result, ad-tech providers must change their current measurement protocols in order to start leveraging the ARA.

A glimpse into our approach

Ad-tech providers who participate in the Privacy Sandbox initiative receive data from the ARA in two forms: event-level reports and aggregate summary reports. This way, two independent views of the same underlying data are available. We encourage ad-tech providers to configure the reporting settings in the API to optimize for better measurement accuracy without 3PC, as well as improve how these two types of reports can be post-processed and used together.

There are many possible ways to utilize the ARA reports. The methodology that works for an ad-tech provider will ultimately depend on its conversion data and measurement requirements. Google Ads has found that leveraging both report types can help the industry benefit from the strengths of each report.

Google Ads leverages both event types to produce a more complete, ad event-level log. We are committed to sharing our process and engaging with the ecosystem to help our partners and the broader industry transition into a future without third-party cookies.

For more details on how we’re implementing the Attribution Reporting API, please refer to our detailed technical guide.

Harikesh Nair, Director, Data Science, Ads Measurement

Google is launching experiments that are intended to provide bidders with an opportunity to test and provide collaborative feedback on ads-privacy proposals–these are features intended to improve user privacy protections and provide mechanisms for testing Chrome Privacy Sandbox proposals. We strongly encourage interested bidders to sign up and participate! Three new experiments made available today are described below.

Experiment #1: TURTLEDOVE simulationThe RTB protocols and infrastructure have been updated to enable a server-side simulation of Chrome’s TURTLEDOVE proposal, as described in the TURTLEDOVE simulation proposal. Bidders interested in participating can reference the TURTLEDOVE RTB Simulation API guide to learn more about the specific API and protocol changes associated with this experiment. Along with these changes, a new biddingFunctions resource for managing bidding functions that are used in the server-side simulation was added to the Real-time Bidding API.

The goal of this simulation is to provide bidders with an opportunity to experiment with Chrome’s proposal before it is implemented in Chrome, so that participating bidders can provide feedback on its viability and effectiveness. The APIs and modified RTB workflow used in the server-side simulation are conceptually similar to the ones that Chrome may later implement for TURTLEDOVE, based on existing proposals and public design discussions. Feedback relevant to Google’s simulation should be directed to the ads-privacy issue tracker, whereas feedback relevant to the TURTLEDOVE proposal itself should be directed to Chrome’s TURTLEDOVE issue tracker. To report bugs or technical questions about this experiment, you may contact the brse-eng-support@google.com support alias.

Experiment #2: Federated Learning of Cohorts (FLoC)Google will allow participating bidders to experiment with Chrome’s FLoC proposal by simulating FLoC cohorts on its servers, based on algorithms described in this Google Research & Ads whitepaper. To facilitate this experiment, a Floc message has been added to the BidRequest in the Google RTB protocol, and as an extension of the User object for Google’s OpenRTB implementation. The message is structured as follows:

message Floc {
    // The value of a cohort ID – a string identifier that is common to a large
    // cohort of users with similar browsing habits.
    optional string id = 1;
    // The type of the FLoC. See
    // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf.
    enum FlocType {
      // Default value that should not be used.
      FLOC_TYPE_UNKNOWN = 0;
      // FLoC simulated using affinity hierarchical clustering with centroids
      // and feature extraction based on Topic categories as described in the
      // whitepaper.

      SIMULATED_AFFINITY_CLUSTERING_CENTROID_VERTICAL = 2;
      // FLoC simulated using SortingLSH clustering algorithm and Domain One-hot
      // encoding feature extraction as described in the whitepaper.
      SIMULATED_SIMHASH_SORTING_LSH_DOMAIN_ONE_HOT = 3;
      // FLoC simulated using a k Random Centers locality-sensitive hash
      // function as described in
      // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/k-random-centers.md
      // with Domain TF-IDF feature extraction as described in the whitepaper.
      KCENTER_DOM_FILTERED_TFDIF = 4;
    }
    optional FlocType type = 2;
  }
  

Only web requests are in scope for the FLoC simulation experiment. In practice, only a small percentage of bid requests for bidders opted-in to the experiment would include this message, and those that do would not include pseudonymous user identifiers such as google_user_id and hosted_match_data.

Floc would also not be populated as a result of privacy controls, such as when users opt out of personalized advertising. Upon winning impressions, bidders can render creatives as usual and use their cookie-based identifiers to attribute conversions–for instance–to measure how well different FLoCs correlate with conversions.

We encourage participants to use the issue tracker to leave feedback on the simulated cohort algorithms. One useful metric to include would be the conversion rates for each FlocType in the experiment, possibly in comparison to regular traffic, where bidders may rely on cookie-based identifiers for targeting and optimization.

Experiment #3: Exchange-enforced frequency cappingThe RTB protocols have been updated to enable an experiment for the exchange-enforced frequency capping proposal, which intends to support the critical frequency capping use case for the inventory provided by a single exchange without reliance on user identifiers provided in bid requests. A FrequencyCap message has been added to the BidResponse in the Google RTB protocol, and as an extension of the Bid object for Google’s OpenRTB implementation. The message is structured as follows:

  message FrequencyCap {
    // An ID that can represent a bidder's use-case for frequency capping; for
    // example, it could represent their campaign, ad, line item, etc. It should
    // not contain any user-specific information or identifiers.
    optional string fcap_id = 1;

    // The time units for which frequency caps can be enforced.
    enum TimeUnit {
      UNKNOWN_TIME_UNIT = 0;
      MINUTE = 1;
      DAY = 2;
      WEEK = 3;
      MONTH = 4;
      // When INDEFINITE is used, time_range will be ignored. INDEFINITE means
      // the frequency cap will be applied for a long period of time, (longer
      // than a month) but not necessarily forever.
      INDEFINITE = 5;
    }

    // The unit of time used to specify the time window for which a frequency
    // cap applies.
    optional TimeUnit time_unit = 2;

    // The length of the time window, in units specified by time_unit, for which
    // the frequency cap applies. For instance, if time_unit=WEEK and
    // time_range=3, then capping is applied for a three week period. If the
    // time_unit=INDEFINITE, this will be ignored.
    optional int32 time_range = 3 [default = 1];

    // The maximum number of impressions allowed to be shown to a user for
    // the provided frequency_cap_id within the time window described by
    // time_unit and time_range.
    optional int32 max_imp = 4;
  }

Additional information about this experiment can be found in the proposal, and we encourage participants to leave feedback in the issue tracker.

Mark Saniscalchi, Authorized Buyers Developer Relations