I’ve gone over what header bidding is in an earlier post and some of the key differences versus traditional tag based setups, but I’ve always strived to technical bluntness on this site as well, hence the diagram and step-by-step path below. As a point of comparison, it could be a good idea to re-familiarize yourself with how ad serving works and the standard exchange redirect path at this time as well. Note that header bidding is also sometimes referred to as ‘advance bidding’, ‘tagless’, or ‘pre-bid’ integrations.
How Header Bidding Works:
- User requests a website
- Header tag script redirects user to one or many SSPs (or DSPs, or Exchanges)
- User calls one or many SSPs in parallel
- SSPs conduct auction with DSPs and internal network demand*
- DSPs respond with bids*
- SSP determines winning bid value and returns to User
- User passes bid value into ad request and calls Publisher Ad Server
- Ad server determines final line item to serve and redirects User to Marketer Ad Server (let’s assume the ad server determines a pre-bid SSP line item for this example)
- User calls Marketer Ad Server
- Marketer Ad Server returns final creative (via CDN)
- User calls trackback to SSP
* It’s hard to tell if everyone or no one actually runs an auction with their header tags because everything happens quite fast relative to your standard exchange process. My sense is that there is either some kind of estimation process vs. a real auction, or some fancy stuff happening with the SSP’s CDN, but without the product people or engineers from these companies actually telling me what happens it’s impossible for me to know. Here’s hoping a few visit the comments section on this article. The important point is that the SSP determines a value for the impression that the publisher can use in their ad serving decision process. How precisely that happens and if it’s better / worse than the standard auction process is an open question.
Header Bidding Explained: Publisher Perspective
For publishers, header bidding has quite a few benefits:
- Eliminate passbacks – with a header tag integration, you have a signal from the SSP in advance that they want the impression, and have transparency on how valuable that single impression is.
- Flatten your waterfall – managing the order in which partners gain access to inventory is no longer necessary because each demand partner declares how they value the impression up front
- Reduce discrepancies – discrepancies arise through latency, and multi-partner waterfalls are inherently latent
- Better yield management – tag based integrations create inefficiency because they force an average rate to compete with the impression level bids of AdX (if the publisher is on DFP). This setup leaves money on the table with both the SSP and AdX. Consider this: if the SSP is bidding anywhere between $0.50 and $5.00, but averaging $2.00, then AdX will win every impression over $2.00, even if the SSP would have paid far more, because there’s no way to know what the SSP would have paid. Similarly, any impression where AdX would pay less than $2.00 but the SSP would not fill at all, or would fill far below their average is lost revenue as well. Header bidding solves this inefficiency.
- Increase revenue – publishers make more money through all the benefits above; they save the ad serving fees paid on passbacks, they monetize the inventory lost to discrepancies, and they earn the highest rate for their inventory irrespective of demand partner.
Header Bidding Costs
As you can tell, I’m pretty positive on pre-bid, but that doesn’t mean it isn’t devoid of costs:
- Operational setup – Header tag integrations require a much, much heavier upfront lift in terms of trafficking line items. It’s not just a little more work, it’s probably 100X as much work to traffic for most publishers. The benefit is that once setup, publishers likely won’t need to touch those line items in the future like they do to manage the waterfall with a tag setup
- Longer pageload – publishers need to watch their pageload times like a hawk because it’s a well–proven fact that even fractional improvements in pageload result in better user engagement. Header tag integrations therefore require some partnership from often scarce IT resources to both implement and manage.
- Yield risk – the biggest risk I can see for publishers is that it could decrease bids from buyers. Wait, haven’t I been saying the exact opposite this whole time? That flattening the waterfall results in greater bid density and demand liquidity, leading to greater revenue and ultimate nirvana? Yes, the risk is that buyers identify which pre-bid partner allows them to buy for the lowest price and move their demand there. In other words, buyers optimize to the platforms of lowest bid density. Remember, header tag integrations don’t allow the publisher to run their own second price auction across all platforms; they just let the publisher pick the best result out of many second price auctions.
Header Bidding Myths
- Data leakage – I think data leakage is an overblown concern for virtually all publishers because if you sell a significant amount of inventory to the exchange today, you are already exposing all your users to a variety of other platforms, which can know each user was on your site. Unless you are both a highly vertical publisher where visiting your site to begin with is a valuable data signal (perhaps a site that is written exclusively for new mothers, brides to be, or those planning a vacation to a specific destination, etc), and you don’t expose much inventory to the exchange already, header bidding won’t create a new risk by itself.
- Latency – many point to latency as a key problem for header bidding, and it’s true that latency can be a problem if you don’t manage it as part of your setup. However, if you set a specific timeout limit to your header bidding tags, you can cap the amount of latency to an acceptable level. In some cases, your latency may actually improve with a header bidding solution because it may eliminate long daisy-chain setups that are highly latent today but more difficult to measure. Additionally, it’s a smart idea to load all your advertising asynchronous to your content, such that any latency on your ads don’t hold up the site content for the user. To be fair, latency can be a problem, but more on the exchange side, as many providers may not be able to respond with a valid bid unless the timeout setting sits at a certain level. My recommendation therefore would be for publishers to measure response rate at the timeout tolerance as the key metric.
Header Bidding Explained: Buyer Perspective
Header bidding is mostly a sweet deal for the publisher, but there are some benefits to advertisers as well.
- Access to inventory – tag based integrations obscure how much inventory is really out there to programmatic buyers because they can’t see what publishers are using to fill their directly sold business. Header tag integrations generate bid requests for every impression available, giving buyers a much better sense of reach for any given publisher.
- Points of access – not only do buyers see all the inventory that’s out there for a publisher with header bidding; theoretically they can access that inventory from a variety of channels. To be fair this is a risk as well as a benefit because it means the same impression is simultaneously available through multiple marketplaces. If buyers aren’t careful they could theoretically bid against themselves for the same impression.
On the con side for buyers, I don’t see many downsides outside of having to manage the risk of bidding against yourself.
Hi Ben,
Why couldn’t the publisher’s ad server simply bid in the auction (possibly with some deal id)? Alternatively, have the direct sold ads entered into the SSP instead of even having a separate publisher ad server?
I don’t understand why any of this has to happen with the user’s browser in between.
Jaka
Hi Jaka,
The key thing with header bidding is that it allows the publisher to know if there is demand for any given impression in the exchange before they make their ad serving decision. The user has to call the SSP before the ad server so the SSP can read the user’s cookie and value the impression. By doing this, the publisher can work with many different SSPs and not just a single one. If a publisher uses DFP and DoubleClick Ad Exchange, they’re basically doing exactly what you suggest, because DFP has a very tight integration with their exchange, to the point where it’s effectively the same system. But to work with multiple SSP platforms, there has to be a mechanism to have them all compete at the same level, rather than silo-ing them in a waterfall. Header bidding enables that to happen, because the calls to the SSPs can happen in parallel, rather than a sequence.
Hope that makes sense!
Ben
Hi Ben,
The link to ‘how header bidding works’ with header tags is broken. Could you fix that. I am new to your website and as a software engineer in this industry, these posts gives me a larger perspective of where the industry is going.
Thanks, and keep up the good work!
Hi Arun –
Thanks for the notice, and sorry about that. Should be all fixed now.
Thanks,
Ben
Hi Ben,
Great explanation of header bidding. When I first heard about Header Bidding I had the same question as Jaka, but reading your response cleared this up: Header Bidding is all about the in-dependency of publishers from demand side partners.
One question remains for me, a more technical one: Why is the User responsible for contacting all the Demand Partners and deciding which one wins? I think i would be more logical that the User would just request one or more creative(s) from the Publisher Ad Server, which contacts all Demand Partners and deciding the winner. This would move all network communication and decision logic to the Publisher Ad Server instead on the unreliable user device.
Hi Gijs,
Thanks – let me see if I can clear up the confusion. So the user needs to call the auction partners to expose their cookie ID, which is largely how DSPs decide how much to pay (bid) for the impressions that user will see. When I say auction partners, those are the systems that actually have a tag on the publisher’s site. In some cases those systems are SSPs like PubMatic or Rubicon, in some cases they are DSPs like Criteo or A9, but no matter what the case, the user is fetching a bid from each partner.
In effect, they call each system and say, “here’s my cookie ID – based on what you know about my ID, how much will you pay to serve an ad to me?” The user then returns those values to the publisher’s ad server. The reason this can’t be a server to server call between the publisher ad server and the auction systems is because the publisher’s ad server can’t read the auction systems’ cookie ID. A cookie ID can only be read by the domain that set it, so that’s why the user has to make a call to each one of those domains. You might find this article helpful: http://www.adopsinsider.com/ad-exchanges/ssp-to-dsp-cookie-synching-explained/
Now, if the user is calling an SSP, the SSP is making a server side call to other DSPs to get bids for that user, but the difference is that the SSP maintains a cookie sync with those DSPs, so the SSP can pass it’s own cookie ID and the DSP will be able to understand it. The publisher ad server does not do that.
One element of clarification though here – while the user is fetching bids and returning them to the publisher ad server the user is NOT deciding what ad serves and who “wins” their impressions. The ad server still does that, it just now has information on if it should consider the line items setup for each auction system or not. That is, if Criteo returns a bid, then the ad server can consider serving the impression to Criteo, but if Criteo returns a zero bid, then the ad server knows not to consider them for the impression. This is a huge difference from tag based integrations (pretty much what you suggest), because in that case, the publisher’s ad server has no idea if the auction system will pay for an impression or not during the ad decisioning process. Rather, they just have to hope the auction system will be able to fill the impression and at a decent rate. Header bidding changes all that because the publisher now has the knowledge on if the impression is worth anything to the exchange during the ad decisioning process, and therefore enables them to weigh that value against their directly sold campaign opportunities, or other systems like DoubleClick’s Ad Exchange, which will not expose a bid but simply say if they will pay less or more than other opportunities.
Hope that helps provide a bit more detail –
Ben
Hey Ben-
Great article. Thanks for sharing all of this information. I had a two-part follow-up to Gij’s question:
1) Is this cookie-synching process unique to header bidding solutions? In other words, do the demand sources now have way more data about each individual user than if a publisher were to go directly through AdX only, for example?
2) With header-bidding, are publishers still able to send “products” representing individual pieces of ad inventory (such as “homepage” or “run of news”) into the exchange, or is only the cookie ID sent through to the DSPs? In other words, do publishers have more or less control over buyer visibility into ad inventory in this model?
Thank you!
Brendan
Thanks Brendan –
1. Cookie syncing is not unique to header bidding, but is a core component of the RTB marketplace. Virtually all users are the internet are constantly being cookie-synced across a large number of platforms, so just working with AdX wouldn’t impact that process in any meaningful way. AdX does have some unique demand (AdWords) to it that does’t depend on bids from outside platforms, but also clears RTB and Network demand which does benefit from cookie synced users. You can read more about the cookie-syncing process here: http://www.adopsinsider.com/ad-exchanges/ssp-to-dsp-cookie-synching-explained/
2. Publishers can still send additional data into the exchange with header bidding solutions, yes – the RTB protocol remains in place with header bidding, so if a publisher wanted to pass additional key values to bidders via header bidding, they would be free to do so.
Generally speaking, header bidding doesn’t provide any new data to either the publisher or advertiser side, it just provides the data earlier (to the publisher) and on more volume (both to the publisher and advertiser). Now, you could make the argument that knowing full capacity by publisher is a new piece of data on the advertiser side, but I’m not sure that’s all that meaningful from a practical point of view.
Hope that helps!
Ben
Thanks Ben! That all makes perfect sense. I appreciate the reply. Great job on this article this is immensely useful.
Hi Ben, thanks for sharing your knowledge on the subject. This is by far the most comprehensive and well explained article on header bidding that I’ve come across -if not the only. Keep em’ coming!
Best,
Hi Ben. Thank you for the amazing article. Do you know where I can get some code examples about how to implement header bidding with a SSP like Pubmatic and DFP as adserver?
Thanks Bruno – I’d love to help, but I think your best bet is to work with those vendors individually on these setups. It’s not especially complex from documentation I have seen around these sorts of solutions, but it’s also pretty specialized to each vendor, so reviewing official documentation is the way to go. They’ll have to enable your account for this kind of setup anyways, so it’s not something you could do on your own in an automated way just yet.
Hi there,
Great article!
I’m really curious about the impact to page load here. Its one thing to have 1 header tag being implemented to flatten your waterfall but what happens when you get 10 or 15 different ssp’s / advertisers wanting to do the same thing?
Hi Dan,
You raise a great point; in my experience managing timeouts is pretty important, and can have a major impact on how well these solutions work. Now, many browsers will support ten or more concurrent connections at any given time (across many hosts), so you’ll likely feel an impact above ten, but below that you should be able to cap the latency at 500ms and still not see too many lost bids due to timeouts. That’s assuming most traffic is in the continental US. 500ms isn’t nothing, but I also don’t think it’s too much to ask for the monetization benefits. You can also run these asynchronously, so they don’t have to hold up your content from loading (unless again, you max your concurrent connections).
From my point of view, I can see a need for perhaps 5 – 7 header bidding partners, but over ten I’d start to wonder how much benefit there is there to the publisher, or if there was an opportunity to route those in some way. If some partners are only going to bid on Canadian traffic, then don’t fire their request on users in the EU, and so forth. I think with some smart routing and timeout management, the impact to pageload is very manageable.
Thanks for the comment though, as this is an important nuance that I didn’t really cover that well in my original article.
Ben
At the end of the day, and I literally mean “at the end of the 24 hour period” you are going to rate your partners on an avg effective CPM. If this increases that, great. Whether or not they are picking the impressions before or after, does not change this performance metric of your partners. So you’ll continue to manage partners this way.
Reducing discrepancies – this is true with a shorter daisy chain, but if you’re a pub that is doing this, remember that you can still only bill what is presented to you in the buyers reporting UI… which can change and does, so what is being bidded may not be what you’re paid. Just like any normal SSP / Network set up.
Don’t assume because it’s real time that it’s dead on reporting now, because there are no pass backs.
Thanks for the comment, James!
You raise some good points about validating what a platform bids is actually what they pay out. And in fact I’ve seen exactly the risks you highlight play out in market, so they are worth worrying about. This seems to be because some platforms out there that appear to bid based on an internal estimate instead of running an actual auction. That results in situations where the impression doesn’t monetize at the rate a platform says as well as situations where the platform bids but actually can’t fill at all. Publishers need to do the due diligence on their partners to ensure an auction is actually happening to mitigate this risk.
I’m going to disagree with you a bit here though that publishers should rate their partners primarily on average CPM; that’s part of it for sure, but in my view total revenue is more important, and rCPM is superior to eCPM (that might be what you mean, though). Through better allocation, a publisher might see yields stay flat, but fill rise significantly (because every impression is now available to every demand partner at the same time) and improve overall revenue. Even if yield falls, if the increase in revenue significantly exceeds that through better allocation among partners, that can be a major positive. From where I sit there is such tremendous, overwhelming amounts of waste in traditional waterfall setups due to discrepancies once the publisher starts to string together more than two partners that the benchmark is easy to beat. I definitely agree that staying on top of the reporting is critical.
For anyone reading this comment thread, James is the CEO of a very cool ad tech company called STAQ that’s worth checking out for cross platform analytics and reporting needs.
Great article!
It seems like implementing this mechanism requires support in this process on both the SSPs side and the Publisher ad server side, which is different from the traditional RTB process.
Can you elaborate on who are the big players in the market that allow these abilities?
Hi Or,
Thanks! To some degree you are correct in that the SSP needs to provide the script for a publisher to place in their header, and the publisher needs to place that script in their source as well as create a number of line items in their ad server to successfully move toward header bidding. I don’t think that’s all that different from the traditional RTB process, because the SSP would still have to create an ID in their system for the publisher so they know who to pay and that the calls are not fraudulent, and the publisher would still have to traffic the SSP’s ad tag. So I think of header bidding as just a different spin on connecting to RTB marketplaces, but not a meaningfully different relationship between systems.
In terms of who provides header bidding technology, most of the major players support it today. AppNexus, Rubicon, PubMatic, OpenX, and Index Exchange on the sell side, and Amazon and Criteo on the buy side. What I mean by buy side is that Amazon and Criteo can both provide header bidding scripts directly to the publisher and actively pursue that; a buyer really doesn’t see a difference if they are buying through an SSP that has integrated with a publisher via header bidding. They still receive the same kind of bid request, and publishers don’t limit their access to demand in any way if they pursue this kind of integration.
Hope that helps!
Ben
Hi Ben,
Great article, thank you! I have a question related to what happens when the bids are passed to the publisher’s ad server. If there are say 5 HB’s integrated on a publisher’s page and 4 of these bid on the impression, is it a given that the highest bid will be prioritized above the others and win’ the impression? Are the other bids prioritized in order of bid value and under what circumstances would the highest bid not ‘win’?
Thanks
Jack
Hi Jack,
So this depends somewhat on how you setup your line items in your ad server, but theoretically, yes, the highest bid would be selected. So, if there are four different systems bidding on the same impression, something like this would get passed in the ad request parameters:
“bidder_A=1.30|bidder_B=1.50|bidder_C=2.11|bidder_D=2.15”
And, if you setup your line items in your ad server correctly, you would have separate line items for each partner at each value. So you’d have line item 1 targeting bidder A bids at 2.15, line item 2 targeting bidder B bids at 2.15, line item 3 targeting bidder C bids at 2.15, and line item 4 targeting bidder D bids at 2.15. Naturally, you’d have many other line items targeting every other value as well. But, because only line item 4 is eligible to serve to the example impression above, it would be the one that serves. And, the reason that line item would serve over the line item setup to target bidder A bids at 1.30 let’s say is that you’d also have a rate assigned to that line item of 1.30, and a rate assigned to line item 4 of 2.15, with both running at a price priority tier. Because they both run at a price priority setting, the ad server will select whichever eligible line item has the highest rate.
The only circumstance where this logic would break is if you setup line items that target ranges instead of exact values. Many publisher will target dollar or dime ranges so they can setup 1/100 or 1/10 as many line items and reduce the setup effort. But, if that was the case, you’d theoretically have two line items that would be eligible – line item 3 targeting bidder C bids between 2.10 and 2.19 (using a wildcard of 2.1*) and line item 4 targeting bidder D bids between 2.10 and 2.19. Now, because you have two eligible line items that would be setup with the same rate (2.10), you have the possibility that line item 3 will serve even though that bid is actually lower than bidder D’s bid. Because the ad server can’t distinguish which line item will pay more though, it will select between line items 3 and 4 at random.
So this is why it makes sense to setup more line items at more granular slices, but you’ll have to weigh the setup cost vs. the chance for better yield management. The right solution is probably somewhere in between – setup lots of line items where you have lots of bids that are close to each other (maybe between $0 and $2), and then expand to wider ranges for line items that are likely to serve less often.
You could also simplify line item setup by using an open source option to manage multiple bidders like prebid.org.
Hope that all makes sense!
Ben
Hi Ben,
Thanks so much for your response. All makes sense. Just wanted to clarify one point with you. In the example above, I presume that all 4 of the header bidders are at the same priority in the publisher ad server? If, for example, Bidder B was at a higher priority than Bidder D, Bidder B would be allocated the impression. Taking this further, I assume that in order to ‘flatten the waterfall’ and to allocate to the highest value within all Header Bidders, they must be allocated to the same priority, but with ‘price priority’ allocation applied within that overarching prioritization. Can you please confirm that this is the case?
Many thanks again
Jack
Hi Jack,
Yes, you’re exactly right – all those line items in DFP need to run at the same priority, set as price priority type so DFP knows to deliver based on rate and optimize vs. AdX.
Hey Ben,
Great article! This comments thread is very helpful as well.
Wanted to get your general thoughts as a two part question:
1) Do you see header-bidding (or any SSP code implementation outside of the ad server) as a long-term solution for publishers or a temporary hack?
2) What are your thoughts on using an API to pipe in historical SSP pricing data into DFP for example? This is theoretical, but couldn’t you pull in pricing lets say every hour across systems and simply update the price priority # rather than traffic thousands of lines? I figure this method would be less risky as you’re not hardcoding anything ahead of your page content, but I’m sure there are downsides to this approach.
Thanks! And again this is a great article 🙂
Brendan
Hi Brendan,
Thanks! To answer your questions –
1. This is a good one; I can see this one go either way, but my sense is it will be a temporary (though multi-year) solution. Reason being, with all the talk on ad blockers and with some of the latency issues on mobile especially, I envision ad serving and particularly real time bidding connections moving toward a server-side setup. That is, your ad server would just make server side connections to whatever RTB sources of demand you wanted. Couple things are holding that back, though. First is identity – the RTB ecosystem relies quite heavily on the cookie as an identifier and cookie syncing as an identity mapping mechanism. So we’d have to find a way to replace that and I’m not sure what would do it that would work in a server side world. Also, MRC certified ad serving must be done using a client side counting mechanism per IAB standards, so those would have to change as well. Client side counting is really to protect buyers against fraudulent billing, so there could be resistance to weaken that approach. And finally, you need ad servers that are willing to support an open market and connect to whomever you, their customer, would want. I’m a big fan of DoubleClick as a platform (which has the largest market share by far), but one thing you can’t really say about that company is that it’s an open market. In fact, it’s quite the opposite and setup to favor Google platforms above all else. I don’t begrudge them their strategy, but the fact remains it would delay a move to server side connections. DFP would have to change their mind or someone would have to introduce an open platform that significantly displaces DFP, and while either is possible, it’s probably not going to happen quickly.
So it depends on your definition of short vs. long term – I think header bidding is far more than a short term hack, but I also don’t see it as the end solution.
2. To me this isn’t a viable solution, the reason being is because it is still a waterfall. Average performance, even updated very frequently is still an average. The reason header bidding is awesome is because it lets any platform compete impression by impression – and I’ll tell you that I know for a fact that the value of one impression to the next can be significantly different. Think of it this way – let’s say you run a store like Home Depot, and you’re in charge of setting prices for every item in the store. A waterfall setup is like saying, whatever the average price of any item over the last hour was, that’s the price of everything for the next hour. It probably doesn’t matter if your timeframe is an hour or a week, because the quality of your product and the mix of your customers isn’t changing the fast; what matters is that some items in your inventory are worth far more than others. So unless you can think of pricing on an item by item basis, you’re going to lose money. To extend the metaphor, now consider that you have five cashiers, one of which can price item by item and four others that can only sell above your hourly average. Customers can pay that price or walk away. Out of the two types of cashiers, who’s going to sell more items? In a waterfall setup, AdX is the cashier that gets to price item by item, and header bidding is what lets you turn your other cashiers into item by item pricers.
Maybe I stretched that metaphor a bit, but hopefully you get the idea.
Ben
Thank you for the informative article! I had a question — how would header bidding affect direct-sold campaign line items? If 100% of inventory and each individual impression is available to auction, how can we ensure proper delivery on ROS and roadblock/companion programs positions for direct? Thanks
Hi Lana,
Header bidding shouldn’t impact delivery of direct campaigns any more than a waterfall setup; it’s all about how you setup the line item priorities, which remain a completely independent decision from header bidding. For example, if you run all your direct at priority 4 or 6 and as a standard type (I’m assuming you’re using DFP), then enhanced dynamic allocation will ensure your direct campaigns stay on schedule. Similarly, if you setup roadblocks as an exclusive or sponsorship type, those will consume 100% of the targeted inventory. Header bidding doesn’t impact priorities by definition, it simply provides a key-value that you can target for better yield management.
That said, header bidding allows you to improve fill beyond what EDA would produce in my experience if you run programmatic at a higher priority than your standard ads (but obviously behind roadblocks). In my opinion, EDA is much too conservative and ends up delivering lots of standard ads on programmatic opportunities to keep each campaign on even pacing, when there would still have been plenty of inventory to deliver the standard campaigns on other impressions. Now setting things up this way does create delivery risk, and you’d have to actively manage that concern with something like an at-risk report.
But, if you want to be conservative, continue to book direct campaigns as standard, priority 4 / 6 as you would today, roadblocks as exclusive, priority 1, and all your header bidding line items as price priority 12. If campaign underdeliver with that setup, it isn’t because the impressions are going to programmatic, it’s because of other reasons, like you oversold the inventory, your capacity dropped, etc.
Hope that helps!
Ben
Hi Ben,
Do you think it makes sense to timeout the ad server for some time to let the bid(s) come in? What do you think is a reasonable time?
Hi Ben!
Just finished reading the article, now I finally understand header bidding. But I have a question: what if the highest key value is for example, 2.15 and when publisher calls SSP server there is no demand for this inventory based on a key value? Will an ad from SSP which bid 2.15 via header bidding serve instead of an ad from SSP, or will a blank ad serve instead, (assuming publisher doesn’t use waterfall anymore)?
Thanks,
Michael
Hi Michael,
No ad from the SSP can serve without a line item in the ad server targeting that key-value. To take your example, if the SSP bids 2.15 and that is the highest value, then the ad server needs a line item targeting “bid=2.15” or something similar in order to serve that ad to a user. As you might imagine, if you had to create a separate line item for every single bid value, you’d quickly wind up with hundreds or even thousands of line items to create. And in my opinion, line item setup is the biggest cost to the publisher when moving to header bidding.
Publishers can approach in many ways though; many use the wildcard feature in DFP, so that instead of creating ten line items to fill values 1.00 – 1.09, they simply create a single line item targeting ‘bid=1.0*’, with * being a wildcard symbol. That gives you a single line item which can fill any of those values, but still gives you a granular range. Other publishers will even go up to a dollar level of granularity; for example targeting ‘bid=1.*’ which will fill any value between 1.00 and 1.99. This isn’t quite as good as dime or penny level buckets from a yield management point of view, but is still better than just using an average rate as you would in a waterfall. Finally, some header bidding partners will actually pass multiple levels of bid aggregation in their response to make this even easier for the publisher. So for example, some bidders will pass ‘bid_exact=2.15, bid_granular=2.1, bid_general=2.00’, which gives the publisher many values they can target.
To answer your final question though, if a bidder’s value did not qualify for any line item’s targeting, then a different line item in the ad server which did qualify for perhaps other elements in the ad request would serve. The worst case scenario is what you outline; if no line at all were to qualify for the ad request, even a house ad, then yes, a blank ad would serve on the site and the impression would be considered ‘unfilled’ in the ad server.
Hope that helps!
Ben
Hi Ben,
After the bids are returned to DFP, it’ll search for the line item with that bid value (as key-value targeting), right.
My question is – Will Header Bidding Partners’ line items (priority=12) compete with other (by ‘other’, I mean line items other than the ones that belong to Header Bidding Partners) price priority line items that are already trafficked in DFP?
Thanks,
Rohit
Thanks for the post, Ben!
I wonder if you could clarify this for me : If I understand correctly, when a bidder sends the response to the user ( and then forwarded to the publisher), it sends only its bid value.
Now, the publisher knows to call that bidder line item, so that bidder tag is returned to the user ?
If that is the case, who’s to say the bidder will actually fill the request at the given price ? (As the serving itself is done in a disrupted way).
What I mean is that the bidder needs to somehow associate the serving request to the header-bidding request, so I would imagine that an additional value should have been passed by the bidder to the publisher along with the bid value, and that the publisher should pass the bidder tag with a parameter containing that additional value.
Hope it makes some sense.
Hi Rohit,
Yes, all eligible line items as well as any dynamic allocation lines (AdX / AdSense) will continue to compete. For example, if you were to work with two header bidding partners, and partner A bid 2.50 for an impression and partner B bid 2.00 for that same impression, you’d now have two header bidding line items eligible for that impression. However, DFP will also now weigh the highest paying line item from that set (partner A) against what AdX will pay, as well as any other price priority line items and select whatever the highest payer is.
Hope that helps!
Ben
Hi Seth,
You’re kind of correct – it depends on the vendor. Many vendors not only send back their bid, but they send back the creative tag to render as well (the marketer’s tag), such that when the header bidding line item serves, it doesn’t have to call back to the header bidder, it simply renders the creative that the browser already has in hand. Usually, this happens through JavaScript in the header bidding line item’s creative – when the request comes in it not only passes a bid value, but a creative ID parameter that is also present in the response. When the line item serves, it essentially says “go render the creative tag associated with X ID”, which is present in the bidder’s response, and which is still accessible to the browser. You can see examples of this in the screenshots I took of various bidder responses on this article: http://www.adopsinsider.com/header-bidding/header-bidding-implementations-in-the-wild/
That eliminates fill risk entirely (except situations where the user abandons the page before the process can complete), but not every vendor works that way. My sense is the vendors that return a bid but not a creative aren’t really conducting an auction but are rather returning an “estimated” bid that may or may not be real, and may or may not pay that returned rate. That definitely happens, though I would say it’s only with a couple platforms. Important questions to ask though as you consider working with particular partners.
Hope that clarifies!
Ben
Hey Ben,
I find myself returning to your articles as I learn more about header bidding – truly a great source of knowledge. Also, thank you for answering all the questions in the comments as these deepen the knowledge as well.
Two more questions from my side:
1) How does header bidding affect first-look deals of a PMP? Right now a publisher could allow advertisers exclusive access to their inventory, however with header bidding if more than 1 vendor is used, then any deal from one SSP would still have to compete with other bidders, which kinda negates the idea of first-look.
2) With header bidding a lot more stuff that used to happen in the back-end, now happens in the frond-end is is much more exposed (especially if a wrapper is used, where you would even have the last auction in the front-end). Also, it’s not hard to imagine some near future version of header bidding, which, faced with the challenge with replicating all the awesome features that SSPs have (like the before mentioned deal feature), might move even more stuff to the front-end. Do you think this poses a security threat?
Thanks BV!
I’ll try to answer –
1. I think you’re correct on this one; while each bidder should take care of running their auction in the correct manner (respecting whatever custom rules and priorities you might have setup), if multiple platforms are involved then it gets more complicated. I know some vendors will actually return a parameter in their response which will tell you if the auction winner is a deal or not. So, you could setup an additional handful of line items in DFP at a higher priority or with a higher rate that would trump all others to fulfill those cases. In that case you wouldn’t have to create hundreds or thousands of line items because price doesn’t matter. Essentially, if you have a bid with X keyvalue, you are compelled to fill it at any price. Where that would get difficult to manage I think is if you setup first look deals with more than one vendor who happened to want the same impression. If anyone else has ideas around this I’d love to know!
2. Hm, I’m not sure what the security thread would be here, though I haven’t thought about it much. I think the question is maybe too abstract – is there a specific feature you had in mind that you think is especially at risk?
Ben
Hi Ben,
I am seeing some DSPs reluctant to put their header bidder code inside a wrapper solution, vs running side by side with other DSPs (in which case multiple ad calls are made). Why would they be so averse to it– what is the risk on the advertiser side for using wrapper vs no wrapper header bidding?
Hi Elena,
I’ve seen this in the wild as well and I’m honestly not sure. My suspicion is that they don’t want to deal with any support questions around something not entirely their tech, or they fear that the wrapper will do some kind of data collection on their bids which will be used against them.
Naturally I side with the publisher here; it’s the publisher’s site and user experience to protect, so as long as the publisher doesn’t implement in a way that breaks a contractual term, I’m not sure why the bidder should get a say in how they are implemented re: wrappers.
Ben
If a publisher is being conservative and not allowing Direct standard and sponsorship line items to compete with Header Bidding, then does the buyer or buyers truly get to see “all” inventory or only what is available at their priority level?
If you prioritize sponsorship over direct standard and private over open then doesn’t this eliminate the advantage of HB?
Hi Rose,
To answer your first question, yes the buyers would still have the opportunity to bid on all impressions, they just wouldn’t have the opportunity to win all impressions. To the buyer, it wouldn’t be clear if they lost because they were outbid by another platform, or if they lost because of a guaranteed line items delivered instead.
Even if you were to stack rank priorities the way you describe, you’d still get plenty of value from header bidding, because you’ll get more accurate dynamic allocation since the ad server will know if an SSP will fill the impression or not (which it couldn’t know with a tag setup) and will be able to weight its true value vs. other price priority line items (as well as AdX), which it couldn’t know with a tag setup either. And, you’d also have the benefit of allowing multiple SSPs to compete in parallel with each other rather than in a daisy chain as you’d have to do in a waterfall.
In my view, most of the value in header bidding is due to this flattened waterfall effect and not as much the improved allocation between direct / indirect.
Hope that helps!
Ben
Can someone please elaborate about the “User calls trackback to SSP” process, Who’s responsabiliy to add the pixel,and how can the SSP receive the win amount ?
Hi Alex,
The callback or trackback pixel is something the SSP automatically injects for it’s own billing / reporting purposes and isn’t something any user has to add. This pixel simply validates that the SSP’s response was rendered by the user, and not dropped during network latency or as a user moved from one page to another. It essentially tracks the discrepancy between user requests and delivered, paid ads the SSP was able to serve.
Hope that helps –
Ben
Hi Ben,
Thanks for the article.
I have a question, what happens if two or more DSP’s returns ad as the header tag calls simultaneously. Does it serve as first come first served.
Thanks,
Sankar
Hi Sankar,
Typically DSPs would respond to an exchange, and would compete in that exchange’s auction. Then the exchange would respond via a header tag to the publisher. That said, it’s a perfectly normal and expected behavior for a publisher to work with multiple exchanges and have to decide between two different header tag responses. Right now, you are correct – the publisher runs a 1st price auction across those responses and simply selects the highest value. Some in the industry have suggested this 1st price auction of 2nd price auctions leads to illogical market dynamics, and I think they are right. That’s why I’d expect there to be a move to handle price reduction in header bidding wrappers so that publishers can run a 2nd price auction across many exchanges at once. The exchanges would submit their 1st prices in this case and the wrapper would handle the price reduction and notification of closing price to the winning exchange. That’s not the reality yet, but is what I’d guess will happen in the next year or so. It makes even more sense if you believe the wrapper tech moves server side vs. client side as it sits today.
Hope that helps –
Ben
Hi Ben,
Thanks for your response. It helps.
Thanks,
Sankar
Hi Ben,
Really appreciate all your help on this. I just want to understand if the inclusion of header bidder for a publisher completely eliminates the need for setting up a Price Priority or Network campaigns. Can a publisher sustain with just the Guaranteed campaigns and Header bidder alone.
Thanks in advance.
Regards,
Siva
Hi Siva,
Yes; for most publishers header bidding price priority line items should be able to replace network deals and waterfall based price priority line items that use an average rate. I see very little consumption on these other types for publishers after they’ve implemented header bidding.
HI Ben,
I have received this email from my Manager and need your help to proceed further.
[long email removed]
Mudassir
Hi Mudassir,
Do you have a specific question? The email you sent over seemed fairly straightforward to me…
Ben
If a publisher configures multiple SSPs like SSP1, SSP2…etc,. Who will pay the publisher and how the payment is calculated when ads are served from multiple SSPs,
Also, Please carify whether ads from SSP1 will be loaded(iframe) under https://ads.ssp1.com and ads from SSP2 will be loaded under https://ads.ssp2.com,
Hi Stuart,
Each SSP maintains its own financial relationship with the publisher, and will get a separate statement and payment from each partner. When the publisher wants to serve an ad from a particular SSP, they have to render a creative file to the user, and when the user loads that file, there’s a call made to the SSP which records the fact that their ad was served and they now owe the publisher payment for that impression.
Re: iFrames, each provider would also draw their own iFrame on the page. In fact, there’s usually multiple iFrames involved as the ad server will typically draw an iFrame, as will the SSP, as will the DSP, and so on as necessary. These are cross domain iFrames or friendly iFrames though – in the case of the former the domains are specific to each party and rely on the PostMessage method in HTML5, and in the latter they all share the same domain.
Hope that helps!