Programmatic advertising has come a long way since its beginnings. There are several types of programmatic advertising like RTB (Real Time Bidding), Private Marketplace and Direct Deals. In this article, we try to tackle some key questions: what is header bidding, what is header bidding wrapper, and one of its most known implementations, Prebid.js. We look at how and why header bidding gained popularity and why Prebid came into existence. Finally, we explain some technical challenges of both Prebid.js and Prebid Server to help you decide which of these solutions is more suitable for you. Let's look into it!
Header Bidding is an advanced programmatic advertising technique that relies on RTB to get bids from multiple demand partners.
The widespread definition of header bidding is known as a technical solution that allows publishers to offer their impressions to multiple ad exchanges and demand partners at the same time, making competition fairer.
Before header bidding, publishers were relying on waterfall or daisy chaining. Publishers usually have direct deals agreed for their premium inventory, but for the rest of their inventory, they generally use waterfall, which means making another request to the next demand partner until someone buys the impression. Waterfall prioritizes partners based on historical data, for example; highest bid, highest fill rate, lowest latency, etc.
Relying on a waterfall technique has its own pros but it requires more human input, such as adjusting priorities based on the average bid price from previous requests. Header bidding simplifies this because it is all done automatically, as bidding happens while the page is rendered.
In scenarios when publishers work with multiple ad exchanges, header bidding helps with getting the impression value in advance (before ad slots load on the page) instead of relying on the average prices that each exchange paid in the past. This is what makes competition fairer, everyone bidding on impressions in real-time.
One very important aspect is latency improvements since waterfall is using sequential requests when a previous request fails for any reason. In case an ad exchange is not able to provide an ad, the publisher is then forced to either not show an ad or perform another request. With header bidding, this all happens in advance and is known even before the page finalises rendering and everything the system has to do is to decide on a winning bid out of all the bids returned.
Revenue improvement is another important aspect. With the waterfall method, there are pre-defined priorities set up based on previous average bid prices for example. This means the winning bid is not competing with others and may not necessarily be the highest one the publisher could get. With header bidding, the publisher is able to guarantee the highest bid wins.
Lastly, we mentioned that with header bidding the whole demand side now bids against each other, however, it also gives more control to the publisher. By adding special deals or direct deals into the mix, the publisher can influence the way in which the bids compete.
Header bidding wrapper is a solution to overcome different requests and responses from different networks or advertisers. Before wrappers were introduced you would have a different setup for every partner leading to more development time. Site performance was also affected due to more code that had to be executed for each partner request/response.
Prebid, which is an open-source implementation used for header bidding, has a header wrapper, also known as Prebid.js, built on top of it, which provides publishers with more control over partner management, and in a much simpler way. It is the most widely used header bidding "container/wrapper" in the ad tech space with 300+ demand partners integrated. That means it has one of the largest repositories of adapters publicly available online.
Prebid adapters are code modules provided by ad exchanges and demand side partners which are code reviewed, approved, and merged by Prebid developers. These adapters exist to make the integration between publisher websites and demand side platforms simpler than it used to be at the very beginning of header bidding.
Simply put, it means that multiple header bidding solutions are being replaced with a single container/wrapper that is able to work with a range of 300+ partners just by specifying which partners’ adapters you want to work with.
There are two types of header bidding wrappers:
Server-side wrapper or Prebid Server, as its name suggests, happens on the auction server, which is usually the publisher's server. The header script on the user's browser performs an initial call to the server which simplifies the whole header script. The client makes a request and gets a response with a winning bid; everything else is done at the server level. In this scenario, the wrapper adapters developed by ad exchanges and demand partners are written in server-side languages (Prebid supports Go and Java).
In order for ad exchanges and demand partners to be compatible with client and server side wrappers it's highly recommended they write their own adapters for both scenarios.
The advantages of Prebid.js are a much better transparency and visibility in real time, as every request can be seen in the Dev Console the moment it happens.
Another advantage is cookie matching where cookies can be shared directly with demand partners, making this part simpler. In order to use cookie matching via the server side some extra development logic needs to be implemented to leverage this feature.
The main disadvantage of Prebid.js are latency and page loading since all code needs to be executed before the page loads (same would happen with server side bidding but in that case we can leverage async requests which mitigates this problem).
Another disadvantage although not always obvious is “Connections per Domain” and “Max Connections” for a browser. Different browsers have different limits but what can happen here is that those limits can be hit on older browsers, especially if the website uses a lot of demand partners and is opened in multiple tabs.
On the other hand, server-side bidding avoids all these disadvantages but the publisher loses the transparency available with Prebid.js.
Adapters for both can be found on Github:
This can be downloaded from the Prebid website.
Probably most commonly used is the GPT library that is used with Google Ad Manager, but there are other popular ones that can be found on the ad servers support list.
After getting familiar with header bidding and Prebid, it is now time to dive into technicalities. We prepared an example of how to integrate header bidding with EXADS RTB (Real Time Bidding).
The first requirement is that you have a publisher account with an EXADS-powered network. Once you have this you can follow the steps below. For the purpose of this tutorial, we will focus on an integration with a banner ad source.
Once you have a site registered in the network, you can create zones. When creating the zone you need to select the RTB Banner Supply format which can support a variety of sizes like 300x250, 300x100, 300x300, and more.
After selecting the format you need to set up your zone. There are a few options available but the default ones suit most clients. The only thing you need to do is to use your preferred zone name and select the partner, which in our case is going to be Prebid Server.
After you click Create you will be redirected to a screen where you can find your RTB endpoint.
You will need three things to set up your header bidding:
This is all that you have to do on your publisher account, the rest is done on your website.
For your convenience, below you can find links to the Prebid version and adapter files from our public Github repository as well as an example page:
Now you are ready to add header bidding code in the <head> of your website. To make it as easy as possible, we created another Example for you. It consists of two parts, client config, and header bidding code. There is no need to change the header bidding code. You just need to update the client config part by changing zoneId, fid, and siteId to one that corresponds to your zone and endpoint.
Below you will find a fully functional example page with EXADS header bidding integration:
Refresh your page and Voilà, you should be up and running.
This article aims to give you a better understanding of what header bidding and wrappers are, how to implement Prebid.js, and its limitations. Although there are other techniques that are popular, like Waterfall, header bidding is a great option for growing and diversifying your business.
Prebid.js and Prebid Server give you flexibility depending on the amount of inventory you have and things you want to track or the way you want to optimize your traffic. Prebid.js gives you more transparency while Prebid Server enables you to store different kinds of logs that can help you optimize in the future.
The example of setting up Prebid.js with EXADS shows you how easily you can monetize your website. And while you may still require some technical knowledge to get things working, it should help you get a grasp of it and make a decision if Prebid.js suits your business or not.
If you want to kickstart your programmatic advertising, then contact our team and start planning your journey!
Senior BE Engineer
Subscribe to receive via email more information about EXADS and the ad serving market.
The adoption of RTB changed the advertising industry and became one of the most important ways of buying and selling ads. In this article we look at how ORTB made the whole process easier and we touch on key points.
Discover the secrets to successful ad serving in the dating industry! Explore essential strategies, must-have capabilities, and expert insights. Learn how ad servers like EXADS revolutionize user experience and maximize revenue.
Retail media is emerging as a dominant force in digital advertising. Retail Media platforms allow ads and sponsored listings to be placed near the point of purchase and displayed to consumers with a shopping mindset. Find out everything you need to know in our new article.