Header Bidding 101: Client-Side Vs Server-Side
Like many other technologies before it, programmatic advertising is constantly evolving, with the overall aim of improving performance and profit. And as the central value provider in media, publishers have seen the sophistication of their monetization strategies evolve alongside it. It transformed trading methods for publishers, from paper insertion orders and faxes to online platforms and algorithms.
But how to prioritize the various direct, and programmatic buyers and campaigns within the ad server? For a long time, the standard for publishers to maximize their yield was the so-called waterfall method (also called daisy chaining). How this worked was to prioritize the various buyers in order, and cascade down each in turn — hence the waterfall.
In other words, the impression would be offered to the one at the top, and if unsold then pass to the next and so on (aka passback). On paper, it sounded great, but the waterfall also had disadvantages. First, it is challenging for publishers to estimate the true value of their inventory by partner at all times, which can ultimately lead to impressions to be devalued, and therefore a loss of revenue. Since buyers apply different bids for every impression, it is impossible to know if the first partner selected in the waterfall is necessarily the one that will bring the most revenue all of the time. Second, passbacks can also create latency. As ad calls are made sequentially they must be passed again and again to each partner in the waterfall, which can impact page loading times, causing a poor user experience. The chart below represents a classic publisher waterfall setup.
Fortunately, header bidding emerged to tackle the waterfall’s inefficiencies. In a header bidding setup, ad calls are made simultaneously — which fosters more competition in real-time, increasing publishers’ yield and CPMs. Technically, it involves adding a header bidding wrapper, also called container — essentially a piece of code — in the header element of a publisher website, enabling them to easily add or remove demand partners
One of the most well-known and popular wrappers in the industry is the open source prebid.js. It was first created and launched in 2015 by AppNexus, but as transparency is a huge debate in the ecosystem, since 2017 prebid.org has acted as an independent organization. You can see below the growing header bidding adoption rates from October 2018 to February 2019.
The different flavors of header bidding: client versus server-side
a. How does client-side header bidding work?
The header bidding wrapper, which is a snippet of Javascript code, is added to the header element of the publisher’s website. Once the page loads, the header wrapper simultaneously calls all of the partners listed, which are usually SSPs. These partners each runs their own auction, sending back to the wrapper their winning bids — which are then transferred to the publisher’s ad server. Finally, the ad server determines the winning line item by evaluating the various bids and serves the ad creative.
Advantages
– Revenue Uplift: Client-side header bidding fosters competition between SSPs, increasing revenues.
– Cookie Matching: Cookie matching is complete as demand partners have direct access to users’ cookies which also results in higher yield.
– Increased Fill Rate: The fill rate increases as more demand partners are added to the wrapper.
– More Control: Detailed understanding of partners’ bidding behaviors and easy reporting on key metrics to further optimize.
Disadvantages
– Page Latency: Page load time increases if too many demand partners are added to the header bidding wrapper, which can result in poor user experience and ultimately lower revenue if users abandon the website.
– Limited Number of Demand Partners: The number of demand partners that can be added in the wrapper is somewhat limited due to the reasons above. In general, the average number of header bidding demand partners is between 3–5.
– Bid Duplication: One of the main potential drawbacks — as the same impression may be available across various demand partners at the same time, resulting in a duplication of bids.
– Heavy Technical Setup: The initial setup is heavy since the wrapper needs to be added to the header and the different line items need to all be created in the ad server.
b. How does server-side header bidding work?
Server-side header bidding works similarly to the client-side variety. The difference being, instead of sending bid requests from the browser, it sends them to the different header bidding partners via an external server, where the auction is held remotely.
The integration process is less time consuming than in client-side header bidding, as only one snippet of javascript code needs to be added within the header tag. When the page loads, that single tag simply calls the header bidding server. The demand partners integrated with the server then run their auctions and the winning bid is determined. The server submits the winning bids to the publisher’s ad server through the same single header tag, and the ad server determines the winning line item and serves the winning creative to the user.
Advantages
– User Experience: Page latency and slow loading times are less of an issue — therefore, user experience is not adversely affected, since the auction is held on a 3rd party server.
– More Demand Partners: Header bidding was first introduced to foster competition between demand partners. Since server-side setups allow more partners to be added, technically that should mean greater pricing pressure and higher revenues.
– Easy Integration: Simple technical setup compared to client-side header bidding, depending on the server side header bidding technology partner.
Disadvantages
– Cookie Matching: As the auction is happening on an external server, instead of the web page header, the cookie match rate is lower, which can impact yields where targeting is not possible.
– Less Transparency: With the auctions happening in an external server, publishers may have less transparency on the revenue share that applies, as well as less control over prioritization of demand partners.
– Bid Duplication: One of the main potential drawbacks — as the same impression may be available across various demand partners at the same time, resulting in a duplication of bids. The risk here is similar to that faced in client-side setups.
Conclusion
To summarize, header bidding gives publishers more power and flexibility to manage different demand partners and increase revenue. However, as with any relatively new technology, header bidding is also far from being complete, or fully featured as yet. If you want to understand more about the next stages of header bidding, and where it will go next, read Rivr’s CTO Moti Tal article recently published in Exchangewire.
Rivr is the first audience yield manager for programmatic publishers. Get in touch to start optimizing your yield on a user level.
