Header Bidding in Advertising

Header bidding — often referred to as pre-bid — was welcomed, around 2015, as a paradigm shift for publishers. It came at a time when the use of real-time bidding was on the rise. More publishers had joined several ad exchanges, only to find out that their performance was still not improving. The reason?

They were still bound by the yearly agreements they had established the previous years, and which, much to their chagrin, they saw themselves as pretty much forced to renew come year’s end.

But let’s take a few steps back and let’s take a glance at this picture from a bird-eye view, shall we?

The Background Story

If, like an eagle, you’d been flying above the publisher’s landscape in 2014, what you would have observed, compared to today, would have been the following:

• Online publishers were operating largely on a free model (Not freemium, not premium). Only a few forward-looking players, such as The Economist, were offering subscriptions. Most other publishers wouldn’t have implemented a paywall yet. Instead, they would offer their content in exchange for advertising only. This is still a very profitable strategy for many small businesses today. 
• Most publishers were tied to yearly agreements with large marketing agencies and their branding clients. Generally, they negotiated such deals at the beginning of the year and for a large sum of impressions, sometimes at a ridiculous CPM price, for the only benefit that the publisher enjoyed a guaranteed income pipeline.
• Open auctions from ad exchanges had come in to erode what little say publishers had on their inventory. Because suddenly, those same brands could buy their inventory, non-guaranteed, for a fraction of the price, through what is called Open auction — basically an auction market for impressions, where advertisers compete on price and publishers are offered limited control by means of pricing minimums (Known as pricing floors) and category-blocking.
• In terms of sales pipeline, yearly agreements were guaranteed, meaning that the publisher, on any given day, would sell those first. Then, if any inventory was left, they would sell it via the open auction.     

Now, let’s put you in the shoes of any of those publishers.

Imagine you have a glowing website, with people flooding in. An advertiser, through an auction, knocks at your door on a Monday morning and says: “May I buy this impression on your page for 10 EUR?” (Note that this is the price per impression, not per thousand impressions).
And you say: “No, I have promised to sell it to my pal Advertiser X for 5”

But would you? I bet not.

And to be frank, neither would publishers in 2014. But in fact, until header bidding and ad server features such as DFP’s Dynamic allocation or Optimised competition (Launched 2017) came along, that’s what they were in the business of doing.

Because you see, header bidding is a programmatic technology that came around to allow the publisher to show the impression first to an open auction and only later to the guaranteed, year-agreement buyer.

The technology came about to allow the publisher, when that same advertiser came knocking, to scream “Hell, yeah”, instead of “Let me look at my guaranteed deals”. But it was also conceived to allow competition to be fair.

In fact, with exchange bidding in place, a publisher could always be sure that the bid from the pre-bid or header bidding auction would be compared to their existing ad server deals — price by price — before a winner would be declared.

What is Header Bidding

Without going too much into details, there are a couple of takeaways you should have gotten so far.

Header bidding is:

• a useful feature if and only if you’re using an ad server
• a useful feature if and only if you’re selling your inventory directly to clients and find that the prices you’re getting through direct deals are on occasion lower than what you would have gotten through a network, an ad exchange, or an auction mechanism
• a complex of features — and in fact — if set up wrong, it can hurt your revenue stream 

If you’re not using or planning to use an ad server, and if you’re not selling inventory directly, what you’ve read so far about header bidding should suffice. You now know what it is, and you can put it at the back of your mind as something you don’t need. Less work for you! 

If, instead, you’re still in the run as a potential header bidding user, let’s go a bit further. 

Have a look at the example below:

Advertiser	Channel	Actual Bid	Bid value as treated by the ad server
Advertiser A	Prebid	5.6	5.5 (Value CPM of the line item* matched to the bid)
Advertiser B	High priority Guaranteed deal in the ad server	—	5
Advertiser C	Price priority deal running through a network, such as media.net or Moneytizer	10	4 (Value CPM set in the ad server for the network price priority line item)
Advertiser D	Ad Exchange priority in Google Ad Manager or equivalent	5.5	5.5

The real question here isn’t even… who wins? Instead, it is, how was the header bidding wrapper set up?

The reason for this question is that while pre-bid sends its bid as 5.6 EUR, that bid still gets in competition with any eligible campaign (or line item) served through the ad server. How? Through an actual line item in the ad server which gets matched to that bid based on bid intervals.

Let’s put it this way. If you were to run a network through your ad server, you would create one non-guaranteed line item (either impressions or percentage-based), with the code offered from that network as your third party creative.

But when you integrate header bidding with your ad server, you’re not creating one line item. Rather, you must create as many line items as necessary to cover the spectrum of bids you want to account for, distributed by intervals. Take a look at the image below.

As you can see, the idea is that all of the bids below a certain threshold, for example, 0.50 EUR, will be matched to a single line item, which in our example is called “Line Item A”, but could be called “Prebid_Line Item_Below 0.50”.

Once a bid passes the Euro mark, it’ll join the heaviest group of bids: here the idea is to be more granular, so that there may be a line item for each .10 cents interval, for example, “Line Item D” in our graphic, which captures bids between 1.10 and 1.20 EUR.

This goes on until the interval where bids are no longer abundant, for example, beyond 5 EUR. In that case, the granularity may be reduced again to one line item per interval of for example, .50 cents.

The intervals are usually set to default to the lower end of the interval.

What does this mean for that 5.6 EUR bid by Advertiser A through prebid that we looked at before?

In simple terms, it means that, if we’ve set up .50 cents intervals, it defaults to 5.5 EUR, assuming the interval goes like this: 5 – 5.5; 5.5 – 6; etc. This is because these are the line items you’ve set up in your ad server for your header bidding bids:

• “Line item K” captures bids higher than 5 and lower than 5.5 EUR
• “Line item L” captures bids higher than 5.5 and lower than 6 EUR

Let’s just spell it out. In this scenario, the header bidding bid doesn’t compete with a value of 5.6. It competes with a value of 5.5.

So, back to our example:

Advertiser	Channel	Actual Bid	Bid value as treated by the ad server
Advertiser A	Prebid	5.6	5.5 (Value CPM of the line item matched to the bid)
Advertiser B	High priority guaranteed deal in the ad server	—	5
Advertiser C	Price priority deal running through a network, such as media.net or The Moneytizer	10	4 (Value CPM set in the ad server for the network price priority line item)
Advertiser D	Ad Exchange priority in Google Ad Manager or equivalent	5.5	5.5

How is your ad server going to treat the bids you’ve got? When there are two bids of equal value competing for the same ad impressions (assuming, as in this example, that they are set to run at the same priority), the ad server would usually select one of them at random.

So, the cost-opportunity in this scenario, for the publisher, amounts to .10c. If the prebid line item by Advertiser A is selected, the publisher cashes 5.6 EUR. However, if the ad server selects Advertiser D instead, the publisher cashes 5.5 EUR.

It doesn’t seem like much, though, doesn’t it? But it can be if you multiply that by the thousands…

And there’s more. You see media.net, there? It was bidding 10 EUR. But who knew? In the ad server, its Value CPM (Average bid value) is set to 4 EUR, ideally, because that’s the result of the end-of-month calculation of media.net’s revenue per thousand pay-out accounting for filled and unfilled bids.

The implication here is that it might make sense to move media.net to header bidding to capture that extra value. In this case, a media.net winner would have paid 4.4 EUR more than the next buyer!

Note that the same line of reasoning applies to whoever is bidding high. It could be The Moneytizer, Adsense, Adform, Rubicon, or any other player. The point is to move to header bidding any network whose bids are coming in with a significant deviation from the average bid value.

However, that’s where one starts running into the danger of overkill. Let’s look at what — if anything — could go wrong with a header bidding solution.

Client-side vs. server-side header bidding wrappers

If you went to the market trying to find a header bidding solution, you would probably be astonished to see that there are tons of them out there. However complex this technology might be, it certainly doesn’t scare off entrepreneurs.

Nonetheless, solutions can be broadly categorized as follows:

	Client-Side	Server-Side	Hybrid
At a glance	This is the industry standard, meaning the header bidding code or wrapper is implemented on the publisher’s website.	This is the newest (but not necessarily best) solution, relying on a central server to send bids from, instead of from the user’s browser.	A compromise between those two, which offers at once the ability to integrate multiple demand partners as a server-side solution but also offers publishers a certain level of control.
Main pros	Control The publisher can at any time change or remove a demand partner from the wrapper, set timeout times for bids, etc.. Cookie matching The technology allows advertisers to identify a user on the page. For example, one who had created a cart on their site and then abandoned it. This is important in that it can lead to higher-value bids.	Minimal Latency It effectively addresses this major cons of client-side wrappers. Higher demand Multiple partners can be put in the competition through the same wrapper, driving higher returns. Best for video and Rich Media Largely because of decreased latency, this solution allows for faster loading of videos, and therefore, better video results	Control and yield management With a hybrid solution, you can select which buyers to give priority to (Those who can compete through a client-side solution) and which ones to only allow through your server-side solution. This means that as a publisher, you can deprioritize buyers who are bidding too low or not often enough. This strategy means your buyers have to tread carefully and keep their game fair. For you, it simply means better returns.
Main cons	Latency Even implementing one client-side header bidding wrapper can make a difference. You do need to add more scripts to your header, and while latency may decrease because of reduced use of pass-backs, you might still see some extra delays in loading speed.  Compatibility with various browsers Because this solution is browser-based, you may run into compatibility issues with some browsers; for example, those that haven’t been updated for ages by non-savvy users.	Little control The publisher sets floor prices, but they cannot get full visibility on the auction process, as this solution is running several sub-auctions against each other  Cookie matching issue Server-side solutions filter most user data in such a way as to prevent the publisher from, for instance, recognizing that this user on mobile is the same person who took a tour of the web last night. Goodbye, retargeting!	Complexity More partners, more channels, more data. You really should be prepared for in-depth, cross-partner analysis if you want to ensure that your yield set-up works properly.   Operational hiccups Using two different technologies at once might cause operational issues. This might put resource constraints on your team and demand a high level of technical expertise.  Lack of transparency Everything you’ll run through server-side will suffer from that same lack of transparency discussed for a full server-side solution. However, in this case, you’ll be stuck with incomplete information. You’ll have enough info on what you run client-side.

How to implement Header Bidding with Advanced Ads

We’ve mentioned it a few times, but it bears repeating. Header bidding is, well, a header solution. It relies on the addition of an extra piece of code in the header of your site.

Thanks to Advanced Ads, adding that code becomes super easy.

To do so, you should first have received the code from the header bidding provider you’ve decided to go for. Do check several providers like OKO ad management before tying the knot, as different providers will most likely entice you with different revenue shares and features. It’s worth shopping around!

Once you have your header code at hand, follow our instructions on how to handle header codes in WordPress with Advanced Ads. Start by creating one ad unit and one placement, as described here: 

1. Go to Advanced Ads > Ads > Create New Ad
2. Select the ad type plain text and code and insert the code which you have copied from your header bidding provider
3. Give your ad a title, e.g., “header bidding code”
4. Publish this ad and create a new placement for it.
5. Go to Advanced Ads > Placements, choose header code placement from the list, and select your ad unit.

Do note that nothing will work until you’ve set up your header bidding partners in your header bidding solution. 

Conclusion

However, you decide to do it, a header bidding solution adds complexity to your stack. Make sure you have the resources and capacity to handle it before you go all in.

Learn about the three header bidding model before committing to one. Possibly, start with an easy client-side setup before you venture forward to one of the other two.

Keep stock of how the solution impacts your revenue, latency, and user experience before making such a set-up even more complicated.

FAQ

Do I need to create separate ad units for my Header Bidding solution?

No, you do not. In fact, if you were to add different ad units solely reserved for header bidding, you would miss the benefits of header bidding entirely. This is because the point of this solution is to have extra bids compete for the inventory you already have, pushing your prices up.

It is not to be a new “network”, like The Moneytizer or media.net, or Adform or even Adsense. Header bidding is conceived to compete against all of those simultaneously by bidding before the auction between them is run in your ad server. Otherwise, all you’re adding to your site is latency.

Will I need to update my ads.txt file after implementing Header Bidding?

Basically, you will. Your header bidding provider should be able to assist you with that. Keep in mind that you will have to add the new partners/technology providers to your current list and not replace your existing one.

Check this article for more information about the ads.txt file.