Back in the early days of the Internet, when an advertiser wanted to buy ad space on a publisher’s website, they would call up the publisher’s sales team to make the purchase.
While the direct advertiser-publisher relationship is still around, the introduction and growth of technology has added speed, efficiency, and scale to the online media buying and selling process.
As the number of technology platforms has increased, so too has the number of processes; and one process gaining traction in the ad-tech world is header bidding.
What is Header Bidding?
Header bidding (aka pre-bidding, advance bidding, and holistic yield management) is a process that enables publishers to simultaneously collect multiple bids from a number of demand sources (not only from their ad server) on all of their ad inventory prior to a sale.
This process allows publishers to “see” which demand sources (e.g. demand-side platforms [DSPs] and ad networks connected to ad exchanges and supply-side platforms [SSPs]) are placing the bids and the monetary value of their bids (e.g. $1.05), allowing them to get the highest cost per mille (CPM) possible. As bids are received before a publisher’s ad server is called, they are able to compete with a publisher’s premium deals, meaning advertisers have a better chance of winning the impression and publishers earn more money for their inventory.
How Did Header Bidding Come About?
AdTech vendors developed header bidding to enable publishers to collect bids on their inventory from demand sources before the ad call was sent to their DoubleClick for Publishers (DFP) ad server. The reason for this was to avoid the common situation where the DFP, which is used by a large majority of publishers, favored bids from the Google 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.
Header bidding has also, somewhat accidentally, replaced waterfall auctions.
A waterfall auction is a structured process for selling inventory handled by the publisher’s ad server, which would sell the available inventory to potential buyers in a sequential fashion.
Typically, the ad server would offer the inventory to premium buyers (e.g. guaranteed buys, direct sales made between the publisher’s sales team and the advertiser, and sponsorships). If the premium buyers failed to purchase all of the available inventory, the ad server would approach the next potential buyer (e.g. an ad network) with the aim of selling the remaining available inventory, known as remnant inventory.
The ad server would continue contacting various demand sources until all of the available inventory was sold. In the event the available inventory wasn’t sold, the publisher could display in-house ads (ads promoting their own products or services).
How Does Header Bidding Work?
From that moment on, each time a page loads, the demand sources (e.g. ad networks and buyers connected to supply-side platforms [SSPs] and ad exchanges) will be able to bid on each impression on that page, even if some or all of the inventory had already been sold through direct buys between an advertiser and the publisher.
A Step-by-Step Explanation of How Header Bidding Works
Here’s how the header-bidding process works from the moment a page loads on a publisher’s website to the time the available inventory is sold:
Here’s what is happening in the image above:
- A user opens their web browser and types in the publisher’s URL (e.g. publisher-abc.com).
- The browser starts loading the page.
- Bids from various sources start coming in.
- The highest bidder wins and the ad is served (i.e. displayed on the page).
As you can see in the diagram, the speed at which bids are placed varies. This latency not only means some demand sources may not be able to place a bid due to being timed out, but also results in the page taking longer to load. The timeout rates vary and are different on desktop and mobile. With desktop, the timeout range is 400–800 milliseconds; with mobile, it’s 800–1,200 milliseconds.
The process described in the image above is an example of client-side header bidding (CSHB), but there is also a server-side implementation.
What is Server-Side Header Bidding?
Server-side header bidding (SSHB) follows a similar process like the client-side implementation, but instead of sending the ad requests from the browser directly to the various AdTech platforms, server-side heading bidding sends the ad requests from the browser to a dedicated server. Then, the server sends the ad requests to different exchanges, SSPs, and DSPs. Once the server has received the bids, it then sends them back to the browser and on to the publisher’s ad server.
Here’s how the server-side implementation of header bidding works:
The Main Advantage of Server-Side Header Bidding
The main advantage of server-side header bidding is a reduction in page latency.
As all of the bidding happens outside of the browser in a dedicated server, the browser is able to render all the other parts of the page without being bogged down with multiples ad requests — resulting in a better user experience.
The Main Disadvantages of Server-Side Header Bidding
Despite the improvements in the user experience, server-side header bidding does come with a few disadvantages. The main ones being:
- A lack of transparency — as the bidding happens in a server, it can be hard for publishers and advertisers to see the details of the auctions, meaning they don’t know the true cost of the impressions, what auction type was used (e.g. first- or second-price auction), and how many fees were added on top.
- Bid latency — even though SSHB reduces page latency, the same cannot always be said for bid latency. Some bids may not be able to respond to the ad requests in time because of the extra step involved in SSHB (i.e. sending ad requests to the server first and then on the supply and demand sources, rather than sending them directly from the browser).
- Cookie match rates — because SSHB moves the bidding process off the page, cookies can be lost. This not only makes it hard for advertisers to identify users, but also means they may need to sync cookies, which can be a rather error-prone process.
- Technical complexity — setting up, configuring, and managing a server-side header bidding connection is much more complex for the header-bidding vendor and the platforms that use it.
It’s important to note that while the header-bidding process is nothing new — it’s been around for about 10 years — it really started to take off in 2014 and 2015 with the help of programmatic media buying. In fact, according to Tom Shields, the SVP of Publisher Strategy at AppNexus, around 70% of major publishers use header bidding in their programmatic sales process.
In-App Header Bidding
Header bidding is currently making its way to various new platforms as more and more companies make their foray into the modern, faster bidding method. Platforms that already offer in-app header bidding include Google AdMob, Amazon, Oath, MoPub, and Facebook, who, although a little late to the party, made a lot of headlines with the long-awaited announcement.
Technically speaking, header bidding has grown to become a slight misnomer today as mobile apps don’t have a header per se – but the core idea remains unchanged. Bids are simultaneously solicited from multiple demand partners before a call to the ad server is made.
Following up the introduction of header bidding to mobile web in 2017, Facebook is currently implementing header bidding in their mobile apps. Just like in the former case, the company did not decide to build their own technology solution to support it, and implemented header bidding through their partners MoPub, Fyber and MAX. There is no need to reinvent the wheel really and companies like Facebook may not want to add another piece of technology to the already populated AdTech landscape. Instead of competing in the AdTech area, the social and data mogul can focus on their fortes: data and demand. For many companies getting on board with header bidding is more like updating the technology to build stronger ties with publisher partners.
The Future of In-App Header Bidding?
The departure from traditional bidding methods is slower than expected with in-app compared to traditional display in browsers. The bidding El Dorado – a situation where auctions are fair, transparent, and the only factor determining the winning bid is the bid itself – is a noble concept, but we’re not quite there yet.
A 2018 study by InMobi reveals that among the reasons for the slow implementation of in-app header bidding companies cite limited understanding of the technology, implementation issues, and a disproportion between programmatic and direct deals.
In-app header bidding is a step forward by all means, but the industry is not quite ready yet – header bidding makes up only a small percentage of total inventory and the situation isn’t very likely to change very soon.
The introduction of header bidding has changed the game of online advertising and brought with it a number of advantages for publishers and advertisers alike. However, just like with most new inventions, it still faces a number of challenges. Thankfully, innovation is a constant force in the online advertising technology ecosystem and AdTech companies over the next few years will no doubt be working on ironing out some of these kinks.