It’s no secret that header-bidding has risen to prominence in the past 3 years. The promise of being able to sell more ad inventory and make more money per impression lured many publishers.

This year, most publishers are selling their ads through header bidding; more than 73% of US websites are using a header-bidding wrapper.

That being said, not all header-bidding wrapper are born equal.

Header bidding wrappers can be categorized into two major groups: Client-side wrappers and server-side wrappers.

Both types of wrappers allow for unified auctions that increase publishers’ ad yields by making advertisers compete for ad impressions at the same time. However, their approaches to doing so vary a bit; which caused client-side and server-side bidding to each have their unique advantages.

Publishers are adopting server-side header-bidding at an increasing rate since the end of last year. That, however, does not mean that client-side meaning is dead; as we’ll explain later.

So, what is client-side header-bidding?

In order to start selling ads through client-side header-bidding, publishers are required to add a wrapper tag (a short snippet of JavaScript code) to their websites “head” section.

The wrapper allows a user’s browser to call different partners in parallel when visiting the publisher’s website. These partners then communicate their bids to the browser before the site is loaded. Subsequently, the wrapper notifies the winner of the auction and sends them a request to serve their creative.

What about server-side header-bidding?

Server-side header-bidding follows a similar process. The main difference between the two approaches being that, instead of the bidding happening on the user’s browser, it happens on the server of the partner.

Why are publishers increasingly adopting Server-side header-bidding?

For a while, Client-side header-bidding was simply called Header-bidding because server-side bidding was not a thing.

The technology initially had a lot of benefits and allowed publishers to significantly increase their ad yield and generate more revenue – large publishers such as the Telegraph were able to increase their programmatic ad-revenue by 70% after implementing Header Bidding.

Just like any other technology, client-side header-bidding had a significant problem: latency.

Due to the computing intensive nature of the bidding process, and because it was all happening on the users’ browsers, the loading speeds of the publishers’ websites became considerably slow.

The decline in performance of the publishers’ websites started affecting their revenue and customer satisfaction levels. A study by the consulting firm Aberdeen Group even found that a one-second delay in page loading time reduced page views by 11% and customer satisfaction by 17%.

Publishers started looking for a solution that would allow them to enjoy the benefit of a unified auction, all while avoiding the loading speed problems that client-side header-bidding caused to some of them.

That why so many of these publishers were quick to adopt server-side bidding.

Because server-side bidding allows publishers to carry out the auction process on the server side, it avoided them the performance loss that client-side bidding entailed.

Server-side bidding also lifted the limitations relating to the number of partners that they could integrate. Seeing that their ad server was handling all of the requests, publishers were able to stop worrying about the linear increase computation complexity that integrating a new partner caused.

Server-side bidding sounds too good to be true, what’s the catch?

Despite its performance benefits, server-side bidding is far from perfect. As a result of the approach’s limited access to the user’s browser, matching user ids between Supply-side (SSPs) and demand-side platforms (DSPs) becomes harder.

With, client-side bidding each SSP have access to the user’s browser, which allows them to use their own data to match their user ids with those of the DSPs (usually through cookie matching).

The decline in match rates that opting for server-side causes usually leads into a slump in buyer interest and thus lower RPMs. That explains why publishers who tested running 100% server-side header bidding did receive up to 40% increase in page speed, but with a decline of 25-30% decrease in ad earnings.

Nowadays, most publishers who use Server-side bidding also implement a client-side bidding wrapper in order to increase their RPMs.

Around 21% of publishers who use Header-bidding have opted for a hybrid approach mixing both client-side and server-side. That will potentially be the case as long as server-side bidding solutions have not figured out a solution to the integration problems and user matching challenges that they are facing.