What is Header Bidding? How Header Bidding Improves on RTB

Read time: 8 minutes

Digital advertising is characterized by frequent developments that seek to overcome the challenges presented by its previous advancements.

One of the more recent and trending ad tech (advertising technology) developments is header bidding.

Nearly 80% of the internet’s most popular websites that sell programmatic ads have implemented the header bidding technique, up from 70% a few years ago.

This guide reviews how header bidding works and how it improves RTB (real-time bidding).

Table of Contents

What is header bidding?

Header bidding, also referred to as “pre-bidding” or “advanced bidding”, is a programmatic advertising technique which allows publishers to put their available ad space impressions (also referred to as “ad inventory”) up for auction across multiple demand sources at once.

A “demand source” is simply a platform that allows advertisers (the ones generating the “demand” for ad space) to place bids and purchase ad impressions from publishers.

In the context of header bidding, ad exchanges are the most common demand source.

Because bids from multiple demand sources can be placed on their ad inventory at the same time, publishers are able to maximize their revenue by increasing ad space competition, raising average bid prices, and performing optimisations like seeking the best ad network payout from various channels.

The exact date of header bidding’s origin is somewhat disputed.

While multiple variants were introduced at around the same time as RTB in 2009, header bidding didn’t gain an identity for itself and attract mainstream usage until around 2014-2017.

How did programmatic advertising work before header bidding?

RTB’s introduction was the first time that publishers could auction their ad impressions on an impression-by-impression basis through demand sources.

After several years however, it became clear that improvements were possible, as auctions could only be run through a single demand source at a time.

Every ad tech process is connected to the entire programmatic ecosystem.

This means that replacing the “components” that are already used by everyone is a nearly impossible task.

This puts ad tech in an awkward situation where new “patch work” solutions must be built on top of existing processes to improve them, rather than redesigning the system as a whole.

The history of digital advertising is filled with situations like these.

To provide a concise ad tech history example as it relates to header bidding:

  • Ad exchanges were developed in 2005 to automate ad buying and selling
  • RTB was developed in 2009 to improve the way auctions worked on ad exchanges
  • Header bidding was developed in around 2014-2017 to improve RTB auctions

It may sound rudimentary to be able to connect and scan advertiser’s bids from multiple demand sources at once – but the limitations of RTB historically prevented this functionality.

Header bidding vs RTB

From its onset, RTB was designed to improve ad exchanges by allowing their automated processes to operate on an impression-by-impression basis.

This linked guide covers how the RTB process works.

Header bidding is a technique developed to improve the performance of RTB.

Header bidding takes the RTB process one step further by allowing an ad impression to be put up for auction across multiple demand sources at the same time, instead of running the auction through each demand source one at a time (a process referred to as “waterfalling”).

Header bidding vs waterfall

In programmatic advertising, waterfalling (also sometimes called “the waterfall” or “the daisy-chain”) refers to the bidding system that RTB historically used to manage auctions.

Waterfalling is the process of running a complete auction for an available ad impression through multiple demand sources, using a single demand source at a time.

In the absence of an advertiser’s bid meeting the price floor (the minimum bid amount set by the publisher) for the ad impression, the auction is run again on a different demand source in an attempt to find a qualifying bid.

A publisher’s “waterfall” refers to the order in which they’d like to prioritize the demand sources through which the auctions will be run.

Traditionally, RTB exclusively relied on waterfalling to carry out its bidding processes.

This practice changed with the introduction of header bidding.

This is because waterfalling causes publishers to miss out on potential revenue.

This example demonstrates why:

  • A publisher has a waterfall consisting of 3 ad exchanges, prioritized in this order:
    • Google AdX (formerly DoubleClick Ad Exchange)
    • Xandr (formerly AppNexus)
    • Magnite (formerly RubiconProject)
  • The publisher sets a $2.00 CPM price floor for their ad impressions.
  • A user visits a page on the publisher’s website that has available ad space.
  • An auction is run on Google AdX (the first exchange in the waterfall).
  • A $2.25 CPM bid is placed for the impression, and accepted as the clearing price.
  • Hooray! The publisher celebrates their earnings!…
  • …but the publisher remains unaware that an advertiser on Magnite was willing to place a CPM $3.00 bid for the same ad impression – an auction which didn’t have a chance to run because of the waterfall’s priority.

In the example above, a header bidding configuration allows the auction on Magnite to take place at the same time as Google AdX and Xandr – meaning the highest bid can be secured.

How does header bidding work?

As header bidding’s alternate names (“pre-bidding” or “advanced bidding”) suggest, in a header bidding configuration, auctions for ad impressions are initiated by using a “pre-bidding” process in “advance” of the standard RTB process.

When a user visits a web page, the header bidding process is initiated, signalling that an ad impression is available to each of the demand sources that the publisher specifies.

The header bidding process occurs before the standard RTB process is initiated, meaning that a publisher’s ad server will only signal an ad impression’s availability to its “fallback” demand sources in the event that no qualifying bids are received for an ad impression via the header bidding auctions.

As the name suggests, “header bidding” requires the placement of a code snippet (or “tag” or “code block”) into the header section of a website’s HTML code.

These code snippets are frequently referred to as “wrappers”.

What is a header bidding wrapper?

A “header bidding wrapper” refers to the piece of JavaScript code that’s placed in the header of a publisher’s web pages, allowing the page to communicate with the demand sources specified in the code.

Header bidding wrappers are frequently described as “containers”.

They allow publishers to “store” a list of demand partners within them, as well as configure rules that determine how auctions should be conducted (for instance, the bid floor price, and how long demand sources have to conclude their auction processes before considering them “timed out”).

Once a publisher’s wrapper is configured, a simplified header bidding process works something like this:

  • A user arrives at a publisher’s content. As the website begins loading the page’s content, the header bidding wrapper, being located at the “top” of the page (in the header section of the HTML) is one of the first pieces of code to be called.
  • Because it’s called first, the header bidding wrapper is able to pause all of the page’s other ad server tags, inhibiting the standard RTB process from initiating, and instead signaling to all SSPs included in the wrapper that an ad impression is available.
  • The ad impression is forwarded to the corresponding demand sources, which conduct their own RTB processes, and return the bids to the header bidding wrapper.
  • The winning bid is established and sent to the publisher’s ad server (in some configurations, the ad server itself determines the winning bid).
  • The winning bid is then evaluated against any other active programmatic deals the publisher may have. The winning bid along with the winning advertiser’s ad creative (the ad itself) is displayed, assuming that none of the publishers other existing deals are more lucrative (and, assuming that the impression isn’t guaranteed/reserved for another advertiser).

Benefits and challenges of header bidding

Part of header bidding’s high rate of adoption comes from the wide range of benefits it offers to the programmatic ecosystem as a whole.

Benefits of header bidding include:

  • Selecting participants. Publishers are able to configure which platforms they want to work with – allowing them to retain the benefits of a waterfall configuration while avoiding potential revenue loss associated with the traditional RTB technique.
  • First-price auctions. Many demand source ecosystems promote the use of first-price bidding models in header bidding configurations, meaning publishers stand to generate more revenue from the increased competition between advertisers.
  • Faster page loading times. When compared to the waterfall method, which traditionally caused page loading latency, header bidding is capable of reducing the time needed to conclude auctions and display ad creatives on a web page.
  • Process transparency. Advertisers are able to review information about a publisher’s overall ad inventory profile. All impressions are run through connected demand sources, even if they end up unsold or being reserved for an exclusive deal.

Despite its numerous advantages, header bidding isn’t all sunshine and rainbows (this is ad tech, after all). There are a few obligatory rain clouds that are certainly worth consideration.

Challenges associated with header bidding include:

  • Implementation. Due to the necessity of configuring the wrapper, elements like prebid adapters, and ensuring that the installation is compatible with any existing ad server configurations, it can be a challenge to start using the technique without a dedicated header bidding solution.
  • Page loading times. Wrapper configurations that include too many SSP tags can end up lowering page performance. This leads to publishers needing to choose between client-side and server-side header bidding installation methods.
  • Security and authenticity risks. While header bidding provides transparency, the same benefit can be used maliciously in some cases. A level of technical prowess and vigilance is required to ensure that demand sources don’t end up leaking customer data, and that fraudulent ad activity doesn’t become an issue (of course situations like these are outliers, or header bidding wouldn’t be as popular as it is – though they’re worth having on your ad tech radar when planning your strategy).

Leveraging header bidding in your business

As an immensely popular and effective technique for increasing ad revenue, header bidding should be high on a publisher’s list of methods for optimizing their ad tech stack.

Due to the complexity of its implementation, an ad serving tool that offers a header bidding solution with ongoing support is helpful for navigating the initial setup process.

Consulting an expert for free is a great way to save time and future-proof your strategy.

The AdButler team has over two decades of experience in helping publishers and advertisers to configure and connect their ad servers to diverse programmatic solutions.

We’d love to share a conversation with you. Ask us a question today!

Can't find what you're looking for?

Send us an email