Client-side vs Server-side Header Bidding | What’s the Difference?
Almost every monetization company utilizes a client-side header bidding model, but the future of programmatic advertising leans towards another ad-serving technology–server-side header bidding.
This article explains the main differences between client-side and server-side header bidding, the benefits and drawbacks of both, and which technology is more beneficial for publishers.
What is Client-Side Header Bidding?
Client-side header bidding, also known as browser-side header bidding, is currently an industry standard most publishers and monetization companies utilize. In this type of setup, the real-time header bidding auction happens on the user’s web browser, such as Google Chrome.
This means that when the prebid JavaScript code executes (code template used to connect publishers’ ad space with demand partners), the user’s browser sends many ad requests to demand partners who participate in the auction where the highest bidder wins.
For this technology to work, publishers have to add prebid JavaScript (JS) code into the website’s source code.
There are two scenarios of how client-side header bidding can work:
- with ad server
- without ad server
In the majority of header bidding auctions, Google is one of the participants. In the header bidding process, Google executes its auction by using a Google Ad Manager (GAM) server where the winning bidder is decided.
How Does Client-Side Header Bidding Work?
Let’s see how it works.
- The user opens the web browser, for example, Google Chrome, and types in the publisher’s URL.
- When the web browser starts to load the page, the JS code (located in the publisher’s source code) executes.
- Many ad requests are sent separately from the user’s browser to each demand partner (SSPs, like OpenX, Magnite, Index Exchange, etc.)
- All bids from demand partners return to the web browser, and another ad request is made from the JS code.
- This ad request includes the highest bidder from all demand partners, and then it is sent to the publisher’s ad server (e.g., Google Ad Manager), where the highest bid competes with the publisher’s direct deals.
- The ad server selects the highest bidder, and the ad code is sent back to the website to display the ad.
If a publisher for any reason is not using an ad server, such as GAM, Google Ad Exchange (AdX) doesn’t participate in the final auction, and the whole HB auction happens within the user’s web browser.
Let’s see how the client-side header bidding auction looks without an ad server.
- The user opens the web browser, for example, Google Chrome, and types in the publisher’s URL.
- When the web browser starts to load the page, the JS code (located into the publisher’s source code) executes.
- All the ad requests are sent from the user’s browser to the demand partners’ servers.
- All the bids are sent back to the web browser, where the prebid.js header bidding wrapper selects the highest bidder.
- Then the winner’s ad is displayed on the website.
Many monetization companies refer to client-side header bidding as a header bidding wrapper solution. However, we at Setupad refer to our header bidding wrapper as a hybrid solution because it combines both the client-side and the server-side header bidding technology. Setupad Header Bidding Wrapper collects the most valuable bids on the client side with bidding on the server side. That way, publishers get the most revenue without compromising the website’s loading speed.
Setupad Header Bidding Wrapper Solution:
- The user opens the web browser, for example, Google Chrome, and types in the publisher’s URL.
- When the web browser starts to load the page, the JS code (located into the publisher’s source code) executes.
- All the ad requests are sent from the user’s browser to the demand partners’ servers and Setupad Prebid Server.
- The Setupad Prebid Server calls all demand partners with a single call and all partners respond at the same time.
- Then the highest bidder’s bid is sent back to the browser and other demand partners’ bids outside of the Setupad Prebid Server.
- The final header bidding auction happens in the web browser, where the highest bidder is decided.
- Then the winner’s ad is displayed on the website.
What is Server-Side Header Bidding?
The server-side header bidding concept is similar to the client-side header bidding, but instead of sending many ad requests and holding header bidding auctions in the user’s web browser, the user sends a single request to the server, which sends out many requests to SSP/ad exchanges. All bidders respond almost immediately without the involvement of the user’s browser.
Even though this approach is not that common, some publishers might entirely skip the client-side header bidding and use the server-side header bidding technology instead. Why? Because for many publishers, website speed advantage is of the highest importance.
What’s the advantage of server-side header bidding?
The main advantage is that the user’s browser only sends one ad request to the server. Then the server forwards this request to many demand partners, sending the winning bid back to the browser. And then, the final ad server (responsible for serving ads; usually, it’s the GAM server) displays the ad.
To execute the process of server-side header bidding, you need a server-side header bidding vendor, in other words, a server that would host the auctions. The most commonly used server for server-side bidding is Prebid, which is also the infrastructure on which Setupad’s ad server is built. The Prebid server also provides the caching solution, which may allow running a lot more demand partners than client-side header bidding, where the number of demand partners is limited.
However, building such a solution from scratch isn’t attainable for most publishers as it’s costly and requires a lot of IT resources. Therefore, it makes sense to partner with a company that has all processes streamlined.
Setupad’s hybrid header bidding includes server-to-server (S2S) connections to Prebid.js server, Google’s Open Bidding, and Amazon Transparent Marketplace (TAM). Overall, these S2S integrations account for 35% of the winning auctions. We predict that S2S auctions will soon take over the majority of auctions thanks to much faster bid response times and better yield.
In addition, Setupad’s Prebid.js custom template (aka header bidding wrapper) stored on our ad server can choose the optimal number of demand partners (SSPs), maximizing the efficiency of each ad placement.
How Does Server-Side Header Bidding Work?
- The user opens the web browser, for example, Google Chrome, and types in the publisher’s URL.
- The user’s web browser starts loading the web page, and automatically the ad request is sent to the Prebid server (in our case, Setupad Prebid server).
- Now the Prebid server calls the servers of demand partners with a single call, and all partners respond with their bids at the same time.
- Prebid server decides the winner.
- The winning bid is sent back to the web browser, where the JS code sends the winner’s bid to the publisher’s ad server, and the ad is displayed.
Client-side vs Server-side Header Bidding
*explained more below the table
| Client-Side Header Bidding | Server-Side Header Bidding | |
| Benefits | • Cookie Matching* • Control of adding and removing the buyers • Easy to implement and the first choice for most publishers | • Minimal impact on website’s loading speed* • Reduced page latency • Better ad viewability • Better fill rate • More demand partners can be added • Higher CPM • Better for rich media and video ads as these are the heaviest ads that take the toll on the website loading speed. • Fewer timeouts* |
| Drawbacks | • Limited amount of demand partners can be added* • Higher page latency • Fewer bids • Higher page loading speed | • Lower Cookie Matching rate • It’s complicated and costly if done by yourself |
*Cookie Matching
Since in the client-side header bidding, everything happens in the web browser, third-party and first-party cookies, aka browser cookies (files that allow advertisers to identify the user on the publisher’s site) can be read. This helps advertisers to run personalized and retargeted ad campaigns.
However, the server-side header bidding, (browser) cookies cannot be read on the ad server because the data is filtered when syncing the publisher’s and server’s DMP. This means that publishers and monetization companies need to handle cookie synchronization themselves to identify users and transmit data to the server.
However, with the third-party cookies phaseout scheduled for the end of 2023, server-side header bidding might be exactly what the industry will reach out to.
*Loading Speed
Server-side header bidding allows the web browser to send a single request to many demand partners, from where the Setupad’s Prebid server handles the heaviest part of the header bidding logic. Since the ad server handles many ad requests, the website’s loading speed is not affected. However, on the client-side header bidding, every request is handled on the web browser.
*Fewer Timeouts
According to prebid.org, all header bidding partners are given a similar amount of time to respond (aka timeout) for each impression. Any bidder that responds after timeout is disregarded.
Povilas Goberis, COO of Setupad: »The timeout is actually a parameter that is being handled by the publisher or, in our clients’ cases, by Setupad. We adjust timeouts based on viewability and ad placements, so the publisher can receive the highest yield while keeping the user experience intact.»
Since you, as a publisher, cannot impact the speed of the user’s internet connection, there is a possibility that you won’t receive the highest bidder’s bid just because the header bidding auction is being affected by a slow internet connection.
In addition, on mobile, where webpage speed is even more critical, some browsers may limit how many simultaneous requests can be sent, which leaves some demand partners out of the picture and results in lower ad revenue for the publisher.
That’s why server-side header bidding is an ideal choice for publishers, as servers are designed to process a large volume of data transfer, thus making them work way faster than web browsers.
*Selected Amount of Premium Demand Partners
Every demand partner adds weight to JS code, so it’s important to select only the ones that have better performance (e.g. quality of advertisers and global reach).
Which Solution is Better for Publishers?
As you can see, both solutions have their pros and cons. Therefore, the ideal header bidding setup is hybrid. And that’s exactly why Setupad’s technology is the best choice for the publisher.
Many companies still hold on to client-side technology because of the complexity of creating their own server and accessing third-party server-side bidding solutions. Despite that, server-side header bidding is the future of programmatic advertising.
Since the advertising industry is currently moving towards a privacy-safe cookieless future, with an increased focus on viewability and user engagement, server-side header bidding will likely gain even more traction and might fully replace client-side header bidding in a not-so-far future.
