Tag Archives: authorized_buyers

Migration to OpenRTB, deprecation of the Authorized Buyers Real-time Bidding Protocol

To align more closely with industry practices and embrace OpenRTB as the standard protocol, Authorized Buyers Real-time Bidding protocol will sunset February 15th, 2025. Following this date, bid requests will no longer be sent to endpoints configured to use the Authorized Buyers RTB protocol. After this time we will support the OpenRTB protocol only. We strongly recommend that you transition to either the JSON or Protobuf formats of the Authorized Buyers OpenRTB protocol implementation as early as possible to avoid interruptions to your bidding integration.

As a first step in migrating to OpenRTB, we suggest that you read through the OpenRTB migration guide. The guide highlights differences between the Google RTB protocol and the supported OpenRTB formats, identifies how Google RTB protocol fields map to OpenRTB, and provides instructions for complex mappings. We will continue updating our developer content as we approach February 2025 to provide additional guidance, and to ensure a smooth migration.

For any questions or feedback you have concerning the transition to OpenRTB, please contact us using the Authorized Buyers support forum, or [email protected].

Announcing the deprecation of Ad Exchange Buyer II API

The Ad Exchange Buyer II API is now deprecated, and the following resources will be sunset on September 29th, 2023:

Accessing the sunset resources will return an error response following the sunset date. Note that RTB Troubleshooting resources aren’t included in this list, and will continue to be supported until further notice.

To continue programmatically accessing your Client Access and Marketplace configurations, you should migrate to the Authorized Buyers Marketplace API. For more information, we recommend that you review the Marketplace guide and samples. If you have any questions or feedback, feel free to reach out to us via the Authorized Buyers API Forum.

Removing support for old OpenRTB versions

Starting today, Google’s OpenRTB implementation will be updated to only include fields and messages for the latest supported version, OpenRTB 2.5. This will affect the OpenRTB protocol and any APIs or tools used to configure bidder endpoints.

OpenRTB protocol changes
As a result of supporting only the latest version, the following fields are deprecated and will no longer be populated:
  • BidRequest.imp[].banner.hmax
  • BidRequest.imp[].banner.hmin
  • BidRequest.imp[].banner.wmax
  • BidRequest.imp[].banner.wmin
Additionally, the following fields may now be populated for all bidders:
  • BidRequest.device.ext.user_agent_data
  • BidRequest.device.geo.accuracy
  • BidRequest.device.geo.utcoffset
  • BidRequest.imp[].banner.api: This will support the value MRAID_3.
  • BidRequest.imp[].banner.format
  • BidRequest.imp[].banner.vcm
  • BidRequest.imp[].metric
  • BidRequest.imp[].native.api: This will support the value MRAID_3.
  • BidRequest.imp[].video.api: This will support the value MRAID_3.
  • BidRequest.imp[].video.companionad.api
  • BidRequest.imp[].video.companionad.format
  • BidRequest.imp[].video.companionad.vcm
  • BidRequest.imp[].video.linearity
  • BidRequest.imp[].video.maxduration
  • BidRequest.imp[].video.placement
  • BidRequest.imp[].video.playbackend
  • BidRequest.imp[].video.skip
  • BidRequest.site.mobile
  • BidRequest.test
  • BidRequest.wlang
If a newer OpenRTB specification is published, Google may upgrade the current supported version to match it. Previously deprecated fields that are removed from the specification will also be removed from the protocol. Non-deprecated fields that are removed will be marked as deprecated in the protocol, and eventually removed following a brief deprecation period.

Authorized Buyers Real-time Bidding API changes
The behavior of the bidders.endpoints resource will change. The following enum values for bidProtocol will be deprecated:
  • OPENRTB_2_2
  • OPENRTB_2_3
  • OPENRTB_2_4
  • OPENRTB_2_5
New enum values for bidProtocol will be added to represent the latest supported OpenRTB version in either JSON or Protobuf formats:
If you have existing endpoints with their bidProtocol set to any of the deprecated values above, they will automatically be migrated to either OPENRTB_JSON or OPENRTB_PROTOBUF depending on the format specified by the original value. Additionally, any modifications to your endpoints that would set bidProtocol to the deprecated values will instead set it to OPENRTB_JSON or OPENRTB_PROTOBUF.

Feel free to reach out to us via the Authorized Buyers API support forum with any feedback or questions you may have related to these changes.

Announcing the release of the Authorized Buyers Marketplace API

The Authorized Buyers Marketplace API has been released. You can use the Marketplace API to manage clients, users, and auction packages, and to negotiate proposals with publishers. This new API is intended to replace the following Marketplace resources included in the Ad Exchange Buyer II API:
Although the Ad Exchange Buyer II API is not deprecated at this time, we recommend that all Marketplace integrations adopt the new API to receive the latest updates going forward. New features will only appear in the Marketplace API.

The Marketplace API introduces the following features:
  • Programmatic support for auction packages.
  • Deals are now a sub-resource of proposals.
  • The finalizedDeals resource helps you manage deals.
  • The rtbMetrics field of finalizedDeals provides performance data.
Given that the Marketplace API is distinct from the existing Real-time Bidding and Ad Exchange Buyer II APIs, please note that you need to enable the Authorized Buyers Marketplace API in your Google Cloud Console project. Additionally, you need to update your existing OAuth 2.0 credentials and workflows to include a new API scope:


For any questions or feedback about this API, please contact us via our support forums.

Announcing new Real-time Bidding experiments

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 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 simulated using affinity hierarchical clustering with centroids
// and feature extraction based on Topic categories as described in the
// whitepaper.

// FLoC simulated using SortingLSH clustering algorithm and Domain One-hot
// encoding feature extraction as described in the whitepaper.
// 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.
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 {
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.

// 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

Announcing Authorized Buyers’ new Real-Time Bidding API

Today we are pleased to announce the release of Authorized Buyers’ Real-Time Bidding API. In addition, we are also announcing that all versions of the Ad Exchange Buyer API are now deprecated, and will sunset by the end of Q1, 2021. With the exception of the Budgets resource that is not being carried over to the new API, we recommend migrating to the Real-Time Bidding API’s equivalent resources well before the sunset to avoid interruptions to your integration. Note that this deprecation does not include the Ad Exchange Buyer II API, which will continue to be supported.

The Real-Time Bidding API currently includes resources for managing creatives and user lists, and will be expanded in Q3 to include resources for managing pretargeting. Additional updates through Q3 and Q4 will add features for managing accounts and billing information, and retrieving performance reports. We recommend reading through the migration guide—which will be updated as new features are added to the Real-Time Bidding API—to learn more about getting started with the new API.

Feel free to reach out to us via the Authorized Buyers API forums if you have questions or feedback concerning the Real-Time Bidding API.

Mark Saniscalchi, Authorized Buyers Developer Relations