Let’s be clear, client-side header bidding is dead on arrival for video. Its 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:
- 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.
- HBPs send the opportunity to their demand partners.
- Upon receiving responses, HBPs conduct server side auctions, select winners and send the winning ads back to the HBC.
- 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.
- DFP determines the final line item to serve and sends the corresponding line item to the player, which plays the ad.
- 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:
- Page loads, player loads, the header bidder mediator’s (HBM) code loads and fires the opportunity to its server.
- HBM sends the opportunity to other header bidder partners’ servers as well as to its own demand partners.
- Each HBP sends the opportunity to their demand partners.
- 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.
- HBM sends the winning ad back to its code on page.
- HBM’s code on page modifies the MVT with Key Value Pairs (KVPs) that instruct DFP on which line item to return.
- 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? Stay tuned. Next week we’ll dive into why you shouldn’t be using header bidding in video advertising.
Leah Brite, Director, Product Marketing