Waterfall Vs Client Side Vs Server Side Header Bidding

Header Bidding is also called “Pre-bid”. It’s an innovative method of integrating demand partners ( Ad exchanges, SSP’s, Ad networks etc) which allow Publishers to sell their inventory to many demand sources simultaneously unlocking higher yield. It allows publishers to collect bids from demand sources for all of their inventory prior to a sale. The goal is to bring a greater level of transparency in the process to help publishers understand who is bidding what amount.

WaterFall Model:

Traditionally Publishers followed Waterfall model which had so many drawbacks. Waterfalling is a technique publisher used to maximize both the pricing and sell-through rate of their inventory. It’s also often called “daisy chaining.”

Earlier publishers were completely operating in an environment which left many questions in their minds unanswered. Major concerns were:

  • Risk of improper valuation of inventory
  • Seller Risk: They never knew who was buying the impressions. There have been events where in some folks have carried out big frauds amounting to millions of dollars. Hence, it is important to alleviate these risks.

How did it work?

In a waterfall approach, the publisher’s ad server offers an available impression to potential buyers in pre-set, descending order. If the ad is compatible with the required buying specs, the ad is served and the waterfall is over.

This approach is inefficient and ultimately hurts both publishers and advertisers. It’s like offering your inventory to four different buyers, one after another, lowering the price whenever someone rejects the inventory. Eventually, someone might say yes for the bargain, but that isn’t how you get the best price. Furthermore, it gives the impression that you’re selling low-grade inventory—inventory that many people already rejected. And given the reality of discrepancies when using this cascading passback approach, it’s like losing inventory between each pitch.


Are there different types of Header Bidding Techniques?


Broadly there are 2 main types of Header Bidding techniques:


  • Client Side:


It involves injecting a header tag in the head element of the publisher’s website.  The head element is a string of code invisible to the end user that looks like this:



<h1>Some major information here</h1>

<h3>Less important data here</h3

<p>Additional facts here</p>



The tag is provided by the header Bidding vendor. This tag is nothing but a short snippet of Javascript code. This snippet is responsible for connecting various sources interested in participating the Bidding and purchasing ad inventory.

Now, whenever the web 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.

This allows impressions to be offered to multiple demand partners who can bid on it. If nobody bids, it creates a second price auction. This process goes on and on until all the impressions are sold.

The below visual diagram can give you a good idea of the old waterfall model & new Header Bidding technique:



What’s the upside & downside?


Higher Cost per mile: Publishers can now receive bids from Buyers who are more interested and are willing to buy more price.

Higher Fill rates: More buyers means higher chances of filling all types of available inventory, including both premium and remnant (unsold) inventory.

Great Insights: Floor pricing allows publishers to understand the real worth of their inventory. Example: If a publisher sets a floor price (the lowest price they are willing to sell their inventory for) of $1 CPM, but after utilizing header bidding finds that their inventory is being sold for an average of $2 CPM then they really understand what they were losing out on earlier.


Latency: The more bidding partners a publisher decides to add the more is the risk of slowdown of Page load time. Which has a negative effect on the user experience, results in fewer impressions loading, and lowers the likelihood of ads being viewed.

Compatibility: Compatibility with multiple browsers is important. Certain browsers may behave in certain conditions differently (e.g., some browsers may pool connections to external pixels or block them completely).

Duplicate Bids: Risk of putting the same impression or inventory up for sale since a publisher uses multiple bidding partners.

Performance: Addition of new logic can slow down the performance of the website & Browser.  

Not Scalable: It isn’t scalable beyond six to eight partners for the browser’s concurrent connection limit, and the problem that limit creates is latency.

  1. Server Side:

It’s just like the Client Side Header Bidding but the difference here is the instead of sending the requests from the Browser, server side Header Bidding sends the requests to the different SSPs from the ad server. This means instead of the user’s browser, the auction now happens outside on a server provided by a technology partner.  There’s just less implementation work to do because with this only script needs to be added for all partners.

On the ad server side, there’s no change; publishers can decide to set up one set of line items across all partners, or a set of line items per partner.  However, because there are often hundreds to thousands of line items required per partner and as mentioned before, a key benefit with server side header bidding is being able to add many more partners, it’s more likely for publishers to pick the former option and consolidate the ad server setup into a single set.

Benefits :

  • Reduces latency
  • Scalable with more Bidding partners: The server side approach essentially creates unlimited scalability without any price on latency.

If you liked my post please feel free to comment or share it. Drop your feedback at ankit@automatad.com or connect with me on Linkedin.  I’ll be happy to speak to you & help you monetize your inventory.

261 Madison Avenue New York NY 10016
Contact: +1 917 720 3756


Copyright © 2017 Automatad, Inc. All Rights Reserved.