What is Header Bidding?
- Header bidding (otherwise prebid) is a programmatic process that enables publishers to collect multiple bids from various SSP’s at the same time before their ad server is called.
- It allows publishers to know which demand partners are bidding, what is their bidding share, bid values and can get the highest possible CPMs for their inventory. Once partners submit their bids, the bids then competes with the publisher’s ad server
- Publishers can earn more revenue (yield) with their inventory and Advertisers on the other hand also have a better chance of winning the premium inventory.
Client-Side Header Bidding:
Client-side header bidding (also known as Browser-side header bidding) involves adding a piece of JavaScript code to a publisher’s website. The code then executes each time a page loads, and sends ad requests to a number of demand partners. Then, bids start coming in from DSPs via SSPs and ad exchanges, with the highest bidder winning the auction.
Pros:
- Transparency and control: All of the code is present on the publisher’s page. He is able to see everything that’s going on.
- Here codes are open source – anyone can check what’s going on.
- Cookie matching: The communication between SSPs and Demand partners, and the publisher, so the cookie matching from the buyers (DSPs) , is done directly with those SSPs. Usually, we have better cookie matching rates on CSHB.
- Here, cookies are stored in the browsers and are sent directly to the programmatic bidders or ad networks.
Cons:
- Page latency: Running all of these auction logic, requests, etc runs on the user browser. So it potentially causes page latency.
- Auction Limits: Browsers have limits on the no. of demand partners. (old browsers – have 6 to 8 partners) Browsers have limited ports, and it makes them load pages slowly
- Duplicate Bids: If a publisher connects to multiple partners, there is a risk of offering the same impression for sale multiple times, which can lead to duplicate bid processing. But, this can also happen in the server-side implementation.
Server-Side Header Bidding:
Server-side header bidding is the latest, but very similar process to client-side header bidding. Here, the requests are being sent from a main server rather than directly from the browser.
Pros:
We are moving all the client-side HB work to a server so that the user’s browser does not have to do the work itself.
- More demand partners – Publishers can choose as many bidders as possible to run in the auction, unlike the client side Header bidding.
- Smaller timeout
- Better performance
- Reduced page latency
- Here the server is responsible for making requests to all the SSPs and receiving their responses and selecting the winner.
- Fewer auction limits – have a lot of ports and are not constrained by limits unlike in a user’s browsers. Then more ad calls at once can be accommodated.
Cons:
- Lack of Transparency and control is a disadvantage here:
- Publishers are unable to choose the buyers
- Publishers have to pay tag partners rev share fee
- Logic of demand structures is not known or clear
- Cookie match rate: Here, the auction happens on a Third-party server rather than a browser where cookies can be lost or cannot be stored. So, it will become difficult to sync the identity of the user with the programmatic bidders which becomes hard for advertisers.
- 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).
Client vs Server Side Header Bidding:
| Features | Client Side Header Bidding | Server Side Header Bidding |
| Working |
In Client side implementation, ad requests will be sent directly from browser to various SSP partners at once. For which the partners will respond with their respective bids to the page and the highest bidding partner’s bid would be eligible to compete with other programmatic channels in the ad server |
In server side implementation sends the ad requests from the browser to a dedicated server to different exchanges, SSPs, and DSPs. Once the server receives the bids back from SSPs, it will send them to browser and then on to Publisher’s ad server |
| Example | Header Bidding occurs on page | TAM (by Amazon), Open Bidding (by Google) |
| Revenue |
Cookie match rates are high for Client side Header Bidding Advertisers will typically bid more on impressions where they can accurately identify a user, this means that client-side header bidding delivers more revenue for each impression |
Cookie match rates are low for Server side Header Bidding When Advertisers has less information about for users identity, they try to bid at less value which means lower average revenue per impression for publishers |
| Transparency | We can get complete reporting on impressions and revenue without any shadowing | It can be hard for publishers and advertisers to see the details of the auctions, true cost of the impressions, what auction type and how many fees were added on top. All these things make it harder to identify and resolve issues. |
| Partners Limitation | The number of demand partners in this setup is proportional to revenueBut the number of bidders accommodation is usually capped by Browser’s call limits |
In Server – side setup, the browser makes only a single call to the server Which means that the publishers can add any number of bidders to the auction without having any negative impact on latency |
| Page Latency | As the auction happens on page and requests will be sent from the page, it is obvious for the existence of page latency | As the auction happens on a dedicated server, the browser is able to render the page without being bogged down |
|
User Experience |
Sometimes, page latency can cause bad user experience | Results in a better user experience due to reduction in page latency |
| Advertisers | The more demand partners you add, the more slower the ad loads | We can add any number of demand partners which doesn’t slow down the ads |
| Cost | There is no additional cost involved in here with client side Header Bidding | Here it has additional costs like server-cut, maintenance related expenses, and fees from Third – party providers |
Which Header Bidding is better- Client side or Server side?
We cannot say which is better but by Choosing between Client side and Server side header bidding is a decision to be made by the Publisher based on specifics they look into like demand, inventory type, revenue, user experience, and market trends. Most publishers started out using client-side header bidding, until they ran into issues related to maintenance costs and latency.
Both implementations have their own advantages and disadvantages, but the best way forward is to test both implementations and clearly see what they will offer for revenue in the long run to the publisher. When evaluating these two implementations, the key factors to be considered are yield and latency.
Few questions to be answered before finalizing the decision:
- What publisher would prefer, maximizing revenue generated per impression or user experience?
- Does a publisher need access to log level data?
- How many Demand partners does a publisher want to include in the auction?
- Do your Demand partners support Server – to – Server integration?
- Do you have an in-house engineering team to manage set – up integrations and issues?
How can DataBeat help here?
DataBeat has ample experience in handling both client side and server side integrations. It can offer tailor made strategies to publishers keeping in view of their niche, domain, and markets.
As choosing between client side and server side depends on the publisher, we offer different strategies that work for different publishers. We also recommend running an A/B test to find out the real results of using both types of integrations and then using the performance results to make the final decision.
