Header Bidding: Client vs Server-side
Cats versus dogs. Mac versus PC. Tupac versus Biggie. These debates have raged for centuries across the annals of human history. Now, the digital advertising industry is introducing a new debate for the public to parse: which kind of header bidding integration should I use?
There are two main types of integrations: client-side and server-side. Each has its own pros and cons with respect to transparency, data, latency, identity, support, and technical limitations. In this blog post, we will look at the difference between the two methods and get some advice from our very own Head of Products, Stuart Moncada, about which header bidding integration is right for you.
Publisher Note: we’ll assume you’re familiar with the basics of header bidding for this discussion. If you need a refresher, head over to our previous piece, Header Bidding Wrappers 101.
Client vs. Server
What are the main differences between client & server-side tech?
“The industry is very much in experimentation mode,” explains Stuart Moncada. “The fundamental difference between these two technologies is the location of the software or code that controls the header bidding auction logic.”
Client-side In client-side header bidding, the auction code lives on the publisher’s page and is executed on the user's browser as they visit the website. So, all the logic to request and receive bids and then pick a winner is happening on the users browser.
Prebid.js, an open source solution, is the most popular client-side wrapper and many exchanges/SSPs have built their own version on top of the open source code.
Server-side With server-side header bidding, all of the auction software and logic is executed on a standalone “auction” server. Therefore, the user’s browser makes a single request to the auction server and the server takes care of sending and receiving bid requests and picking a winner.
Vendors of server-side integrations include Google Ad Manager (formerly EBDA), Amazon TAM, and Prebid Server.
Scorecard
With the basic framework laid out, let’s take a closer look at the pros and cons of each:
| Client-Side | Server-Side | |
|---|---|---|
| Transparency | Since the code lives on the publisher’s page, the publisher has complete control and visibility over how it functions and picks winners.
This also provides publishers with direct access to bid and log-level data.WINNER |
In a server-side configuration, the vendor controls and runs the auction logic on their “auction” server. This puts publishers at the mercy of the vendor with respect to auction mechanics, logic, and access to bid data. |
| Latency | The software that handles the auction logic runs on the user’s browser, which has limited resources. If a page needs to load heavy content or JavaScript, the additional load of the auction can increase latency. | Server-side integrations have better performance in terms of latency because servers have more power and resources than browsers. WINNER |
| Identity | Cookie matching rates are higher in client-side set-ups because user IDs go through fewer syncs (not needing to be sent to an additional server), which means there are fewer opportunities for failure.
Advertisers will pay more for an impression they can identify, so higher cookie matching rates translates to more revenue per impression for publishers. WINNER |
Cookie matching rates are lower in server setups because the matching is done by the vendor’s server and the ID method used by the vendor may be different from other SSPs and DSPs. Additionally, the extra sync with the auction server provides another chance for the user information to be lost.
As mentioned on the client-side, advertisers are less willing to pay for an unknown impression, so lower cookie match rates lead to less revenue per impression. |
| Auction Limits |
Browsers have limits on the number of outgoing calls/requests that can be made. This limits the number of demand partners you can include in your header bidding auction because each partner counts towards total calls. |
Without the browser limitations, publishers don’t have to limit the number of demand partners they include in their server-side auction.WINNER |
| Support | Running the auction code on page means publishers will have to maintain another piece of technology and manage any integration or browser compatibility issues (though there are vendors that offer managed client-side header bidding services). |
Since the auction runs on a vendor’s server, the vendor handles the maintenance and support in exchange for a fee and/or per-impression charge.WINNER |
Making the right decision
Now that you know the pros and cons of client-side and server-side bidding, you may be asking yourself if one integration is more suitable than the other. According to Stuart, “it’s a subjective decision which of the two solutions are better, so I recommend to publishers that they let their organizational priorities and values direct their decision.”
Stuart elaborates: “If you are a publisher that values transparency and control above all, client-side header bidding is your solution.”
“If you purely care about increased revenue yield, there is not a definitive answer on which technology is better as it can depend on your type of inventory, your audience, and your setup. On the client-side, increased cookie matching rates drive up yield, yet may suffer from latency and fewer demand partners. Server-side integrations see increased yield thanks to lower latency and more yield partners, but are hurt by cookie matching.”
“There are so many changing variables that it is very difficult to have a definitive answer for publishers. There can also be an added variance in performance and yield between the different tech providers within the two technologies, which adds another layer of complexity. In theory, if server-side header bidding can resolve the cookie matching issues it would seem to hold an edge in terms of performance which should translate to higher yield, however, this has not yet been shown.”
Best Practices
While the decision is far from simple, Stuart did share a few best practices for choosing your header bidding integration.
“Decide up front which are the KPIs and features (yield, latency, user experience, transparency) that are important to your business and align your solution accordingly.”
“Demand transparency and data, and measure performance.”
And when it comes to vendor discussions, “There is no valid reason why a server-side solution wouldn’t provide bid level data to publishers.”
Ultimately, publishers need to prioritize their expectations for a header bidding integration and choose according to what they feel is important for their revenue goals.
Hopefully, this guide has helped clarify the differences and provided some insight to help you make your final decision. If you’re still unsure what direction to take, we’re happy to help!
Contact us ›