A bidder can purchase inventory for multiple entities in a single bid, if those entities are Authorized Buyers clients. For example, a demand-side platform (DSP) might use its bidder to purchase inventory for several marketers or agencies who are themselves Authorized Buyers clients. This guide explains how to code your bidder to process a single request sent on behalf of multiple Authorized Buyers clients.
Background
Authorized Buyers works with ad networks, agency trading desks, and demand-side platforms (DSPs). In some scenarios, an ad network or agency trading desk may choose to work with one or more DSPs. There are two implementation options available for clients who work through a DSP:
- The DSP purchases inventory for marketers or agencies that are not Authorized Buyers clients. In this case, the DSP receives one bid request and responds with one bid. Google bills the DSP directly.
- The DSP purchases inventory for marketers or agencies that are Authorized Buyers clients. Authorized Buyers clients are required to bid independently, even when they use a DSP. This is to ensure publishers have visibility of the actual buyer, to enable exclusive allocations of inventory, and to ensure no redirects go from network to network. In this model, Google bills the Authorized Buyers client, not the DSP. The rest of this guide focuses on this scenario.
Authorized Buyers routes bid requests for child accounts of a parent bidder (DSP) through an ad group ID. Child account ad group IDs are provided at child account setup time by an account manager or Authorized Buyers and Open Bidding Support. The DSP uses this information to process the bid response. For a DSP that has Authorized Buyers clients using its technology to buy from Authorized Buyers, it receives a consolidated callout for a set of RTB clients.
Setup and pretargeting
All DSPs are configured for consolidated requests. Pretargeting criteria selection is done on the parent bidder level for all child accounts. This is called Bidder Level Pretargeting (BLP).
With BLP, inventory matching is only done on the parent bidder level. This simplifies the workflow and makes it easier to manage inventory and settings across many accounts.
Benefits of bidder level pretargeting versus regular pretargeting (deprecated)
Bidder-level pretargeting | Regular pretargeting (deprecated) |
---|---|
Parent seat manages eligibility for all seats | Each seat manages their own inventory eligibility |
All seats eligible for all traffic | Varying pretargeting setups across many accounts |
Simpler setup and easier to manage | Less control at parent bidder level, but granular control for specific seats |
Child accounts have a single adgroup ID associated with them, and thus, pretargeting matches are
included as one entry in the matching_ad_data
field of the BidRequest
for each matched child account.
When responding to a BidRequest
that contains pretargeting
matches from an account other than the parent account (for example,
any BidRequest
for which the matching_network_data
field is set), the billing_id
field in the BidResponse
is required so that Authorized Buyers knows which account and campaign to associate
with the bid. Any response that does not set the field is dropped. The field
remains optional for any BidRequest
that only includes pretargeting
matches from the bidder account. A response to a BidRequest
that
contains pretargeting matches from multiple accounts can return multiple ads.
Bidder level pretargeting example
Child seat (ad group ID: 123) | Parent seat (ad group ID: 124) |
Pretargeting: US + EU | Pretargeting: US + APAC |
Callout criteria | billing_id sent |
---|---|
US only | 123 + 124 |
EU only | 123 |
APAC only | 124 |
Example BidRequests
Below are examples of a BidRequest
. You'll note that there are multiple billing IDs
in these requests because the requests are applicable to multiple accounts.