Let’s cover some very basics of prebid and header bidding in general.
The first thing to know is that header bidding, is a term used to describe the process of running an action, to determine the highest bid for a certain impression, whereas prebid is the actual library you can use to perform this auction.
How Prebid works
Prebid operates on the principle of header bidding, which involves running an auction among multiple demand partners for each ad impression. Traditionally, publishers would use a waterfall auction, where they would offer their inventory to one demand partner at a time in a predetermined order. However, header bidding allows multiple demand partners to bid simultaneously, which can result in higher prices and increased revenue for the publisher.
To use Prebid, a publisher must add a small piece of JavaScript code to their website’s header. This code calls the Prebid library, which in turn requests bids from all of the demand partners that the publisher has configured. The demand partners respond with their bid price and other relevant information, such as ad creative and targeting criteria.
Prebid then runs an auction to determine the highest bid for each ad impression, taking into account any targeting criteria that the publisher has set. The winning bid is sent to the ad server, which then serves the ad to the user’s browser.
Implementing Prebid
There is a real demo here. But here are the general steps.
Include the Prebid library in the website’s header:
This is typically done by adding a script tag to the website’s HTML code.
<script async src="//cdn.jsdelivr.net/npm/prebid.js@latest/dist/not-for-prod/prebid.js"></script>Now the specific partners need to be configured. This requires two parts:
1. Your prebid file should include the bidders you want to work with. This can either be done by using their CLI or by manually downloading a prebid file from here. Do not underestimate this step, as it needs to be done every time you want to add a new bidder or a module (These are out of scope for this article). The downloaded file should be hosted in a public URL, so it can be downloaded by the website, as shown above.
2. Configure the ad units on the page, so the correct parameters are being sent to the demand sources. This step can also be a bit tedious to maintain, as the parameters for each bidder are usually different. An example of a “bid request” from Appnexus could look like this:
{
bidder: 'appnexus',
params: {
placementId: 13144370
}
}Verify the setup
To verify the setup (to get a basic setup running, I would recommend getting the basic example up and running locally), we can check multiple things.
- Check your network tab:
In the network tab, you can see the “output” of the prebid library. This means that everything the prebid library does is to help the site create the correct HHTP request to a demand channel and officiate the auction (this is a bit simplified).
This HTTP request will contain all the information, the demand source needs, to decide if it wants to commit a bid. This includes domain, ad size, user consent, device, etc.
- Use a chrome extension like this. With this, you can directly see if you receive any bids or if anything is wrong
With the above extension, we can verify that our bidders are bidding. So if you see something that looks like the above, you have so far correctly implemented prebid.
3. Use the prebid debug functionality:
By adding the following to your URL, you will instruct Prebid to show a lot of information in the console
?pbjs_debug=trueThe result would be something like this:
Complete the adserver setup (usually Google ad manager)
In the adserver, a few things are missing before you will actually see any of your bids being shown as ads. For Google ad manager, the rough logic is as follows:
- GAM receives the highest bid from prebid, through a key-value.
- This key-value will contain the name of the bidder (let's say Adform) and the actual bid (let’s say 5$). In GAM there needs to be a line item that matches these two keys (Adform with a bid of 5 $). If this line item exists, it will go into the normal ad selection in the GAM engine. In an optimal setup, this means that many hundred line items need to be created in the ad server.
- Adform with a bit of 1$
- Adform with a bit of 1.1$
- Adform with a bid of 1.2$
And so on…
Dependent on the granularity you need, this is a lot of work to set up, even though there exist some open-source projects, that can help you create all these line items.
This is all described in the prebid documentation, but be aware, that there is a certain minimum “cost” when setting up your own header bidding system.
Final notes
I think header bidding is an important piece of technology, that will only grow in the future. It's necessary, to avoid waterfall or passback chains.
That being said, it also requires some maintenance, if you want a good setup. Here are some more advanced features, that most will need to implement if they want to have a “good” setup
- A/B testing, of different settings. This could be timeouts, prebid versions, bidders, etc.
- Prebid server (and monitoring). This is a bit more advanced, but for bigger publishers, this will also be a good idea to test.
- Keep your ads.txt up to date. If your working with external publishers (as ad networks do), this is surprisingly tedious.
- Testing of new bidders. New bidders are everywhere, and while it might be tempting to just add a new bidder, it often requires a bit more work, than just adding a bit to the request (you need to update your prebid file, add new line items in GAM, update ads.txt and more)
- Have full transparency over what you actually make. Even though you can get some rough numbers directly in your own adserver, it can’t be used directly for reporting. Some demand sources have APIs you can connect to, while others can only send you a report daily or monthly :O.
/ Let’s add more demand!
