» Header Bidding

Let’s be clear, client-side header bidding is dead on arrival for video. It’s an outdated mode that isn’t effective for the video format. While client-side header bidding makes sense in display, where the header bidding phenomenon first emerged, the industry has continued to evolve, moving towards server-side model. To handle the hefty weight of video and to take advantage of modern technology, video header bidding should be executed server side.

In display, lightweight creatives are cached in the header, making them instantly ready for demand to be called. Due to the large associated file sizes, the same isn’t as effective with video. Not to mention that there is no header in video header bidding, where instead, the video player acts as the mediating layer between the website and demand side platforms.  In display, which has traditionally been executed client-side, the number of header bidding partners a publisher can work with is limited by the number of the network connections allowed by the browser. Most modern browsers can handle between 9-17 connections at any given moment. Here is how client-side header bidding works:

clientsideheaderbidding

  1. Page loads, player loads, the header bidder container (HBC) code loads, including each header bidding partners’ (HBPs) code, each of which fires the opportunity to their respective servers.
  2. HBPs send the opportunity to their demand partners.
  3. Upon receiving responses, HBPs conduct server side auctions, select winners and send the winning ads back to the HBC.
  4. The HBC mediates among the respective submissions from each HBP, selects the winner and modifies the Master Video Tag (MVT) with Key Value Pairs (KVPs) that instruct DFP on which line item to return.
  5. DFP determines the final line item to serve and sends the corresponding line item to the player, which plays the ad.

The cutting-edge version of header bidding relies on a lightweight execution of JavaScript code client side and brings the programmatic auction server-side, where there is then a server-to-server connection between the supply and demand side platforms. This is much more amenable to the video format and allows for unlimited header bidding partners. This client-to-server to server model has several advantages as it:

  • Provides more control over latency, a serious concern for video header bidding,
  • Moves the complexity from the client to the server. This allows a website owner to shift the responsibility of managing complex code from themselves to their header bidding provider. Managing that complex code is part of the domain expertise that a header bidding provider offers, alleviating the burden from the website owner.
  • Mitigates some of the risk of user abandonment and/or user adoption of an ad blocker. Some savvy users run extensions like Ghostery to gain insight who’s tracking their web browsing. When header bidding is executed client side, all the calls out to demand partners are made client-side, making them visible to these savvy users. If a website owner has ten header bidding partners integrated, that user is going to see ten calls being made.  In a recent HubSpot survey, 39% of respondents that had installed an ad blocker cited doing so because ads created security concerns. By moving the calls server-side, we can present users a cleaner experience and potentially mitigate further adoption of something we can all agree is detrimental to the industry.

Here is how the server side model works:

serverside3

  1. Page loads, player loads, the header bidder mediator’s (HBM) code loads and fires the opportunity to its server.
  2. HBM sends the opportunity to other header bidder partners’ servers as well as to its own demand partners.
  3. Each HBP sends the opportunity to their demand partners.
  4. Upon receiving responses, HBPs and the mediator each conduct a server side auction, select a winner and send the winning ad back to the HBM. The HBM mediates the responses from each of the HBPs’ auctions and its own, on its server.
  5. HBM sends the winning ad back to its code on page.
  6. HBM’s code on page modifies the MVT with Key Value Pairs (KVPs) that instruct DFP on which line item to return.
  7. DFP executes its process to review the line items, including the one submitted by the HBM. DFP selects the final line item and sends it to the player, which plays the ad.

Interested in learning more about video header bidding? Check out our full suite of header bidding resources:

Leah_White_headshot

Insights from:

Leah Brite, Director, Product Marketing

GO BACK

Get News and Updates from SpotX

Sign up now to receive SpotX updates, news and product information from the leading minds in Ad Tech.