What is Video Header Bidding and How Does it Work?

Innovation can arise in many different ways. Sometimes it comes about as a result of years of research, and sometimes it evolves from a simple hack to solve a common problem. Header bidding is one example of the latter.

Header bidding first emerged as a way for publishers to receive bids on their display inventory from demand sources before ad calls were sent to their DFP ad server. The reason for this was to avoid the common situation where the DFP would favor bids from Google’s ad exchange (AdX), meaning non-Google demand sources would often miss out on bidding on or purchasing the publisher’s inventory, even though they were willing to pay more for it.

Since then, header bidding has morphed into a game changer for not only display advertising, but for video as well and as a result, has given rise to video header bidding.

What is Video Header Bidding?

Video header bidding is a process used by publishers to open up their video inventory to multiple demand sources (e.g. DSPs and ad networks via SSPs and ad exchanges) simultaneously. It is designed to eliminate the issues caused by the traditional waterfall method of selling inventory whereby a publisher’s video-ad server makes ad calls to different demand sources (typically ad networks) one after another, which not only causes latency but also reduces the publisher’s ability to maximize yield.

The concept behind video header bidding is the same as header bidding in display advertising, however the implementation process is quite different.

How is Video Header Bidding Implemented?

Just like with display header bidding, there are two variations of video header bidding: client-side and server-side.

Client-Side Video Header bidding

Below is a visual representation of what happens during client-side video header bidding:

The video player loads and the header-bidding wrapper (explained below) calls the three supply-side platforms (SSPs)/ad exchanges.
The SSPs/ad exchanges send the ad request to the demand sources (e.g. demand-side platforms [DSPs] and ad networks) and each of them place their bids on the available inventory.
The bids are sent to the header-bidding wrapper via the SSPs/ad exchanges. Each bid will be evaluated as long as they respond within the given timeout period set by the publisher, e.g. within 500ms.
The header-bidding wrapper then sends the highest bid (along with the ad markup), which in this case is $7.50 CPM, to the publisher’s ad server.
The publisher’s ad server then compares the winning bid against the bids from direct campaigns, private marketplace deals, and others. The highest bidder out of all of those is selected and the ad video file is sent to the video player and displayed to the user.

Server-Side Video Header Bidding

Below is a visual representation of what happens during server-side video header bidding:

The video player loads and the header-bidding wrapper sends an ad request to the server-side heading-bidding vendor.
The server-side heading-bidding vendor then sends off the ad request to multiple SSPs/ad exchanges, which in turn send the ad request to multiple demand sources (e.g. DSPs, ad networks).
The SSPs/ad exchanges return the highest bid along with the ad markup to the server-side header-bidding vendor, provided they haven’t timed out.
The server-side header-bidding vendor then sends the winning bid, which in this case was $6.25 from SSP/ad exchange #3, to the header-bidding wrapper.
The wrapper then sends the bid to the publisher’s ad server.
The publisher’s ad server then compares the winning bid against the bids from direct campaigns, private marketplace deals, and others. The highest bidder out of all of those is selected and the ad video file is sent to the video player and displayed to the user.

The main differences between these two types of implementation is the way ad requests are handled. With client-side header bidding, separate requests are sent to the SSPs/ad exchanges from the video player, whereas with server-side header bidding, a single request is sent to a server (i.e. the header-bidding vendor), which in turn sends requests to SSPs/ad exchanges.

No Header in Video Heading Bidding

“Header bidding” gets its name from the bidding process that occurs in a web page’s header — i.e. between the <head> </head> tags.

Video players don’t have header tags, however; the video player itself is typically just another piece of Javascript within the page. If the header-bidding solution is implemented properly, the bidding can take place in the web page’s header elements and then pass the winning bids into the video player. Such a situation is possible with Prebid.js (an open-source library for header bidding and an independent project incubated by AppNexus), but can only occur when the video player loads at the same time as the page.

What is a Header Bidding Wrapper?

A header-bidding wrapper is essentially the framework that implements all the logic used to carry out the heading-bidding process. Generally, each header-bidding partner would have a wrapper to handle its specific requests.

Wrappers allow publishers to:

Easily add and remove different header-bidding partners by enabling and disabling selected adapters in the wrapper.
Set a universal timeout for all header-bidding partners (e.g. 500ms).
Ensure that all bid requests are sent at the same time, which is accomplished with asynchronous code.

What are the Pros and Cons of Video Header Bidding?

The advantages and disadvantages of video header bidding are very similar to the ones found in display header bidding.

Advantages of Video Header Bidding

Maximized yield for publishers: If the figures for display header bidding are anything to go by, video CPMs could be improved by as much as 50 percent, and with video CPMs being priced higher than display ads, this could mean getting $16 CPM instead of $8 CPM. It’s also quite easy to add and test new SSPs/ad exchanges and remove them if they don’t perform well.

Enhanced reach for advertisers: One of the main benefits of header bidding for advertisers, compared to the waterfall, is that they now have a better chance of purchasing the impressions they want as all demand sources compete against one another at the same time.

As the waterfall method calls each demand source individually in sequential fashion, advertisers located lower down the waterfall may not be able to bid on the inventory at all, even though they want to pay a higher CPM than the advertisers located at the top of the waterfall.

This also benefits the publisher, as it is protected against potential losses due to the unavailability of a demand source. With the waterfall, if a demand source is unavailable (e.g. they time out), then it won’t be able to pass the next demand source’s ad tag to the ad server, meaning the ones located lower in the waterfall wouldn’t be able to bid on the inventory.

This is an example of the benefits of having asynchronous header-bidding code which simultaneously calls several demand sources to fill the inventory/video-ad placement.

Disadvantages of Video Header Bidding

Data leakage: Even though video header bidding allows publishers to offer all their available inventory to numerous demand sources at once, the main drawback of this is the user’s data is shared with all demand sources. In the waterfall method, if the first demand source purchases 50 percent of the available inventory, then the next demand source in the waterfall would only get data on the 50 percent that’s remaining.

In addition, header bidding allows all demand sources to see how much programmatic video inventory a publisher has and even capture the audience, meaning an advertiser could target the same audience on some low-quality sites but still reach the same audience that they would on a premium publisher’s site. That’s obviously a potential big loss for the premium publisher.

Transparency: The transparency issue with video header bidding relates mainly to the server-side implementation and is twofold. Firstly, advertisers have no way to inspect whether there’s any bias towards certain demand sources. Secondly, advertisers don’t know for certain whether the price they pay for inventory is the same price received by the publisher, or whether the publisher or header-bidding vendor is taking a cut.

Latency: Slow load times are a big problem for video in general, but this can be amplified by making multiple ad calls either within the page’s header or within the video player itself. However, latency can be mitigated in a few ways, for example, by sending out ad calls straight away instead of waiting for the user to click on the play button (which is what usually happens with video ad calls) or by taking the whole header-bidding process server side.

Why Aren’t All Publishers Implementing Header Bidding for Video?

Despite all the benefits and potential that header bidding for video encompasses, there are a couple of things to keep in mind regarding adoption:

1. Video Inventory is Somewhat Scarce

Unlike display, video inventory is somewhat scarce. There simply isn’t that much video inventory around to warrant a technological and strategical shift from the current video-buying methods, which is mainly direct private marketplace (PMP) deals. However, this will certainly change over the coming years as more publishers move towards in-stream and out-stream video ads, which offer higher CPMs to display ads.

2. Technical Challenges

In an attempt to reduce latency, many publishers and header-bidding vendors have created wrappers, which are essentially containers that manage all the demand sources.

However, some wrappers are custom built, meaning their implementation differs from one wrapper to the next, and most only work with certain providers. This requires a bit more hands-on work when adding new demand sources, but there is a solution to this problem — Prebid.

Each SSP/ad exchange that offers video inventory creates its own adapter for Prebid and the publisher can easily enable it in Prebid without much work. However, Prebid only rolled out the video support a few months ago and is still lacking adapters for many popular demand sources.

Also, the nature of video advertising, and video in general, is much more complex than display advertising. For example, there are many different types of video players (e.g. Video.js, JW Player, Brightcove, Cedato, Ooyala, and many others), video ad formats and standards (e.g. VAST, VPAID 2.0, VPAID 3.0, MRAID, etc.) for video ad serving and event tracking that needs to be supported.

Video Header-Bidding Vendors

Below are some of the main video header-bidding vendors on the market. Some of them have partnered with Prebid.js, while others have built their own solutions and wrappers:

Final Thoughts

As it is with Ad Tech, two things are for sure:

Video header bidding will require some compromise (e.g. reduced latency and more demand sources for less transparency).
Even though a couple publishers and Ad Tech vendors have already started experimenting with video header bidding, most publishers and advertisers will take a wait-and-see approach, as they always seem to do when innovation is knocking at the door.

What is Video Header Bidding and How Does it Work?

Contents

What is Video Header Bidding?