What is Header Bidding?
Header bidding is an automated way for publishers to offer ad inventory to multiple sources simultaneously. This allows publishers to pitch multiple buyers against one another without the delays and inefficiencies this would normally involve through VAST tags using a Waterfall approach.
To understand the benefits of header bidding, consider the most common approach to selling digital inventory. First, the site reaches out to its ad server. After the site connects to its ad server, it will usually try to assign the inventory through a waterfall approach, meaning it offers it to the (theoretically) most profitable source first, then the next most profitable source, and so on. The key is that it sells the inventory as soon as it finds a matching source. If there’s any inventory that wasn't sold, the site can pass it on to another ad exchange, and the process begins again.
Header bidding adds a new step before this process. It’s triggered by a simple javascript code in the header section of the page, hence the name. When a page is loaded, it reaches out to multiple SSPs and ad exchanges and lets them compete against one another, creating a programmatic auction. Depending on the chosen set-up, the highest bid can be accepted or held back to compare with other sources such as direct sales by the site.
Why Publishers Should Use Header Bidding
The traditional Waterfall approach’s biggest flaw is that it’s very possible an ad will sell at one price to a “historically more profitable” source when it would actually have attained a higher price from a “historically less profitable” source further down the waterfall. That’s largely because different sources are ranked by past average performance, which can be crude and inaccurate for predicting a specific sale for any given impression.
Waterfall also has a big problem that’s particularly relevant to video publishers. Even if everything works smoothly, checking in with multiple exchanges and sources in sequence can take hundreds of extra milliseconds until an ad is finally delivered. In addition, if any one source glitches or times out, the entire process can slow down or even stall.
Both problems create delays that may seem minor for a web page as a whole, but are particularly noticeable when the code is embedded in a video player. This can cause an irritating delay in playback, a lag that is quite noticeable to the user waiting for the ad.
How is Video Header Bidding Implemented?
Most ways of using header bidding fall into two main categories: client-side and server-side.
Client-Side Video Header Bidding
As the name suggests, the client-side approach means the code in the page header does all the work. The main advantage is that the publisher can set the code up to contact a precise range of ad exchanges and other sources, with minimum technical barriers. It’s widely supported so an ad exchange or SSP that supports header bidding, also supports client-side header bidding.
The main disadvantage is that the precise control offered by client-side may require more complex coding and maintenance. Some ways around this are to use pre-made open source “wrappers” such as Prebid.js to handle the code, or to use video players which have built-in client-side header bidding functionality that can simplify the implementation. At Primis we have this capability implemented onto our proprietary video player.
Server-Side Video Header Bidding
Server-Side (also called S2S) means the header code for the bidding does nothing more than pass on the relevant details to an external server, which then does the heavy lifting of contacting all the SSPs\exchanges and finding the highest bid.
As soon as the header code sends the request, the page itself can begin loading without any noticeable lag for the user. That works particularly well for publishers who want to offer inventory to a wide range of sources and exchanges. Doing it this way avoids the situation with client-side bidding where publishers face a trade-off between waiting for more bid responses and imposing a time-out limit to avoid lag on page loading.
Important to mention, the S2S integration approach will have additional costs, since you will have to use an external provider for this solution. Although, with this approach you will be able to parallel call more partners compared to Client Side integration, but the additional costs may harm your overall profit.
Another possible approach for S2S video header bidding is Google’s Exchange Bidding (EBDA). In most cases, publishers are using Google Ad Manager as their ad server, which is already integrated into all of the major SSPs\exchanges in the industry. The advantage of this approach is that there is no need for additional on-page implementation since the site is already connected to the ad server, hence to Google’s demand partners.
The main differences between these two types of implementation is the way ad requests are being sent and handheld. Through a client-side header bidding, separate requests are sent to the SSPs/ad exchanges from the video player, while with server-side header bidding, a single request is sent to a single server ,which in turn sends requests to SSPs/ad exchanges.
What Our Numbers Say
After numerous case studies we’ve conducted at Primis, when pre bid integration is an option, we came to the conclusion that Client Side approach is preferred.
This whole process might seem overwhelming, but with the Primis video unit it’s all integrated and automated. Our product takes the benefits of header bidding that the industry has found valuable for other types of advertising for years and seamlessly integrates it into the video medium.
