Client-Side vs. Server-Side Header Bidding: Pros and Cons

Understanding the concept of header bidding is central to understanding how programmatic ad buying works. The process originally emerged as a novel solution to remedy the inefficiency, and Google’s preference, of its own ad exchange (AdX), during the waterfall ad-buying process.

However, it quickly gained traction and became a widely accepted and expected industry standard. It is estimated that more than half of US publishers have adopted header bidding as the leading programmatic process.

What Is Header Bidding?

Header bidding (aka pre-bidding, advance bidding, and holistic yield management) is a programmatic process that enables publishers to collect multiple bids from various demand sources (such as DSPs and ad networks connected to ad exchanges and SSPs) at the same time before their ad server is called.

This process allows publishers to “see” which demand sources are placing the bids, and find out the actual value of their bids (ex. $1.05), allowing them to get the highest cost per mille (CPM) possible.

Because the bids are received before a publisher’s ad server is called, they can compete with a publisher’s premium deals within the publisher’s ad server. The benefit for advertisers is that they have a better chance of winning the impression. Publishers, on the other hand, can earn more money for their inventory (better yield).

On paper, it’s a win-win situation, but the actual benefits vastly depend on the way header bidding is implemented by the publisher.

In this post, we will look closer at the server-side and client-side implementations of the process and provide a detailed analysis of the pros and cons of each type.

What Is Client-Side Header Bidding (CSHB)?

Client-side header bidding (aka browser-side header bidding) involves adding a piece of JavaScript to a publisher’s website in between the tags. The code then executes each time a page loads, and sends an ad request(s) 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.

How Does Client-Side Header Bidding Work?

Here’s how the header-bidding process works from the moment a page loads on a publisher’s website to the time the available inventory is sold:
[img 17230 caption=”Client-side header bidding” title=”bidding graph_2″ align=”center” size=”full” alt=”Client-side header bidding process”]
Here’s what is happening in the image above:

• A user opens their web browser and types in the publisher’s URL.
• The browser starts loading the page.
• The header-bidding JavaScript code located in between the tags executes and sends a request to the third-party header platform.
• Bids from various sources start coming in.
• The highest bidder wins and is passed to the publisher’s ad server.
• The winner from the header-bidding auction competes with a publisher’s direct deals.
• The ad server selects the highest bidder and the ad is served (displayed on the page).

As you can see in the diagram, the speed at which bids are placed varies. This latency not only means some demand sources may not be able to place a bid due to being timed out, but also results in the page taking longer to load.

The timeout rates vary and are different on desktop and mobile web browsers. With desktop, the timeout range is 400–800 milliseconds; with mobile, it’s 800–1,200 milliseconds.

The concept is very simple, and offers a range of benefits for publishers:

Pros of Client-Side Header Bidding for Publishers

1. Cookie Matching

As the whole bidding process happens in the browser, AdTech vendors representing publishers and advertisers are able to sync their cookies, which allows advertisers to identify the user on the publisher’s site.

This ability to identify users allows advertisers to run targeted and retargeted ad campaigns, which ultimately results in more revenue for publishers.

2. Control of the Wrappers and Transparency

Header-bidding wrappers are pieces of JavaScript that act as a management system for publishers, similar to how tag managers work.

By using a wrapper, publishers can easily add and remove demand sources and set bid timeouts. However, the setup can be rather complex, and changing wrappers (for example, switching from Index Exchange’s Header Tag to Prebid) is not a trivial task.

Also,  header-bidding wrapper (or a single header-bidding tag) on a web page means that publishers are provided with more transparency in areas like demand sources and clearing prices.

3. Client Side Is Still the Industry Standard

Server-side header bidding still has a few kinks that need to be ironed out for it to be accepted by the ad industry, making client-side header bidding the go-to implementation for many publishers and advertisers.

The client-side header-bidding process clearly offers multiple benefits for the publisher, but it also comes with some inherent problems of its own.

Cons of Client-Side Header Bidding

1. Latency Issues

Header bidding originally emerged to reduce the number of passbacks that made waterfall auctions inefficient. However, the client-side implementation of header bidding is still not perfect.

Because it adds a number of scripts in the page header, page-load times get longer, negatively affecting the user experience and resulting in fewer impressions loaded.

Also, as client-side header bidding involves establishing multiple connections to other servers (AdTech platforms), it can lead to additional problems for users with a slower internet connection.

2. Compatibility

Client-side header bidding works in the browser, so it has to be backward-compatible with different browsers (also legacy versions), which can raise problems. Also, some browsers may pool connections to external pixels or block them completely, leading to inefficient header-bidding auctions.

3. Risk of Duplicate Bids

If a publisher connects to multiple header partners, there is a risk offering the same impression for sale multiple times, which can lead to duplicate bid processing. However, this can also happen in the server-side implementation.

4. Performance

Adding more logic slows down performance of the browsers and the website itself, which is not a big deal on modern hardware, but can be a problem on slightly older hardware and older smartphones.

5. Proneness to Shady Auction Practices

Because it’s controlled by the user, not a renowned vendor, client-side implementation leaves much space for possible shady techniques, and therefore can never be fully transparent for all parties involved.

Processes such as data validation should be done server-side, not client-side, as client-side data submission can be faked to avoid validation logic.

6. Limited Ad Requests

There are only so many requests a browser can make at one time, meaning the number of ad requests sent from the client-side header-bidding wrapper is going to be limited to around a dozen or so.

What Is Server-Side Header Bidding (SSHB)?

Server-side header bidding is a newer, but very similar process to client-side header bidding. The exception is that the requests are sent from a central server rather than directly from the user’s browser. Because of that, it offers publishers all the advantages of header bidding, but at the same time saves them from many of the problems associated with it – latency being one of them.

How Does Server-to-Server Header Bidding Work?

Here’s how the server-to-server implementation of header bidding works:

Step-by-step explanation:

• A user opens their web browser and types in the publisher’s URL.
• The browser starts loading the page.
• The header-bidding JavaScript code located in between the tags executes and sends a request to the SSHB vendor.
• The server then sends out bids to multiple demand sources.
• The highest bidder wins and is passed to the publisher’s ad server.
• The winner from the header-bidding auction competes with a publisher’s direct deals.
• The ad server selects the highest bidder and the ad is served (i.e. displayed on the page).

Here’s a side-by-side comparison of how the client-side and server-side header-bidding implementations work:

As you can see, the main difference between the two is that with CSHB, the bidding is done in the browser, whereas with SSHB, it’s done on a server.

Pros of Server-Side Header Bidding

1. A Solution for Latency Issues

There are different ways to fight latency with the client-side header-bidding implementation, such as using an open-source header-bidding wrapper solution like Prebid.js, or configuring a reasonable timeout, but solutions that completely eliminate the need for client-side bidding have obvious appeal.

The latency issue is significantly reduced by moving the header-bidding process off the browser and into a server – either a dedicated header-bidding server or an ad server.

How big of a performance boost are we talking about? Possibly just a few milliseconds, but the difference is big enough to matter in the overall user experience. For example, CafeMedia noticed a 40% improvement in page-load speed with server-to-server header bidding, but the tradeoff was revenue, which fell by nearly 30%.

2. Works Better for Videos and Rich Media

Because videos themselves are slow to load, switching to server-side is found to vastly improve user experience when loading video ads. Server-side is also the only implementation method for ads running on OTT devices, which are not open-ended and are part of a very fragmented ecosystem lacking ad-delivery standards.

3. More Demand Partners Sending Bids

Unlike browsers that have a limited number of network connections they can make at one time, server-side header bidding can be set to send bid requests to as many buyers as the publishers want. The result is better ad yield and higher fill rates for publishers and more scale for advertisers.

Cons of Server-Side Header Bidding

1. Lack of Control and Transparency

While the floor price in an auction is set by the publisher, the publisher can’t choose the buyers. The auction process remains “hidden” on the server.

With client-side implementation, publishers can choose the buyers using the header-bidding wrappers. However, server-side doesn’t offer such transparency for publishers.

2. Harder to Identify Users

Server-side header bidding lacks cookie matching, as most user data is filtered when moved to a server. In one such case, Ranker, a crowd-sourced polls website, saw a 25% decrease in revenue with a server-to-server header-bidding setup.

3. Adoption and Trust

Server-side header is the newer implementation method and still raises many concerns of publishers and advertisers. It will take some time before it is fully accepted and widely implemented in the online advertising industry.

Google’s Response to Header Bidding

Google couldn’t simply allow the opportunity to pass and not come up with its own solution. Google’s Exchange Bidding Dynamic Allocation (EBDA) is a response to the increasingly popular header bidding – it solves page-latency problems and comes with Google’s support as one of its main selling points. Google also emphasizes the fact that exchange bidding allows publishers to consolidate billing and payment.

Google’s exchange bidding is a direct response to server-side header bidding, available to certified partners exclusively.

Also, Google manages and controls the process for publishers, causing transparency issues. On the plus side, publishers can get the benefits of header bidding without doing the legwork, as Google manages everything for them (even the payments).

Server-Side or Client-Side Header Bidding – Which Is Better?

The choice between client-side and server-side header bidding is a decision for publishers, and should be hinged on the specifics like inventory type, demand, and current market trends.

As both implementations come with their own advantages and disadvantages, the best way forward for the publisher is to test out both implementations and see what it does for revenue in the longer run.