Experiment #1: TURTLEDOVE simulation

The 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 [email protected] 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 capping

The 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

Source: Google Ads Developer Blog