Client-side vs Server-side Header Bidding | What’s the Difference?

client-side vs server-side

Almost every monetization company uses a client-side header bidding model, but the future of programmatic advertising leads toward 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 will be more beneficial for publishers.

Table Content:

What is Client-side Header Bidding? 

Monetization companies currently use client-side header bidding (aka browser-side header bidding) for serving programmatic ads on publishers’ sites.

Client-side header bidding (HB) runs HB auction on the user’s web browser, for example, 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.

How does Client-side HB work?

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 GAM ad server 
  • without GAM ad server

In the majority of header bidding auctions, Google is one of the participants. In the HB process, Google executes its auction by using a GAM server where the highest and the final bidder is decided.

Let’s see how it works. 

  1. The user opens the web browser, for example, Google Chrome, and types in the publisher’s URL.
  2. When the web browser starts to load the page, the JS code (located into the publisher’s source code) executes.
  3. Many ad requests are sent from the user’s browser to demand partners.
  4. All bids from demand partners come back to the web browser, and then another ad request is made from the JS code.
  5. This ad request includes the highest bidder from all demand partners, and then it is sent to the GAM server, where Google Ad Exchange (and sometimes Google’s Open Bidding partners) participates.
  6. Then Google’s demand competes with other demand partners, and the highest bidder wins.
  7. When the winner is decided, the ad code is sent back to the website to load the ad.

When a publisher for any reason is not using an ad server, such as GAM, Google Ad Exchange 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 GAM.

  1. The user opens the web browser, for example, Google Chrome, and types in the publisher’s URL.
  2. When the web browser starts to load the page, the JS code (located into the publisher’s source code) executes.
  3. All the ad requests are sent from the user’s browser to the demand partners’ servers.
  4. All the bids are sent back to the web browser where the prebid.js based header bidding auction happens, and the highest bidder wins.
  5. 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, the Setupad header bidding wrapper is a hybrid solution because it combines 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:

  1. The user opens the web browser, for example, Google Chrome, and types in the publisher’s URL.
  2. When the web browser starts to load the page, the JS code (located into the publisher’s source code) executes.
  3. All the ad requests are sent from the user’s browser to the demand partners’ servers and Setupad Prebid Server.
  4. In the Setupad Prebid Server, all demand partners start to compete with each other. 
  5. Then the highest bidder’s bid is sent back to the browser and other demand partners’ bids outside of the Setupad Prebid Server.
  6. The final header bidding auction happens in the web browser, and the highest bidder wins.
  7. Then the winner’s ad is displayed on the website.

What is Served-side Header Bidding?

The server-side header bidding concept is similar to the client-side HB, but instead of sending many ad requests and holding HB auction in the user’s web browser, the user requests the winning bid from the server. 

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. In the example below, we also assumed an ad server, such as GAM, is not used for simplification purposes.

This means that the user sends only one ad request to the server. Then the server forwards this request to many demand partners, and when the highest bidder wins on the server-side, the winning bid is sent back to the browser. And then, the final ad server (responsible for serving ads; usually, it’s the GAM server) displays the ad.

The most commonly used server for server-side bidding is Prebid. 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.

How does Server-side HB work?

  1. The user opens the web browser, for example, Google Chrome, and types in the publisher’s URL.
  2. The user’s web browser starts to load the web page, and automatically the ad request is sent to the prebid server.
  3. Then the Prebid server makes many requests to the servers of demand partners, which then sends back the bids to the server.
  4. Prebid server concludes the winner from the demand partners.
  5. Then 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, where the final ad is concluded.

Client-side vs Server-side Header Bidding

*explained more below the table

Client-Side Header BiddingServer-Side Header Bidding
BENEFITS– Cookie Matching*

– Control of adding and removing HB Wrapper

– Easy to implement and the first choice for most publishers
– Minimal impact on website’s loading speed*

Reduced page latency

Better ad viewability

– More demand partners can be added

– Higher CPM

– 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 expensive if done by yourself

*Cookie Matching

Since in the client-side header bidding, everything happens through 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, on the server-side header bidding, (browser) cookies cannot be read on the ad server. This means that publishers, monetization companies themselves will need to do cookie synchronization to identify users and then transmit them to the server to make the bidding decisions.

*Loading Speed

Thanks to the server to server connection, it’s possible to directly connect the ad server to many demand partner servers. Server-side HB allows the web browser to send only one ad request, and the server handles the heaviest part of the HB process. Since the ad server handles many ad requests, the website’s loading speed is not affected, but on the client-side HB, 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 bid that responds later than the 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 went from a default timeout of 1000 ms in the early stages, and now, as our ad load speed-focused technology evolved, we have reduced it to 400 ms and planning to reduce it even more.”

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 HB auction is being affected by a slow internet connection. 

Web browser itself isn’t the main reason why something isn’t loading from the internet, but the user’s internet connection’s speed is what matters. That’s why it’s better to run HB auction on the server-side, so the web browser doesn’t have to handle the whole header bidding process, which is heavy.

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 script code, so it’s important to select the ones who have better performance (e.g. quality of advertisers and global reach).

Which Solution is Better for Publishers?

Server-side header bidding is the future of programmatic advertising. Many companies still hold on to the client-side technology because of the complexity of creating their own server and getting access to 3rd party server-side bidding solutions.

The main benefit of server-side HB is the speed of the technology. It doesn’t compromise the website’s loading speed and reduces page latency, therefore, increasing ad viewability, leading to even more ad revenue for publishers. Setupad is already on this path by creating server-side header bidding, and if you are our client, you don’t have to worry about this. Join Setupad!

Tus comentarios ayudan