Header bidding integrations: Client vs. server-side, explained

Every once in a while, something disrupts the status quo and changes how an entire industry works. Header bidding is probably the best example of this in ad tech. According to Kevel’s HBIX, just over 65% of Top 10K US publisher sites were using header bidding in Q1 2021. That’s especially impressive as header bidding only went mainstream around 2016.

So what’s the main driving factor behind this mass adoption? In two words: More revenue. By allowing multiple demand partners to simultaneously bid on individual impressions, header bidding allows publishers to maximize yield. With header bidding, publishers can achieve a revenue lift of anywhere between 20-40%, sometimes more. For instance, The Telegraph achieved a 70% increase in programmatic revenue with header bidding.

There are two main types of integrations in header bidding: Client-side (the original header bidding auction model) and server-side (the new kid on the block), both integrations have their unique set of advantages and disadvantages. In this guide, we’ll explain how both integration types work, along with a head-to-head comparison of client vs. server-side header bidding.

Client vs. server-side header bidding

Comparison and verdict

	Client-side integration	Server-side integration
Latency	As mentioned before, the code that runs the header bidding auction resides in and is executed on the users’ browser, which contributes to latency both during the initial page load and auction execution, especially when the user is connected via a low speed connection.	Auction servers are purpose built for running auctions and are connected to the Internet via high speed connections, which means that they can send requests, receive bids, and select a winner much faster than client-side header bidding wrappers can. (Winner)
Revenue	Cookie match rates are higher with client-side header bidding because user IDs don’t need to be synced with an additional server, reducing failure rate. 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 every impression. (Winner)	Cookies match rates are lower because the ID method used by the vendor may be different from other SSPs/DSPs. Additionally, the extra sync needed with the auction server increases the potential failure rate in identification. Advertisers bid less for unidentified users, which means lower average revenue per impression for publishers.
Investment	Running your own client-side stack requires more initial investment of time and resources during setup. You also need to dedicate resources on an ongoing basis for managing updates and ensuring browser compatibility. However, there are vendors who offer fully-managed client-side wrappers.	In server-side header bidding, the auction runs on the vendor’s servers. Therefore, publishers don’t have to allocate resources for maintenance and support of the header bidding stack. In exchange for managing operations, vendors charge publishers a fixed or impression based fee. (Winner)
Bidder limit	The number of demand partners in a client-side setup is proportional to revenue lift. However, how many bidders you can add is usually capped by browser call limits. Every additional bidder also contributes to page latency.	In a server-side setup, the browser only has to make a single call to the auction server. This means that publishers can add as many bidders to the auction as they want, without noticing any negative impact on latency. (Winner)
Transparency	One advantage of running the auction code in the browser for publishers is having complete control and visibility over how it functions and selects winning bids, including direct access to bid and log-level data. (Winner)	Server-side auctions work as “black boxes”, the browser makes a single call and receives the winning bid—everything that happens in between is opaque. This means limited access to auction logic and bid data.

Making the right choice

Most publishers started out with using client-side header bidding, until they ran into issues related to maintenance costs and latency. Server-side header bidding was launched in response to the market need for an alternative that can deliver revenue lift comparable to client-side, while limiting its downsides. In some crucial ways, server-side does manage to do just that.

When evaluating server-side or choosing between client vs. server-side integration, the key consideration is the tradeoff between yield and latency. As a publisher, would you rather prioritize maximizing revenue generated per impression or user experience?

Here are a few other questions to ask:

• Do you need access to bid/log-level data?
• Do you have in-house engineering resources?
• How many demand partners do you want to include in the auction?
• Do your demand partners support server-to-server integration?

Some publishers also run client-side and server-side header bidding concurrently, picking the winning bid from both auctions at the last step. It’s also important to note that the comparison above considers typical client-side and server-side header bidding integrations. It’s possible to find a fully-managed client-side wrapper, or conversely, a server-side vendor who is open to sharing bid data. We recommend running an A/B test to capture the real world results of using both types of integrations and then using the performance results to make the final decision.