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 ad group IDs. A child account is expected to set up pretargeting for both campaigns and ad groups, and to provide the ad group ID of the pretargeting along with any other requested fields to its DSP. The DSP uses this information to process the bid response.

There are two options for DSPs who have Authorized Buyers clients using the DSP's technology to buy from Authorized Buyers:

  • Receive a consolidated callout for a set of RTB clients. This scenario is described in this document.
  • Receive separate, multiple, RTB callouts for each Authorized Buyers client buying through the DSP. In this case the DSP receives a separate HTTPS request for each account that configures the DSP's server as the associated URL. These calls come into the DSP's servers independently, allowing for easy load-balancing and logical separation of clients.

Setup and pretargeting

A DSP can choose to have multiple requests consolidated into a single HTTP request. To be configured for consolidated callouts, the DSP must sign an additional contract. Contact your account manager to arrange this.

For DSPs configured for consolidated requests, pretargeting criteria selection can be 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 regardless of the child account configuration. This simplifies the workflow and makes it easier to manage inventory and settings across many accounts.

Benefits of bidder level pretargeting vs. regular pretargeting

Bidder-level pretargeting Regular pretargeting
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

Every pretargeting match is included as one entry in the matching_ad_data field of the BidRequest. Only one ad group from a child account will be sent, so as a best practice, only one ad group should be active for each child seat. If there is more than one ad group, the matching_ad_data entry will include the numerically lowest active ad group ID per child seat. Buyers can use the BillingInfo to gather all active ad group IDs.

When responding to a BidRequest that contains pretargeting matches from an account other than the parent account (i.e., 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