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 allows 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 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 publishers 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 it worked?
In this approach, the publisher’s serves the impression to buyers in a descending order. If the ad matches with the required specifications, it is served.
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:
- Server 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:
<head>
<script type=”text/javascript” src=”lib/ui.js” />
<script type=”text/javascript” src=”lib/prebid.js” />
</head>
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.
Once the page loads the demand sources (e.g. ad networks and buyers connected to supply-side platforms [SSPs] and ad exchanges) bid on each impression on that page.
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?
Pros:
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 buyer’s 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.
Cons:
Latency: The more bidding partners a publisher decides to add the more is the risk of slowdown of Page load time. This can negatively impact the user experience resulting in fewer impressions loading & lowers the chances of ad being served.
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.
2. 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. What that means is the auction now takes place outside on a server instead of the user’s browser. 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 or Twitter. I’ll be happy to speak to you & help you monetize your inventory.
