We’ve learned about header bidding and its use cases. But, what happens when we have Client-Side Header Bidding Vs Server-Side Header Bidding?
Header Bidding also called pre-bidding, is an advanced method of integrating demand partners ( Ad exchanges, SSP’s, Ad networks etc) which allow Publishers to sell their inventory to many demand sources (advertisers) 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. The technique relied on the users’ browsers for execution.
Client-Side Header Bidding Vs Server-Side Header Bidding
Although header bidding increased the CPMs by up to 60%, there were some drawbacks in implementing header bidding on the client-side. Noticeably, Page latency. So, to deal with the pitfalls and improve the user experience, adtech introduced a sister technique named ‘Server-Side Header Bidding’.
But the server-side header bidding has its own advantages and disadvantages. Ultimately, it’s up to publishers to settle on a decision. As a Header Bidding provider, we feel responsible to guide publishers like you to choose the best decision.
There’s no one size fits all solution in programmatic advertising. Hence, we explained both Client-Side Header Bidding (Browser-Side Header Bidding) and Server-Side Header Bidding to help you pick the right solution.
What is Client-Side Header Bidding?
In Client-Side Header Bidding, bidding happens on the browser. Everytime a page loads, ad request will be sent to the demand partners to receive their prices.
The demand partners conduct their own auctions and send the prices to the page header. Now, the header passes the information to the ad server (with the help of key values) to determine the winning bid. Then, the user will be served with an ad.
Higher Cost Per Mille (CPM): 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: If a publisher decides to add more header bidding partners, then the page will take more time to load. This is obvious as more partners mean more bids which make users wait longer. This 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 because of the latency issues.
What is Server-Side Header Bidding?
It’s just like the Client Side Header Bidding but the difference here is that 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 only one script (from the ad server) needs to be added for all partners.
When a webpage loads, an ad request will be sent to the ad server. The ad server then sends the request to SSPs, DSPs, Ad Exchanges, etc. and receives the bids to determine and serve the winning ad creative.
Reduced latency: As the browser is sending a single request (to the ad server) this time, the page load time is greatly reduced.
Scalable: The server-side approach essentially creates unlimited scalability without any price on latency. A publisher can add as many bidder partners as he/she wants.
Match rates: Since the ad request is sent to the SSPs, DSPs, Ad Exchanges from an external ad server (not from the user’s browser) match rate will be low. Hence, bidding prices will also be lower than the client-side header bidding.
Black Box: Ad Server will be in control and publishers have to rely completely on the server to pass the right values and decide the winner. Publishers consider this as a ‘Black Box Approach’. In browser-side, a publisher will be in control and can see what happens exactly.
Client-Side Header Bidding Vs Server-Side Header Bidding – Which One is for You?
If User Experience* > CPM for you, then the ideal way is to go with Server-Side Header Bidding.
If CPM > User Experience*, then the right way is to go with Client-Side Header Bidding.
*Note that we’re talking about very minimal differences here. For instance, there might be a few milliseconds difference when you execute and compare both the solution.
Hybrid – For those who don’t compromise on both. In the hybrid, a couple of the bidder partners are shifted to the ad server. So, minimal latency and standard CPMs.