Server-side Header Bidding: Fewer Complexities, Greater Reliability

box-1198688_1280

Header bidding: the ad tech juggernaut that is now used by over 70% of all publishers. But what considerations should publishers take into account when choosing header bidding containers? Andrew Buckman (pictured below), MD EMEA, OpenX, explains the difference between server-side and browser-side header bidding containers; and tells ExchangeWire that server-side header bidding could reduce complexity and improve ad quality.

Imagine for a minute what the internet would be like if browsers had never moved beyond Mosaic – the first ever graphical browser. With over 4.8 billion webpages, it would be beyond unmanageable. This illustrates that even the most innovative technologies usually require the evolution of further solutions to make them operational, and header bidding is no different.

Header bidding enables publishers to offer inventory simultaneously to multiple demand partners prior to calling their ad server, ensuring they get the best price for each impression. As well as maximising yields, this also enables dynamic pricing and eliminates pass backs. But, as publishers explore header bidding and add new partners to capitalise on the technology, the process becomes increasingly complex. Header bidding containers have, therefore, emerged to organise and manage multiple demand partners. These containers fall into two distinct categories: browser- or client-side solutions and server-side solutions.

So, what are the key considerations publishers should take into account when selecting a header bidding container and how do client-side and server-side solutions stack up against this criteria?

There are six considerations publishers should take into account when selecting header bidding containers:

Firstly, and most importantly, they should think about the user experience. Any solution that increases latency and page load times will have a negative impact and so should be used with caution – however, it is important to note that advertising often has less effect on page load times that the content itself.

Secondly, publishers must assess complexity, both operational and technical. A header bidding container should make adding header bidder partners as simple as possible, and should ensure the header bidder code interacts successfully with the rest of the code on the webpage.

Andrew Buckman | OpenXThe third consideration is reliability. As header bidding is a relatively new technology, and all solutions are unique, publishers should seek a reliable tech partner with the proven ability to manage multiple demand partners over a long period of time.

Transparency is the next factor to think about, and publishers should choose a solution that passes bids from all partners to the ad server simultaneously, rather than passing only the winning bid, which opens up the potential for manipulation.

The fifth consideration is reporting, which becomes increasingly complex as the number of header bidding partners increases; so, any solution should be equipped to deliver consolidated reporting across all partners.

Finally, adding multiple demand partners increases the risk of ad quality issues, so a header bidding container provider should be prepared to address these both proactively and reactively.

Browser-side header bidding containers

Client-side containers sit on the user’s browser and manage demand partners from there. While these containers have functionality to set timeout thresholds, which reduces latency, they don’t improve page load times. Browser-side containers use the internet connection between the user and the demand partners, and rely on Open Browser Calls to communicate with the web. Browsers have a limited number of slots – Google Chrome has just ten – so this can dramatically slow down page load speeds and impact the user experience.

Browser-side containers do reduce operational complexity, making it easier to manage demand partners, without touching webpage code. But, technically, they can add challenges as interactions between partner code and brittle container code can easily lead to the page breaking. As header bidding is a relatively new technology, there are no client-side solutions proven across multiple implementations over a longer period of time, making it difficult to select a reliable provider.

Reporting across multiple partners should be possible for a client-side container, and they can also pass multiple values to the ad server, ensuring transparency. But many only pass the winning bid by default so publishers must request all values when working with this type of solution. Finally, client-side containers don’t guarantee ad quality because, when key values are passed into the server, the container doesn’t know which ad will be served and can’t apply quality controls or restrictions.

Server-side header bidding containers

In contrast to browser-side solutions, server-side containers sit on the provider’s server. A piece of code on the user’s page calls the server, after which the process is no longer dependent on the internet connection between the user and each partner, removing the burden from the browser. Calling each demand partner from the server using a lightning quick connection reduces latency and speeds up page load times, significantly improving the user experience.

Just as with client-side solutions, server-side containers reduce operational complexity, making it easy to bring in new partners, or pause or remove existing partners. But they also reduce technical complexity by leveraging OpenRTB standards that are already well-known and understood throughout the industry. This also makes server-side solutions more reliable, as OpenRTB has a proven track record.

In transparency and reporting the differences between client-side and server-side containers are minimal. Both can pass all values to the ad server to drive maximum publisher yields, and provide robust reporting into bid rates, win rates, and yield by partner. However, when it comes to ad quality, there is a major difference. Using OpenRTB in a server-side solution, demand partners respond not only with a price, but also with the creative they are planning to serve. This allows the proactive application of ad quality standards to prevent bad ads appearing on publisher pages.

Header bidding is revolutionising digital advertising and header bidding containers are an essential element in managing this new technique. By moving the container off the user’s browser and onto the provider’s server, publishers can make use of tried and tested technologies to minimise complexity, improve ad quality, and optimise the user experience.

Comments


  • Gleb Belogortsev

    If server-side container is using Open RTB protocol, then what is the difference between it and SSP? In my opinion, header bidding is more a workaround for cases when RTB integration is not possible.