Configuring an Open Bidding Integration

Open Bidding enables exchanges and other buyers to leverage Google's Real-Time Bidding infrastructure to bid on Google Ad Manager and AdMob inventory.

In order to participate in Open Bidding, configure a Real-Time Bidding integration customized for your Open Bidding use-case, and send bidder endpoints to your Google account manager for testing to verify that the integration functions correctly. This is a one-time process.

Limit your integration to select publishers

Your Open Bidding integration can remain in "private mode" until you're ready to accept requests from any publisher. While in private mode, you can work with your account team to connect with select publishers and remain in this state until you're ready to scale. Once you exit private mode, your account will be visible to all publishers.

Supported protocols and encoding

Open Bidding uses the proprietary Authorized Buyers and OpenRTB real-time bidding RTB protocols. Learn more.

Google OpenRTB implementation

Google's OpenRTB implementation does not support all features found in the OpenRTB specification, and adds extensions for Authorized Buyers and Open Bidding-specific functionality. To learn more about Google's OpenRTB implementation, and how it relates to the proprietary Authorized Buyers Real-Time Bidding protocol, see the OpenRTB Guide.

Handle incoming bid requests

Open Bidding uses the same BidRequest structure as Authorized Buyers, but some fields are exclusively sent to Open Bidding participants. See the Request Guide to learn more about Open Bidding-specific fields sent in the bid request.

Respond with a Bid

Open Bidding also uses a BidResponse structure similar to that of Authorized Buyers, with some exclusive fields sent to Open Bidding participants. See the Response Guide to learn more about Open Bidding-specific fields you can respond with.

Depending on the desired ad format you intend to bid with, the response structure can differ in significant ways. It is recommended that you review the following guides to help you configure your bidder application to respond with bids for common ad formats:

Track impressions to reduce discrepancies

It is strongly recommended that you use the optional impression_tracking_url field to retrieve impression-level data on when Google records billable events you will be charged for. For OpenRTB this is exposed as BidResponse.seatbid[].bid[].ext.impression_tracking_url, and as BidResponse.ad[].impression_tracking_url in the Google protocol.

SDK rendered ads

Mobile app inventory originating from publishers who integrated your Open Bidding adapter into their application can accept bids with the SDK rendered ad format. SDK rendered ads are defined by you; how they render is based on your SDK implementation and the SdkRenderedAd included in the bid response. In order to begin working with SDK rendered ads, first contact your Technical Account Manager to configure your account, then implement an Open Bidding Adapter that enables your SDK to communicate with the Google Mobile Ads SDK.

Bid request signals

Bid requests for mobile app inventory will include details about SDKs and adapters installed in the publisher's app that are accessible to you. You can use this to determine the SDK and adapter versions installed in the publisher's app, and retrieve the SDK ID that must be provided in the bid response when placing a bid containing an SDK rendered ad. The Google protocol exposes this via the BidRequest.mobile.installed_sdk field, and the OpenRTB protocol via BidRequest.app.ext.installed_sdk. You can learn more about the InstalledSdk message in the Google and OpenRTB protocol guides.

Placing a bid with an SDK rendered ad

In order to place a bid containing an SDK rendered ad, your bid response must include the SDK's ID retrieved from the bid request, as well as the data that will be rendered by that SDK. The Google protocol exposes this via the BidResponse.ad[].sdk_rendered_ad field, and the OpenRTB protocol via BidResponse.seatbid[].bid[].ext.sdk_rendered_ad. You can learn more about the SdkRenderedAd message in the Google and OpenRTB protocol guides.

Google demand discrepancy resolution (Beta)

This feature aims to ensure that the number of impressions for which an exchange is billed aligns with the number of impressions that are paid by Google Display & Video 360 (DV360).

By accurately identifying DV360 impressions that were served by Open Bidding, Google can then adjust for ad spam and billable event discrepancies to make sure you are not billed for impressions for which you are not paid.

Propagate google_query_id in bid requests

In order to ensure that the number of valid impressions matches across Google demand, the google_query_id must be propagated as is from Open Bidding requests to Google demand platforms. This is a prerequisite to Open Bidding discrepancy resolution. The current expected length of the google_query_id is around 64 bytes.

Propagate third_party_buyer_token in bid responses

In the event that the Google demand platform wins an exchange's internal auction, third_party_buyer_token field must be propagated as is in the bid response back through the Open Bidding impression. This allows Google publisher platforms to establish that the winning bid from an Open Bidding partner is a bid on behalf of Google demand for the same impression opportunity. The current maximum length of this field is expected to be 150 bytes.

Pass Google creative markup as is in bid responses

In order to ensure that the discrepancy resolution applies to bids from Google demand, an exchange is required to propagate Google creative markup without any wrappers (script tags, iframes, or VAST wrappers). Due to the discrepancy resolution, Google may invalidate and not invoice for those Open Bidding impressions that weren’t counted by Google demand platforms. Google will periodically check creative markup to confirm that bids with third_party_buyer_token were submitted on behalf of Google demand, and not any other buyer.

HTML5 creatives

An exchange is required to submit Google HTML markup as is, with exchange-specific macro expansions that normally apply, and, optionally, extra tracker pixels or scripts an exchange normally adds.

Google is unable to apply discrepancy resolution if an exchange wraps Google HTML creative into a tag (script, iframe, or other techniques) that subsequently load or render Google HTML code.

VAST video creatives

To be eligible for the discrepancy resolution, an exchange is required to use one of the following approaches to populate VASTTagURI in VAST XML responses:

  1. An exchange can preserve the value of VASTTagURI element as part of VAST XML document returned by Google in adm field as is, with exchange-specific macro expansions that normally apply.
  2. DV360 can populate the nurl field with a VAST document URL in bid responses to an exchange. An exchange can then pass the value of nurl that Google (DV360) responds with in VASTTagURI tag, with exchange-specific macros expanded normally as needed.

An exchange can specify additional VAST event and error trackers within VAST XML document if necessary.

Deals

Exchanges participating in Open Bidding can use Preferred Deals (PD), Private Auctions (PA) with Open Bidding. The deal ID and type must be specified as follows:

Field Description
OpenRTB protocol:
BidResponse.seatbid[].bid[].dealid

Google protocol:
BidResponse.ad[].adslot[].exchange_deal_id
The deal ID from the exchange's namespace associated with the bid and reported to publishers. This is arbitrary UTF8 text and must be no more than 64 bytes.
OpenRTB protocol:
BidResponse.seatbid[].bid[].ext.exchange_deal_type

Google protocol:
BidResponse.ad[].adslot[].exchange_deal_type
An enum specifying the type of deal. This is reported to publishers and affects how the deal is treated in the auction. Possible values are:
OPEN_AUCTION = 0;
PRIVATE_AUCTION = 1;
PREFERRED_DEAL = 2;
EXCHANGE_AUCTION_PACKAGE = 3;

Below is a sample OpenRTB bid response for PD/PA.

id: "ECHO_BIDREQUEST_ID"
seatbid {
  bid {
    id: "BID_ID"
    impid: "1"
    price: 1.23
    adm: "AD_TAG"
    adomain: "DECLARED_LANDING_PAGE_URL"
    cid: "BILLING_ID"
    crid: "CREATIVE_ID"
    dealid: "DEAL_ID"
    w: 300
    h: 250
    [com.google.doubleclick.bid] {
      impression_tracking_url: "IMPRESSION_TRACKING_URL"
      exchange_deal_type: "DEAL_TYPE"
    }
  }
}

In order to populate Google-hosted match tables, Open Bidding participants can use any of the options below that best suit their needs:

  • Cookie Matching: Buyer or exchange-initiated matching Learn more.
  • Pixel Matching: Google-initiated matching Learn more.
  • Cookie Match Assist: Exchange-initiated matching with their bidders Learn more.

Managing latency

You should use the trading locations found in the Peering Guide to estimate the latency your bidder endpoints will have when responding to incoming bid requests.

Large exchanges that receive a high volume of bid requests should consider entering into a peering arrangement with Google to reduce latency and latency volatility. Learn more about peering.

Click macros

We recommend that you implement click macros. These will allow reporting that includes clicks and click-derived metrics for your account and for the publishers you work with. Learn more.

APIs

Open Bidding customers can use the Authorized Buyers REST APIs to access data that may be useful for troubleshooting purposes. Only the following API resources are currently accessible:

You can contact your Technical Account Manager to configure your account for accessing these APIs, and to retrieve the account ID needed to make API calls. For technical support in using these APIs, you may contact the adxbuyerapi-support@google.com support alias.

Additional resources

Sample bid requests and responses

Bid request and response samples for all supported protocols can be found in the Request and Response guides.