Today we are going break down all of the different elements of a header bidding implementation, from the header bidding wrapper to DFP line items, to help you better understand the mechanics of how header bidding works.
A quick technical overview of header bidding
Before we jump into the specific elements involved in a header auction, let’s do a quick overview of the full process.
When a user visits the website, the header bidding script in the head of the web page “sees” this user and sends a request to all of the integrated partners (SSPs and exchanges) simultaneously. At this time, each partner initiates an auction with their DSPs. The DSPs then return their bids for the impression and the winning bid is returned to the ad server so the ad server can determine the final line item to serve. The marketer’s ad server is called with the final line item and the ad creative is returned via CDN and loaded on the page. Notice that the workflow of this process is very similar to that of a waterfall except all of the partners are called simultaneously instead of routing the call through a number of passbacks from partner to partner.
Header bidding elements and their roles in the auction
Bidder – a bidder is simply a partner that is equipped to receive requests and send bids via a header bidding implementation. This could be a supply-side platform (SSP), ad network, retargeted, etc. There are now over twenty different ad tech companies that have their own “bidder.” It is best practice to work with at least 6-8 different bidders in a healthy header auction in order to increase competition for inventory.
Header bidding wrapper or container – A piece of Javascript that “wraps” together ad requests and bids in the <head></head> section of a website. Within 500-1000 milliseconds, the container sorts these bids and selects the winner. The wrapper organizes all partner bids and applies auction logic and key values to returns bids.
Header bidding mediation – Mediation is the main job of the wrapper or container code. The wrapper code asynchronously calls all bidders, collects their bids and determines a winning bid before the ad server ever gets involved (thus the terms “pre-bidding” or “advance bidding”, early terms used for header bidding).
Header bidding adaptor – Partner-specific code that allows them to communicate with the wrapper to receive requests and return bids to the auction.
Timeout – Header auctions must be completed within a very small window so they do not negatively impact page latency. Most wrappers, most notably Prebid.js, have timeout settings that allow a publisher to determine how long the auction should wait for each partner to return a bid before closing the auction.
Ad server – The winning bids from header bidding auctions are sent along to the publisher’s ad server to select the appropriate line item and return the winning creative to the correct zone on the page. For most publishers using DFP, the winning bid must also compete against AdX dynamic allocation at that time.
Key values – When bids are received, the wrapper code adds the price and creative identifier to the ad server’s call as a set of query string parameters. This process is called key value targeting.
Header bidding line items – Line items are setup to target specific bid prices, allowing the bidders’ programmatic demand to compete with other line items based on price. The winning bid is then matched to the corresponding line item in order to select the correct creative to return to the page.
Ad creative – The actual ad asset (an image file) that is returned to the page which extracts and displays the ad from the bids returned via the header code.
To learn more about how all of these elements work together in symphony each time a page is loaded, check out this video with Sovrn’s header bidding guru, Tony Casson.
