Ever experienced the thrill of an auction? For some people, auctions are like sports. They can be a hobby or a way of life. The room quickly fills with different people looking to compete and bid on priceless works of art, classic cars, coins or maybe mystery objects they absolutely don’t need and probably don’t have room for. In Ad-Tech, auctions are a bit different. While they don’t include rooms filled with people, memorabilia or expensive collections, for publishers and advertisers they are just as exciting as they have the power to determine both viewability and revenue.
This article will review header bidding, the popular” auction” method on desktop and will discuss the future of in-app header bidding.
What in the world is header bidding?
Let’s talk a little about what header bidding really means. If we simplify it, header bidding is just a few lines of code that goes in (you guessed it) the header of a web page. That same code allows publishers to present their inventory to various ad exchanges at the same time. By allowing different sources to bid on the inventory at the same time publishers increase their revenue potential.
As far as mobile web advertising, header bidding has made a substantial difference. According to Facebook, approximately 70% of web publishers serve ads through header bidding. While header bidding revolutionized desktop, in-app advertising pretty much stayed behind. Today, in-app advertising still works according to the waterfall system.
Don’t go chasing waterfalls
The Waterfall was created out of publishers needs to sell all of their ad slots. The goal was/is to help publishers increase their fill rates and maximize their revenue.
How does it work?
Because direct sales usually provide the highest CPM, it is publishers first choice when it comes to selling their inventory. However, if they cannot, the impression will move to the waterfall which includes various ad networks. The publisher decides which ad-network will be approached first, usually based on the historical yield meaning how much money this ad-network has made the publisher per geo in a specific period. If the first ad-network can’t meet the request the impression will pass through the waterfall until it is sold.
The system work but has a variety of issues.
Waterfall leaks water everywhere
- Things change. Just because one ad-network performed well for a time being doesn’t mean it should always be the first choice.
- It doesn’t always take the publishers needs into consideration. Historical yield does not mean the ad-network will supply the best results. What if another ad-network is interested in bidding higher for this specific impression?
- The waterfall can often cause slow loading time causing poor user experience.
- Dynamic filling with AdX (DFP) and other in-house ads, eventually the ad server will fill the impression from it own exchange (AdX in the case of DFP) in one cent above the waterfall slot. If the publisher left gaps in the slots (or added a slot per each cent), it will loose money.
The waterfalls disadvantages and inefficiency led to the introduction of header bidding on desktop. Currently, App publishers are still stuck with “chasing waterfalls.”
As mentioned above the waterfall system isn’t perfect. Not that header bidding always is but, it is pretty awesome. Header bidding creates healthy competition from direct demand by generating an auction for each impression. Thanks to header bidding, publishers don’t have to settle for what the waterfall has to offer, they can always choose the highest bid per impression.
Heads up! In-app header bidding is on its way
By now it’s clear. Header bidding for desktop = good. Header bidding for in-app = almost non-existent so publishers settle for the waterfall. Fortunately, we are starting to hear more and more talk of header bidding migrating to in-app. Appnext recently released in-app header bidding. By updating the new SDK version app publishers can maximize yield for each ad request, by letting them serve the highest real-time bid, as opposed to relying on the Waterfall and average historical eCPM bidding.
In order for in-app header bidding to succeed or have a chance of succeeding developers must be open to trying new tools that require the implementation of an SDK. Let’s face it, it’s not the end of the world, just a little more effort and code that could very well revolutionize in-app advertising the same way it did desktop.
Now close your eyes. Imagine that you are attending an auction. You are in a room with hundreds of other publishers. You can either have an option to choose five-set ad-networks that may or may not deliver the desired eCPM OR, you can have various ad networks compete to serve your request and maximize revenue. Which do you choose?
Comments are closed.