Bidding Requirements and Best Practices

Bidding Integration Requirements

All in-house integrations must follow the criteria below in order to implement a correct and optimal integration.

  • Send requests for 100% of ad impressions that are winnable (for example, not direct-sold).
  • Send only 1 request for each impression opportunity.
  • Do not combine bidding and standard (aka tag) requests for the same ad unit.
  • Do not send a request for the same impression opportunity on both waterfall and bidding.
  • Send win, loss and timeout notifications with the appropriate loss codes.
  • Obtain buyeruid from client using Audience Network SDK. The buyeruid is the user bidder token generated on the client side, using the getBidderToken method from the Audience Network SDK.
  • Use Audience Network SDK to retrieve and render ads.
  • Request the ad only if the bid wins the auction.
  • Send bid requests using authentication token (app secret and request id).
  • Add a HTTP header to every request, called x-fb-pool-routing-token that contains bidder token as its value.
  • Set up multiple price floors on other demand sources that are in a traditional waterfall when combining that with bidding. Two price floors is generally a good start. This is to give more fine grained control of how the auction competes with the waterfall which will increase overall yield.

For more information on how to combine bidding and existing waterfalls see Integrating Bidding-Based Auction With Existing Waterfall

Bidding Best Practices

In addition to the optimal integration criteria, we recommended following these best practices.

  • Set a bid request timeout value of at least 1 second.
  • fetch BidderToken on server for each bid request.
  • Send a unique id for each request.
  • Read and log x-fb-an-errors HTTP header on bid responses with status code other than 200 to be used in troubleshooting.
  • Read and log x-fb-an-request-id HTTP header on all bid responses to be used in troubleshooting.
  • Use existing placement ids for bidding and don't create new placements unless you're running A/B tests or using a partner platform that requires creating new placements.
  • Use server-to-server integration where possible to shift processing and network utilization from the user's device and network to the publisher's servers and network and to allow bidding and auction modifications with no app changes.
  • You can pass a gzip-compressed request body if you provide a Content-Encoding:gzip header to your request.
  • Don't use price floors on bidding, as it'll be ignored.