Bid on Behalf of Multiple Accounts

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.


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.



OpenRTB Protobuf