What is a Header Bidding?
Header Bidding (also called as pre-bidding) is a real-time bidding technique where the publishers simultaneously call multiple DSPs/advertisers to bid on their inventory. This helps publishers boost their revenue and also have a fair competition in the auction. This is good for advertisers too because they get to bid higher on the ad space that they like and have a possibility to win an auction. Let me sketch that for you:
- Sam visits a publisher’s site.
- The header tag on the site communicates with the supply-side platforms(SSPs) that the publisher is connected to.
- The SSPs simultaneously call multiple demand-side platforms(DSP) for an auction via an ad exchange to bid on the ad slots.
- DSPs send bids to the SSP via an ad exchange
- The winning bid i.e, the highest bid is determined and communicated to SSP.
- The winning bid’s ad creative is pushed to SSP.
- The creative is sent to the publisher’s ad server.
Wait, Isn’t this how an auction works?
Enter Waterfall Bidding
Yes, but not quite. Before the emergence of header bidding, Waterfall/daisy chain bidding technique was widely implemented. To understand why the header bidding dynamics are better, let us walkthrough the waterfall bidding process. The digital publishers faced the issue of low fill rate even after the sales team worked over hours to sell all the inventory. To help publishers solve this problem, programmatic buying was proposed as a solution to sell remnant inventory. The bidding technique that was used was waterfall technique where the bidding was done in a sequential fashion. Time for another sketch, shall we?
Sam is a 40-year-old financial partner at a famous firm with an income of $400K/year. He visits examplesite.com. Here is what happens while the page is being loaded.
- Financialtimes.com informs the SSP about the available ad slot.
- The SSP informs the ad exchange and calls for an auction with a floor price of $1.5.
- The demand-side platform A-F are ranked based on the past data of yield. The more inventory the advertiser buys from Financial times, the higher the rank/priority.
- DSP A does not bid as it does not have any matching advertiser as Sam does not belong to any of the demographic groups.
- The Demand side platform B, C, D, E, F bid $1.8, $2.00, $2.6, $2.2, $1.6 in the specified order.
- DSP B has been the second major advertiser at Financial times. They have bought maximum inventory and have a higher priority.
- DSP B wins the bid and despite the higher bid, other DSPs loose the auction.
- Sam sees an ad from DSP B.
Okay, Tell me more!
There are 2 types of Header Bidding:
- Browser side also called client side header bidding
- Server side Header Bidding
Client Side or Browser Side Header Bidding
In the browser side header bidding process, the header tag sends request to ad exchanges/DSPs to bid for an inventory. Although the publishers have higher transparency in this process, they do have to compromise on the page latency. The SSP needs to wait to receive multiple bids before showing the ad. To tackle this issue, publishers use time out and asynchronous loading of web content
Server Side Header Bidding
There is not much of a difference here in the mechanics that a server is sitting between the header tag and the ad exchange. However, transparency is a bigger issue here. The publishers do not really know if the server is being transparent with the pricing or adding a % of commission on top. The selling point of server-side header bidding is that that page latency is reduced as the tag passes one request to the server and the server handles the bidding.
Oh well, Header Bidding Sounds Perfect. Why aren’t publishers using it already?
Yes, that’s correct. However, publishers need to consider a lot of points during the implementation.
Drawbacks of Header Bidding
Shoots up Page Load Time a.k.a page latency
As the header tag has to wait for multiple DSP to pass the bid, it increases the page load time. This could shoo away the users and have a detrimental effect on the revenue.
Browser Compatibility Issues
The header tag sends requests for multiple DSPs to bid on their inventory simultaneously. This means that it has to be compatible with multiple browsers to receive the bids.
Loss of Data
As some browsers like Mozilla and Safari block tracking pixels, this could lead to loss of data.
Although header bidding is not a “new”concept, some publishers are not so open to experiment with it as it requires their ad operations team to amend the site code. They would rather let others try out first than be the first movers.
Wow a lot of points to note. Is it worth all the hassle?
Let’s find out…
Advantages of Header Bidding
Using header bidding, publishers can earn more revenue as compared to waterfall bidding. As multiple DSPs are called for an auction simultaneously and the highest bid wins in an auction, publishers can get more money for their inventory.
No “Google” Factor, a fair Auction
In waterfall bidding, the DSPs are ranked based on their historic yield. Google almost always has the upper hand and ends up winning the auction. Using header bidding is the way for a fair auction to give other DSPs a chance.
Advertisers can now access premium inventory
As header bidding is a pre-bid process, advertisers now have the chance to get access to premium inventory. The publisher ad server can compare the winning bid to the guaranteed deals to serve the ad that pays the best for the publisher. It is a win-win.
Leave no inventory unsold. Higher Fill Rate
Header bidding aids higher fill rate for the publishers. Calling multiple DSPs to participate for an auction at once in a synchronous fashion leads to a higher probability to sell maximum inventory possible.
Better Pricing Strategy
Now that the publisher knows how much an ad space is worth in the market, they can price the inventory based on a data driven approach.
Yep totally worth it! The Ad operations team keeps mentioning about Header Wrapper. What’s this?
Without this, the publishers have to make multiple code amendments to accomplish the above tasks.
Btw I have an app, is it different for an in-app inventory?
Yes, the dynamics of in-app advertising is completely different. Even though the publishers can easily replicate the process in the mobile browser, it is a different implementation in the mobile app environment. First off there is no actual “header”, hence it is referred to as ‘mobile bidding’ and sometimes as unified auction/advanced bidding.
Using advanced bidding in the app would require the publisher to add multiple SDKs which could potentially slow down the app. However, there are quite the number of providers like Mopub who are offering a solution to this problem for the publishers. It is still in the nascent stage for adoption at the moment.
Last Question: How Do I get Started?
The pros of header bidding definitely outweighs the cons and to get started with the header bidding you could use a list of providers that can offer header bidding solutions like OpenX, Adbutler, Adpushup and more.
Do not take anything for granted and launch a pilot project to test out the providers first. Once you find out what works for you, you can scale it up. Happy Testing 😉