It’s been nearly three years since I first wrote about the concept of holistic ad serving – the idea of seamless yield management across sales channels, namely direct sold and programmatic – but in the last six months or so this idea has quietly gone from the drawing board to reality via a mechanism known in the industry as ‘header bidding’, ‘tagless’, ‘advance bidding’ or ‘pre-bid’ integrations because they rely on a piece of JavaScript in the publisher’s header to work. Header bidding is a revolutionary enhancement to the way publishers have historically integrated with their SSP partners, and has wide ranging implications for nearly every part of the RTB ecosystem. The future is now!
Header bidding integrations, or something very close to it have been common for years with retargeting networks like Criteo seeking ‘first-look’ relationships with publishers, but it’s only recently that the major sell side platforms started to integrate this way. The major difference between the retargeters and SSPs is that retargeters have all the demand within their own platform, while the SSPs and Ad Exchanges rely on an auction with external parties to fill impressions.
What is Header Bidding?
Header bidding is a method for publishers to integrate with their RTB demand partners. Those could be ad exchanges, supply side partners, or direct links they might have with DSPs or programmatic networks.
Critically, header bidding integrations allow a publisher to request a bid from each and every partner simultaneously and before they decide what ad to serve. Instead of having many partners fragmented from each other in a waterfall based on their aggregate yield, all demand partners compete for every impression at the same level of priority. Publishers only redirect an impression to demand partners when they bid, so every demand partner now fills at 100% (or should get very close), which eliminates the need for passbacks and pain of high discrepancies and reporting issues that come with them.
A header bidding integration contrasts with a tag-based integration, which has been how a publisher has historically worked with a programmatic demand partner. A tag-based integration is the same thing as 3rd party ad serving. The SSP would give the publisher an ad tag to place in their ad server, which they could then traffic to whatever inventory the publisher wanted. Usually, the publisher would serve out all their guaranteed demand first, and then if there was any inventory left over, they would start calling the SSP’s tag.
There are still 3rd party tags involved with a header bidding integration, but what makes a header bidding integration different is the script in the publisher’s header that “flashes” a user to the SSP without having to serve their 3rd party tag. Let all that sink in for a moment, because the differences are just huge. No more waterfall to manage, no more passbacks, advance valuation from the SSP, the idea that the “winner” of the SSP auction can still lose; it’s a sea change to the way publishers have historically managed the programmatic channel.
How Does Header Bidding Work?
At the core, header bidding integrations work because the publisher requests bids and then waits for a response from all partners before they allow a request to their ad server. The reason this is so important is so the publisher can pass the bid value for that specific impression to their ad server as a key value. Getting the bid value into the ad call is the whole point of this process. For the technical folks out there, yes this works through a piece of in-line JavaScript that is clearly identifiable in the site HTML. If you like, you can go to any website today and easily figure out if the publisher has any header bidding integrations once you know what to look for. That script has to live in the site header, so publishers should be prepared to fight with your IT folks because pre-bid integrations have the unfortunate cost of increasing site load times, albeit to a very small degree – from what I can tell adding about 150 – 400ms, depending on the partner.
With the bid value from each demand partner as a key value in the ad request, publishers can now target specific line items in their ad server to those bid values. Tag based integrations that ran a single SSP tag to “size = 728×90” can now traffic a similar tag to “size = 728×90 AND price = 1.20”. The presence of the bid value in the targeting criteria means the line item will only serve when a demand partner bids. Not only that, but ad ops can set a rate for the line item at the same value as the price variable, which enables the SSP’s tag to compete in a highly accurate fashion with other programmatic partners, including Google’s Ad Exchange, all yield optimized impression by impression through Enhanced Dynamic Allocation. One key element to pre-bid integrations is that the publisher has a choice on whether or not to accept the bid.
Now, if you haven’t realized yet, header bidding integrations also have a cost in terms of requiring far more line items in the ad server. What might have been one run of network line item per ad size with a tag based integration now requires a line item per ad size per bid value – it can easily be hundreds or even thousands of line items to traffic. Some publishers will group bid values into small buckets by using wildcards on the bid values, perhaps dime ranges or dollar ranges (for example, price = 1.1% for every value between 1.10 and 1.19, turning nine line items into one), but the most granular the values, the better the yield optimization.
Where header bidding gets a little complicated is that while it appears to be a universal functionality, and even a specialty among certain platforms like Sonobi or Beanstock Media, each platform does things a bit differently. Some platforms pass exact bid values, some platforms pass simply a “yes” or “no”, some platforms pass a “above average”, “average”, “below average” signal, it’s hardly standardized. This means it’s also not all that straightforward to optimize between multiple header bidding partners. How do you decide between “$1.24” and “above average”?
What’s also unique about header bidding integrations is the bid response from the SSP partners will sometimes contain the exact creative tag to serve, and sometimes will require a redirect to their system like any 3rd party tag. This OpenX patent is one of the only piece of intellectual property I could find on the topic of header bidding, and it mentions the idea of storing the winning creative information in a user’s cookie in section [0095].
Click here to read more about the technical process to how header bidding works.
With the header bid solution would I still need to use a platform such as DFP or one of the others to manage the campaigns or is that simply done within the header bid solution itself?
Hi Brandon,
The main benefit of header bidding is to either manage allocation between directly sold campaigns and SSP demand, or the demand between many different SSPs. So you’d still need a technology like an ad server to do that decisioning process. The header bidding script simply returns data that you can use to make better ad serving decisions, but it won’t do the ad serving for you.
Hope that clarifies!
Ben
Hi Ben,
Could you show me what to paste in the header section of the publisher? Should we paste different SSP tags in parallel or just DFP GPT tag? Not sure exactly how to pass the bid value from different SSPs (Need API integration or not?) for that specific impression to ad server (we have DFP) as a key value. Thanks!
Hi Xi,
You’d have to get a script from your header bidding partner first, and that’s what you’d paste in your source code. Each script is partner specific, so I can’t provide you the code myself. You’ll also have to have your account configured with that vendor to support those requests. Part of that configuration will be a timeout setting, which is important because you’ll have to make your GPT call wait for a response from your SSP.
Once you get the script from your vendor, you’ll also get more detailed implementation instructions that show you how to inject their response as a keyvalue into your ad call. Then, you’ll need to traffic a variety of line items in your ad server that target that keyvalue, and host a creative tag that leverages the pattern macro in DFP. Again, you should be able to get detailed implementation instructions from your vendor here.
Good luck!
Ben
Hi Ben,
Can you tell me what should I look within the website script to find out if the publisher has the header bidder function? In other words, if we support the header bidding as a SSP, how can we identify if the publisher has this technology on site?
Thanks,
Gal
Hi Gal,
That’s a good question, actually – you can do this by either looking at the custom keyvalues being passed to the ad server and / or by looking at the response from any SSP that executes before the call to the ad server. You can view either by using Chrome Developer tools. You’re looking for a block of code that usually has a reference to common ad sizes, like the 728×90, 300×250, etc., a price associated with that size, and then a 3rd party redirect. Usually this comes in the form of a JSON array. The price value should match a variable in the ad request, which means you know the SSP’s bid is being passed to the ad server to facilitate header bidding.
As an example, you could go to CafeMom.com, which was a publisher interviewed about the strategy in this Ad Exchanger article about header bidding and mentioned they work with a number of partners. When I go to their site I can see that they’re working with Rubicon as well as Amazon given what I see in the custom_params and scp keyvalues in the request to their ad server, Doubleclick. Amazon values are being passed in the ‘amznslots’ variables, and Rubicon’s are being passed in the ‘rp_tier’ and ‘rp_cpm’ variables. I can tell because if you look at the response from ‘aax.amazon-adsystem.com’, which is called before Doubleclick you’ll see something like the below, which has values that match those in the DoubleClick call. In this case, Amazon actually connects both the slot and bid price together in a single value, and obfuscates the actual rate with a price tier, which could refer to anything. FYI, I removed the actual redirects in this case to shorten the code:
/* aax response */
amznads.updateAds({
"ads": {
"a1x6p14": “More code here”,
"a728x90p14": “More “code here”,
"a3x6p13": “More” code here”,
"a300x250p14": “More” code here”
},
"ev": true,
"status": "ok"
})
In some cases you can just look at the source code of the page and get a sense, but I find that’s not too reliable because many publishers have these scripts in a tag management solution, so the SSP’s code isn’t actually in the raw source code. You really have to record the output of the page and look through everything that actually renders to figure it out, but after you have a sense of what to took for, it’s not at all difficult. The hardest part is learning how each partner integrates so you know what variables to look for, and what domains they are using to host their header bidding solution.
Hope that helps!
Ben
Hi Ben,
Thanks a lot for your interesting article. We are interested in using this for our site – Is there anyone you can recommend as a partner. We are a publisher and would like to look at this opportunity with a partner.
Many Thanks,
Jurg
Hi Jurg,
Thanks! There are lots of companies that support header bidding – AppNexus, PubMatic, Rubicon, OpenX, Index Exchange, Yieldbot, and others. I would reach out to any one of those (disclaimer: I work for AppNexus), and focus on any where you already have a relationship in place. You may be able to to work with none or all depending on your inventory volumes, content quality, geographic footprint, and other factors.
Good luck!
Ben
Hi Ben,
Thank you for all the information.
A quick question coming from a Publisher perspective.
If we are using say, AppNexus and Open RTB to aggregate our Demand Partners i.e. allowing our demand partners to bid on the inventory we are making available. Why would I integrate them into the header of my page? Am I not achieving the same by directing them to the Auction of my Inventory within AppNexus?
I thought the core benefit was that the demand partners is (1) able to “pull unique information” from the page they might not have access to at time of bid or through the old fashion daisy chain and (2) that the demand partner has more decision time.
As I don’t see why we would want to move “many” demand partners to header load when I can have them all action through a platform in real time. Thanks in advance, RJ
Hi RJ,
There are a few benefits you could see from header bidding – I’d recommend you check out the list of publisher benefits on this article: http://www.adopsinsider.com/ad-exchanges/diagramming-the-header-bidding-redirect-path/ The primary benefits to the publisher are allowing multiple programmatic partners to bid on every impression (because there are no passbacks needed) and allowing other partners to compete with AdX on an impression by impression valuation. To be clear, if you already have every demand source you work with sitting in AppNexus, it would not benefit you to take them out of that system and integrate them directly on your page, but it would make sense to integrate AppNexus directly on your page, which you can do.
There’s no additional benefit demand partners get in terms of data transparency when the publisher is using header bidding vs. a waterfall setup (assuming the demand partners live within a supply partner like an SSP; if you implement them directly on the page then you would expose more detail to them because there isn’t a server sitting between your user and them as there is when an SSP like AppNexus, Rubicon, etc. is in place). From a timeout perspective, that’s a question of your timeout setting on the header bidding tag which can be permissive or restrictive. If you set it to be especially permissive, then you could theoretically see a benefit from increased time to respond, but I would say bidder timeout does not have a significant impact on yield from my perspective.
And to your final question, the reason you’d want many header bidding partners is because each partner can bring a different set of demand to the table. For example, if you were to test three different SSPs on the same exact impression, you would find they all return different values. They might be very close in value most of the time, but they will rarely match exactly. Using many header bidding partners exploits that fact to a publisher’s benefit, and at the same time makes it simple for buyers to access supply across whatever platform they prefer.
Hope that all makes sense!
Ben
Hi Ben,
I’ve recently read a post about header bidding, which implies some rather negative consequences in the long run. The post in question is here:
https://www.linkedin.com/pulse/header-bidding-publisher-revenue-optimization-dilemma-mike-nolet
Do you have any thoughts on it?
Also there was an interesting comment on the post, stating multiple problems down the road for the DSPs:
1)multiplication of QPS for same impression – add hardware
2)dealing with many floors for same impression – time to redesign pricing algos
3)having your pacing algo get gamed – time to upgrade
4)impressions multiplied like this look like botnets – time to try and differentiate bots vs header bidding
5)latency affects response rate on advertising – time to figure out which impressions are low latency and bias $$
6)volume/avail – time to discount publishers which have inflated inventory numbers
7)supply chain integrity – time to calculate risk of URL forgery
Do you think those are valid?
Hi BV,
I read Mike’s post as well and have to say I disagree with a lot of what he said. I was frankly kind of shocked at his take down of header bidding because Mike is such a smart guy and I think he’s just misinformed on this topic. That’s tough for me to say, too because Mike was one of the people who really educated me on the space years ago, and was one of the inspirations for me to start my blog. The core error in Mike’s article is his argument that header bidding fundamentally alters the quality of the inventory.
He says, “Including header bidding changes the quality of the impressions that a publisher sends to a buyer. The first ad-view of a user is much more valuable than the second or third, not because the buyer is willing to pay more but also because a user is more likely to click.” That’s true, but header bidding is simply exposing all inventory to all demand sources, rather than silo-ing it based on the waterfall order. Sure there could be an adjustment in the short term, but the whole point of header bidding is to serve the ad to the highest bidder, irrespective of source.
He also then says, “So let’s say you implement header bidding. Before, premium buyers were getting ad-views 1-5, and then views 6-20 were going into AdX. Now, you implement header bidding and instead AdX only receives views 9,13,16->20. You are now sending lower-quality impressions into AdX.” This was the statement that surprised me in particular because any publisher using enhanced dynamic allocation via DFP today (which is nearly everyone I know) is already sending everything to AdX today. The problem is without header bidding, AdX is the only party that gets that 100% view into inventory. In any case, suffice to say I think Mike’s article is deeply flawed and I hope he comes around, or at least further clarifies these objections.
To some of your other questions – I think some of these are valid, others maybe not so much. The increased QPS is certainly a factor, but that should be a good thing for DSPs, because it gives them access to more quality inventory, or should in theory. DSPs are already processing tons of requests that they bid nothing for, or nearly nothing for. So the transaction costs are minimal to look at bids vs. the opportunity to serve an ad to a valuable user in my view. The pricing concern is real I think, though it’s similarly complex on the publisher side. Remember, the idea is to make parallel calls, not calls in sequence.
The pacing algorithm stuff is also a maybe, it depends how publishers implement. Latency I think will actually get much better – it’s a question of many parallel calls with controllable latency with header bidding vs. sequential calls with uncontrollable latency with waterfalls. Header bidding will look like it is making latency worse, but will actually make it better for many publishers by killing a messy waterfall setup. And the last two; volume and fraud, I don’t really think there’s any change there. In fact, with tags directly on the page it will get easier to police inventory quality and therefore publishers using header bidding will be more trustworthy in my opinion. On the volume question, chances are the volume is already there, it’s just very hard to measure because it’s shattered across so many platforms. With header bidding every partner will see conceivably the entire supply.
Whew, long response – curious as to others’ thoughts on this meaty question as well.
Hey Ben,
Quick question – Will header bidding hurt the ad quality? Any impact on the quality of ads?
Regards,
Avinash
Hi Avinash,
There’s nothing particular about header bidding which would change expectations around ad quality; those controls are still set with your SSP / Exchange.
Thanks!
Ben
Hi Ben,
This was a super enlightening post – thank you for taking the time 🙂 I’m a newly minted product owner focused on ads at a high quality publishing platform, coming most recently from the ad tech space (a native advertising SSP), so definitely reading up about header bidding and programmatic optimization for us here.
We have some SSPs we are starting to get ramped up with, haven’t yet implemented but a previous employee had started the process on getting tags set up. I’m contemplating setting up tests with probably up to 3-4 SSPs in the next month or so and am wondering if header bidding would be a good approach to go out the gate with, rather than implement tags into DFP. We don’t have much yet in the way of direct sales yet (as there is currently one sales rep), hoping to get some deals sold either through DiD or IO based, so I’m focused on getting programmatic channels optimized.
Thanks for all the posts and looking forward to hearing your thoughts 🙂
Val
Thanks Val – I would definitely recommend skipping a tag based approach and going right to header bidding. I should help you optimize between partners much more accurately, and thereby make you more money. If you’ll be working with many providers, I’d also recommend using a wrapper solution such as prebid.js (which I was a contributor to). The downsides I see are you’ll have a slower time to launch with header bidding because the implementation is more complex than just trafficking a single ad tag, and it might limit the number of partners you can work with (for example, it will eliminate working with many networks). But there’s such a clear upside in my mind in terms of revenue that it seems like the obvious path.
Best of luck!
Ben
How can we optimize pricing floor in Header Bidding?
What are the various factors that are to be considered in deciding price floors?
Hi Nishant –
Generally speaking, it’s very difficult to optimize revenue through static floors. A static floor puts a price on a publisher side object, like a tag, when buyers tend to bid based on the user. So a static floor will increase your price, but not your yield. In other words you’ll likely pay more in fill rate than you’ll earn in increased price. Rather, you’re almost always better off setting a $0.01 floor and letting the market determine your price if you just want to make as much money as possible, are a programmatic only shop, and don’t have a direct business to protect. This is especially true for header bidding because you don’t have to worry about a large block of low price inventory skewing the rate at which your RTB line item competes in your ad server, as it would a waterfall tag. If you do have a direct business to protect, then you’ll have to think carefully about what rate makes the most sense given your direct rates.
The other solution is a dynamic flooring solution which many SSPs have built in house. In some cases SSPs can accept a dynamic floor in the request if you wanted to build your own solution, but I’m not sure how widely that’s accepted. This would be my recommendation to you.