[Open Bidding](https://support.google.com/admanager/answer/7128453)
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

You can use OpenRTB in either JSON or Protobuf formats.
[Learn more](https://developers.google.com/authorized-buyers/rtb/start#select-a-protocol).

### 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, see the
[OpenRTB Guide](https://developers.google.com/authorized-buyers/rtb/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](https://developers.google.com/authorized-buyers/rtb/request-guide#open-bidding-fields)
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](https://developers.google.com/authorized-buyers/rtb/response-guide#open-bidding-fields)
to learn more about Open Bidding-specific fields you can respond with.
**Note:** Bid requests sent to Open Bidding participants should receive a response within 300 to 1000 ms, depending on the inventory format. In order to determine the specific requirement for a given request, check the `BidRequest.tmax` field.

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

- [Interstitial ads](https://developers.google.com/authorized-buyers/rtb/interstitial-ads)
- [Video ads](https://developers.google.com/authorized-buyers/rtb/adx-video-guide)
- [OpenRTB Video ads](https://developers.google.com/authorized-buyers/rtb/openrtb-video-guide)
- [Native ads](https://developers.google.com/authorized-buyers/rtb/native-ads)
- [Native Video ads](https://developers.google.com/authorized-buyers/rtb/native-video-ads)
- [Buyer SDK ads](https://developers.google.com/authorized-buyers/rtb/buyer-sdk-ads)

### Track impressions to reduce discrepancies

It is strongly recommended that you use the optional
`BidResponse.seatbid.bid.ext.impression_tracking_url` field to
retrieve impression-level data on when Google records billable events for which
you will be charged.

## 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 `https://developers.google.com/authorized-buyers/rtb/openrtb-guide#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
`https://developers.google.com/authorized-buyers/rtb/openrtb-guide#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, `https://developers.google.com/authorized-buyers/rtb/response-guide#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
`https://developers.google.com/authorized-buyers/rtb/response-guide#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.

##### Meets technical requirements

In this example, Google (DV360) **creative HTML code from the bid response
is passed verbatim**, prepended and appended with an exchange-specific HTML
code.

```
<!-- START exchange-specific HTML header -->
<iframe src="https://exchange.example.com/impression?..." width="0" height="0" frameborder="0" scrolling="no" style="display:none;" marginheight="0" marginwidth="0"></iframe>
<!-- END exchange-specific HTML header -->
<!-- START HTML code as returned by Google in the bid response -->
<DIV STYLE="position: absolute; left: 0px; top: 0px; visibility: hidden;"><IMG SRC="https://pagead2.googlesyndication.com/pagead/gen_204?id=xbid&dbm_b=..." BORDER=0 WIDTH=1 HEIGHT=1 ALT="" STYLE="display:none"></DIV><iframe title="Blank" src="https://googleads.g.doubleclick.net/xbbe/pixel?d=..." style="display:none" aria-hidden="true"></iframe><div><div style="position:relative; display:inline-block;"><div class="GoogleActiveViewClass" id="DfaVisibilityIdentifier_..."><script>var url = 'https://googleads.g.doubleclick.net/dbm/ad?...';document.write('<script src="' + (window.rfl ? window.rfl(url) : url) + '"></s' + 'cript>');</script>...
<!-- END HTML code as returned by Google in the bid response -->
<!-- START exchange-specific HTML footer -->
<img src='https://exchange.example.com/track?...' width='0' height='0' style='display:none;'>
<!-- END exchange-specific HTML footer -->
```

##### Does not meet technical requirements

In this example, creative **HTML code returned by Google** is obfuscated
in the bid response provided by an exchange and *does not appear verbatim in
the bid response*. Google-provided HTML code may get rendered by an
exchange-provided wrapper in the browser.

```
<!-- START exchange ad tag that encodes / renders Google creative in the browser -->
<!-- Google creatives markup from the bid response (adm) is not present verbatim -->
<span class="ad"><script type='text/javascript' src='https://exchange.example.com/ad?p=%%WINNING_PRICE%%&m=n_ybbRoVpsLlXSo8gVHRn-W0tynBt-Hoe8t8m0qwKhLFiaF-0gB0U4w-5pjeB8IMIkg7PcRri5iCIjBMMKDqg
...'></script></span>
<!-- END exchange ad tag that encodes / renders Google creative in the browser -->
```

#### 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 the `BidResponse.seatbid.bid.adm` field **as is**, with exchange-specific macro expansions that normally apply.
2. DV360 can populate the `BidResponse.seatbid.bid.adm.nurl` field with a VAST document URL in bid responses to an exchange. An exchange can then pass that value with the `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.

##### Meets technical requirements

In this example, Google (DV360) **creative VAST URI from the bid response
is passed verbatim**, with an exchange adding its specific VAST event and
error trackers.

```
<!-- START exchange VAST tag referencing Google creative -->

<?xml version="1.0" encoding="UTF-8"?><VAST version="2.0"><Ad id="123456789"><Wrapper>

<!-- Google VAST URI from the bid response is present verbatim -->
<AdSystem>XBid</AdSystem><VASTAdTagURI><![CDATA[https://bid.g.doubleclick.net/dbm/vast?...]]></VASTAdTagURI>

<!-- START Exchange-specific event trackers -->

<Error><![CDATA[https://video.exchange.example.com/vast_error?error=[ERRORCODE]&...]]></Error><Impression><![CDATA[https://video.exchange.example.com/impression?price=%%WINNING_PRICE%%&...]]></Impression><Creatives><Creative id="1234567890" sequence="1"><Linear><TrackingEvents><Tracking event="creativeView"><![CDATA[https://video.exchange.example.com/track/view?...]]></Tracking><Tracking event="start"><![CDATA[https://video.exchange.example.com/track/start?...]]></Tracking><Tracking event="midpoint"><![CDATA[https://video.exchange.example.com/track/midpoint?...]]></Tracking></TrackingEvents><VideoClicks><ClickTracking><![CDATA[https://video.exchange.example.com/click?...]]></ClickTracking></VideoClicks>

<!-- END Exchange-specific event trackers -->

</Linear></Creative></Creatives></Wrapper></Ad></VAST>

<!-- END exchange VAST tag referencing Google creative -->
```

##### Does not meet technical requirements

In this example, creative **VAST code or URI returned by Google**
*does not appear verbatim in the bid response* , and instead, an
exchange-specific VAST wrapper is used. Google-provided VAST code may be loaded
by an exchange-provided VAST wrapper (as defined in `VASTAdTagURI`
element, `https://video.exchange.example.com/creative?...`) upon SDK
loading an ad.

```
<!-- START exchange VAST tag that encodes or loads Google VAST creative subsequently -->
<!-- Google VAST URI or VAST document from the bid response is not present verbatim -->

<?xml version="1.0" encoding="UTF-8"?><VAST version="2.0"><Ad id="1234567890"><Wrapper><AdSystem version="0.1">VideoExchange</AdSystem><VASTAdTagURI><![CDATA[https://video.exchange.example.com/creative?...]]></VASTAdTagURI><Error><![CDATA[https://video.exchange.example.com/error?ec=[ERRORCODE]]]></Error><Impression><![CDATA[https://video.exchange.example.com/imp?...]]></Impression><Creatives><Creative></Creative></Creatives></Wrapper></Ad></VAST>
<!-- END exchange VAST tag that encodes or loads Google VAST creative subsequently -->
```

## Deals

Exchanges participating in Open Bidding can use
[Preferred Deals](https://support.google.com/authorizedbuyers/answer/2604595)
(PD), [Private Auctions](https://support.google.com/authorizedbuyers/answer/2839853)
(PA) with Open Bidding. The deal ID and type must be specified as follows:

| Field | Description |
|---|---|
| `BidResponse.seatbid.bid.dealid` | 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. |
| `BidResponse.seatbid.bid.ext.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; ``` |

The following is a sample 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"
    }
  }
}
```

## Cookie matching

In order to populate Google-hosted
[match tables](https://developers.google.com/authorized-buyers/rtb/cookie-guide#match-table),
Open Bidding participants can use any of the options below that best suit their
needs:

- Cookie Matching: Buyer or exchange-initiated matching [Learn more](https://developers.google.com/authorized-buyers/rtb/cookie-guide#how-it-works).
- Pixel Matching: Google-initiated matching [Learn more](https://developers.google.com/authorized-buyers/rtb/cookie-guide#pixel-matching).
- Cookie Match Assist: Exchange-initiated matching with their bidders [Learn more](https://developers.google.com/authorized-buyers/rtb/cookie-guide#cookie-match-assist).

**Note:** Open Bidding participants are not able to create, populate, or target user lists at this time.

## Managing latency

You should use the trading locations found in the
[Peering Guide](https://developers.google.com/authorized-buyers/rtb/peer-guide#trading_locations)
to estimate the latency your bidder endpoints will have when responding to
incoming bid requests.

> [!IMPORTANT]
> Inventory is generally sent through the closest trading location, but this isn't guaranteed. The only way to guarantee access to all impressions is to have bidder endpoints in all trading locations.

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](https://developers.google.com/authorized-buyers/rtb/peer-guide#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](https://support.google.com/authorizedbuyers/answer/3187721).

## APIs

Open Bidding customers can use the [Authorized Buyers REST APIs](https://developers.google.com/authorized-buyers/apis/guides/start)
to access data that may be useful for troubleshooting purposes. Only the
following API resources are currently accessible:

- [v1.4 Performance Report](https://developers.google.com/authorized-buyers/apis/v1.4/performanceReport/list)
- [v2beta1 RTB Troubleshooting](https://developers.google.com/authorized-buyers/apis/guides/v2/rtb-troubleshooting)

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

- [Best practices for managing connections](https://developers.google.com/authorized-buyers/rtb/practices-guide#managing-connections)
- [Using bid URL macros](https://developers.google.com/authorized-buyers/rtb/request-guide#Bid-URL-Macros)
- [Decrypting price confirmations if you use the WINNING_PRICE macro](https://developers.google.com/authorized-buyers/rtb/response-guide/decrypt-price#scenario)
- [Testing recommendations and best practices](https://developers.google.com/authorized-buyers/rtb/test-guide)

## Sample bid requests and responses

Bid request and response samples for all supported protocols can be found in
the [Request](https://developers.google.com/authorized-buyers/rtb/request-guide#sample-bid-requests)
and [Response](https://developers.google.com/authorized-buyers/rtb/response-guide#sample-bid-responses)
guides.