Before the advent of header bidding, the traditional way to connect video advertising inventory to programmatic demand was to use a series of VAST tags in a waterfall configuration. The capability to waterfall VAST tags is built into almost every video player.
The waterfall method, however, has main two disadvantages that header bidding avoids. The first is latency. By calling one provider at a time, the latency inherently is higher. Because these calls are happening from a web browser, 500 milliseconds per call is a good estimate. Which means to go through three providers, we are looking at ~1.5 seconds. Since this waterfall process often doesn’t start until video starts playing, this lag is quite noticeable to the consumer waiting for the ad.
The second issue with waterfall is lower yield. In waterfall, the demand partner who performs best, on average, is called first. Yet, for any given impression, another demand partner who is lower down the stack may have the highest bid. In a waterfall set-up, those partners may never be called if the partners above them in the stack fill. This means the publisher has lower than optimal yield.
Header bidding solves this problem by calling all demand partners simultaneously. Latency is also minimized because the calls happen in parallel, and because bids from all demand partners are considered for every impression, thus optimal yield is achieved.
Client-Side Video Header Bidding
Conceptually, header bidding calls to demand partners happen in parallel. However, in practice the reality is bit more nuanced as the web browser will only allow a limited number of outbound calls at a time.
Web browser limits become more important as the number of desired calls increases. In addition to competing with each other, network connections to solicit bids also compete with the webpage loading non-advertising content which can slow down the whole experience.
The most common “flavor” or instance of video header bidding is client-side header bidding. With client-side, there’s JavaScript on the web page that calls out to each demand partner.
Using client-side header bidding has advantages. It’s widely supported thus any SSP or ad exchange that supports header bidding, supports client-side header bidding. Client-side bidding also typically has higher cookie match rates than alternatives.
The most popular client-side header wrapper for video is Prebid.js which is an open source wrapper. Some video players, such as JW Player, have built-in client-side header bidding functionality which can simplify implementation.
The alternative to client-side header bidding is server-side header bidding. With server-side header bidding, there’s one network call from the web page to a server. Computing and network resources are greater on a server than a web browser so the server component can call multiple demand partners very quickly.
Server-to-Server Video Header Bidding Options
Server-to-Server (S2S) header bidding for video comes in multiple flavors and each has unique pros and cons. One flavor is an extension of client-side header bidding. The JavaScript wrapper on the page calls one server rather than each demand partner. The server will then call each individual demand partner, sending one or more bids back to the client-side wrapper. With S2S, it’s possible to run a hybrid setup where some demand partners are called client-side and others server-side. Prebid Server, used in conjunction with Prebid.js is an example of this type of setup.
This differs from a client-side wrapper from an implementation standpoint as the server-side component needs to be hosted by either the publisher or a vendor.
A second flavor of video header bidding is Google’s Exchange Bidding (EB). With EB, the header calls to the demand partner are run from behind the ad server, Google Ad Manager. The advantage of this approach is that no additional on-page implementation is needed since the website is already connected to the ad server.
The third approach for video header bidding uses a single client-side VAST tag, which any video player can directly call, and in turn header calls are made by the server. Because the protocol for fetching and delivering video ads is standardized by the VAST protocol—and VAST is almost universally adopted by video players which support advertising—header bidding using a VAST tag is a reliable option. This option doesn’t exist for display because there’s no standardization of how display ads are fetched from web pages.
The VAST approach is much simpler to implement than using client-side bidding, or client code plus server approach, because there is no code that needs to be added on the page beyond a simple tag for user syncing. Additionally, many video players have a UI for configuring VAST tags. The combination of a player with a UI for managing VAST tags and header VAST tags simplifies implementation, particularly when using mid-roll or post-roll video ad units. For reference, PubMatic’s OpenWrap Video is implemented using a VAST tag.
The header bidding through VAST approach has the advantage that it works for both web and mobile in-app. For in-app, there’s no need to implement an additional SDK to support video header bidding as the header bidding VAST tag can be added to the existing monetization stack in the app. For publishers, running a waterfall today for video, using VAST tag video header bidding is an easy and low risk way to boost yield without needing to completely overhaul their ad stack.
Choosing an Approach
Given the myriad of options, figuring out which approach to use can be daunting. PubMatic’s expert customer success team provides a consultative approach to help publishers determine their optimal set-up. Here are some key considerations for publishers getting started with video header biding.
First, publishers should consider whether they have an existing player they want to keep using. If a publisher is thinking about a change, consider a video player with built-in header bidding support.
For publishers looking for fast implementation requiring minimal engineering resources, a VAST tag-based approach or Exchange Bidding are good options. If a publisher is looking for maximum flexibility and control, plus have development resources available, Prebid.js is a strong contender.
What’s Next?
To learn more about PubMatic’s video header bidding capabilities, check out our solutions page or contact us.
