Header bidding is a large component of programmatic advertising. Less than ten years ago, it was unheard of, but now, about 79% of publishers are using header bidding. So what is header bidding? Header bidding is a programmatic advertising technique that allows publishers to offer their inventory to multiple ad exchanges simultaneously before sending requests to ad servers (ie. Google Ad Manager).
Within header bidding, there are two types of implementation methods that a publisher can choose — client-side and server-side. In this blog post, we take a look at each implementation method and analyze the pros and cons of each type. Before we begin, let’s break down what a header bidding wrapper is since both implementations use a “wrapper.” A wrapper, also known as a container or framework, is JavaScript code that organizes all demand partners and sets out rules for the auction like a specific timeout period. The wrapper also ensures that all demand partners bid requests are triggered at the same time.
Now, let’s dive in!
What is Client-side Header Bidding?
Client-side (or browser-side) header bidding involves adding a piece of JavaScript to a publisher’s website in between the tags. This code executes each time a page loads and sends an ad request(s) to a number of demand partners. Then, bids start coming in from their demand partners, with the highest bidder winning the auction and serving their ad.
How does Client-side Header Bidding work?
- 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 auction competes with a publisher’s direct deals.
- The ad server selects the highest bidder and the ad is served (displayed on the page).
What is Server-side Header Bidding?
In server-side, requests are sent from a central server rather than directly from the user’s browser. It offers publishers all the advantages of header bidding, but at the same time saves them from many of the problems that come with it, such as latency.
How does Server-side Header Bidding Work?
- A user opens their web browser and types in the publisher’s URL.
- The browser starts loading the page.
- The JavaScript code located in between the tags executes and sends a request to the server-side header bidding 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 (displayed on the page).
How are They Different From Each Other?
Client-side header bidding (or 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 the 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.
As previously mentioned, server-to-server header bidding involves requests being sent from a server rather than directly from the user’s browser. A publisher is still required to add a piece of JavaScript to their website in between tags, but instead of requests being sent from the publisher’s website and the website hosting the bidding process, a server hosts the auction and manages the bids. This improves the header bidding process for a number of reasons – one of them being reduced latency which we’ll go into in the next section.
Source: Amazon Publisher Services
What are the Pros and Cons of Each Implementation?
CLIENT-SIDE HB | SERVER-SIDE HB | |
PROS | Cookie matching Client-side header bidding has the ability to identify users allowing advertisers to run targeted and retargeted ad campaigns, which ultimately results in more revenue for publishers. Control and transparency By using a wrapper, publishers can easily add and remove demand sources and set bid timeouts. This also gives the publisher the opportunity to see who is bidding and when. Industry standard Client-side header bidding is the go-to implementation for many publishers and advertisers, so there are many ad partners and demand partners who can easily work with this implementation. | Reduced latency With server-to-server header bidding, latency is significantly reduced by moving the header-bidding process off the browser and into a server. The latency may be improved by just a few milliseconds, but the difference is big enough to matter in the overall user experience. Works better for videos and rich media Videos and rich media are already slow to load so switching to server-side can improve the user experience when loading these types of ads. More demand partners bidding While browsers have a limited number of network connections they can make at one time, you can set server-side header bidding to send bid requests to as many buyers as the publisher wants. For a publisher, this means better ad yield and higher fill rates. |
CONS | Latency Client-side header bidding adds a number of scripts in the page header, meaning page-load times get longer and may negatively affect the user experience and result in fewer impressions loaded. Duplicate bids If a publisher connects to multiple header partners, there is a risk in offering the same impression for sale multiple times, which can lead to duplicate bid processing. This can also happen in the server-side implementation, albeit less frequently. 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. | 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. Duplicate bids If a publisher connects to multiple header partners, there is a risk in offering the same impression for sale multiple times, which can lead to duplicate bid processing. This typically happens more frequently in the client-side implementation. Harder to identify users Server-side header bidding lacks cookie matching, as most user data is filtered when moved to a server. |
Which Solution is Better for Publishers?
The choice between client-side and server-side is a decision unique to each publisher. Client-side offers greater control and monetization for standard formats, but lacks in user experience due to latency issues. Whereas, server-side offers a better user experience as latency issues are minimized, but potential risks arise from a lack of control and transparency, with reduced match rates. As both implementations come with their own advantages and disadvantages, the best way forward for a publisher is to see what works best for them.