Header bidding is one of the most important parts of the programmatic ecosystem. Its impact cannot be overemphasized and everyone in the industry should understand the ins and outs of what it is, how it works, and what its potential impacts might be. There have been several Lift Letters on header bidding, including an overview of header bidding, discussions of Google's and Amazon's header bidding solutions, a review of the IAB header bidding standard, and it is mentioned in a discussion of supply path optimization. If you are not familiar with header bidding, you should read every one of those links.
Header bidding, at its core, allows multiple SSPs to bid against each other for a given impression. This has been a great boon for publishers as DSPs will be running multiple auctions for the same impression, and their highest bid will be the one that's used, through whichever SSP it works with. Similarly, SSPs have incentives to minimize the bid reduction between the first and second price bids, and come up with all sorts of wonky ways to do so (e.g. DSP-specific floors - meaning a DSP like Criteo that will often bid a very high amount for a retargeted user, assuming there will be bid reduction, would only be able to win over a high amount, like $10. TripleLift does not do this but we are aware that others in the ecosystem do). Having a number of SSPs compete against each other on each auction increases the average clear price overall. Publishers have seen a significant increase in CPMs as a result.
There are several noteworthy themes to think about with header bidding:
1) Diminishing returns. Each additional SSP that a publisher works with in a header bidding capacity has diminishing returns. On the client side, there is increasingly latency, meaning there is a clear, quantitative tradeoff when an additional SSP has negative value due to user retention issues. For server-to-server header bidding, this is less straightforward. That said, given that most demand is substantially the same through the different sources, the 15th SSP is not likely to increase average CPMs by an appreciable amount. It takes time for the publisher ad ops teams to implement block lists, deal with ad quality and similar issues. Thus, even though server-to-server can handle an arbitrarily high number of SSPs, it does not seem likely that it will scale materially above 10 for so or any most publishers, regardless of the implementation. This is compounded by ads.txt making it ever so slightly harder to add another partner.
2) Swinging pendulum. It is likely the case that publishers that have implemented header bidding have already seen the vast majority of the upside that header bidding might have. This means it is unlikely that developments in header bidding (outside of those for mobile app and video, which largely have not been implemented) will materially change a publishers' monetization. Indeed, as we will discuss below, it is possibly the case that the returns from header bidding will decline as supply path optimization (SPO) reduces the number of times that a given DSP competes against itself (read the Lift Letter on SPO for more details).
3) Identity consortia. Client side header bidding has latency problems. Server side header bidding has cookie syncing problems. Identity consortia are emerging to handle the latter problem. The rationale of such a consortium is that every participant would settle on a single ID, derived from a single source, and use that for that as the ID for the user. Thus, instead of requiring every participant sync with every other participant for every user, each participant need only have sync'd with one other participant for that user. The problem, however, is that there are multiple consortia emerging, including those led by DigiTrust, The Trade Desk, and LiveRamp / AppNexus / Index. The first independent and not free, the second is free but based on single participant's ID, and the third is not free but based on LiveRamp's ID - which has additional benefits. It is unclear which will win, if any, but these do present opportunities to resolve the s2s user ID problem.
4) First price. This is a complicated issue. One might expect that the natural evolution of header bidding would be for all exchanges to settle, eventually, on first price auctions. This is because the lower the bid reduction, the higher that exchange's win rate will be in the header, with the limit naturally being a first price auction. That said, it is the case that exchanges are not coordinating this move and DSPs are generally, though not uniformly, not in favor of this change. Many DSPs have derived substantially all of their bidding edge, their UI advantage, or the workflow patterns from the fact that there are second-price auctions. For example, if a DSP exposes the ability to bias up by x% bids for impressions that match a certain targeting pattern - in a second-price auction you don't need to worry about whether there will be actual ROI for these additional impressions, it means you will clear more of those impressions at a rate not much higher, so there will almost definitely be ROI. This is a fundamental difference and it means that many of these DSPs, as part of their supply path optimization, will lean towards exchanges that don't do first price auctions, even if the margins of those exchanges is higher (assuming, of course, the bid reduction is sufficient to offset the higher margin). Some DSPs will develop different algorithms and UX for a first-price world, and some won't. Demand will be adjusted accordingly.
5) Margins. There will be pressure on SSP margins. Even absent any changes in auction dynamics, margins would decrease to increase win rate. Supply path optimization may actually mitigate the impacts of margin pressure. As discussed in the SPO Lift Letter, if DSPs ultimately settle on a single SSP, or even a couple, as opposed to using all of them, the ongoing pressure on that SSP will be less. That said, there will still be ongoing margin pressure due to the need to win in the header - and it is likely that DSPs will periodically sample various SSPs to continually optimize their supply path choices. It is unclear what the impact to DSP margins will be.
6) Algorithmic bid throttling. One tool in the SSP war chest for ensuring that DSPs see the best results in working with them is algorithmic bid throttling. This means that the SSP will use various types of analysis to determine whether or not to send any given impression to any particular DSP. The most straightforward example is not sending fraudulent or bot impressions - DSPs should naturally see improved performance. But more generally, this means only sending the impressions that the DSP has a decent chance of winning, or that would likely perform well. This has a doubly positive impact. First, the DSP's costs for accessing a certain publisher are lower because it sees fewer impressions but hopefully still wins roughly the same number of impressions. Additionally, the DSP would only see higher quality impressions so it wins more from a given SSP and would value the inventory from that SSP more highly.
7) Direct-to-header relationships. We have not witnessed DSPs integrating directly at a material level. There are some entities that have been active, including Xaxis, Criteo and Amazon. There are a couple reasons that this may be the case: 1) DSPs do not have the publisher-facing tools like reporting, brand blocking, etc that publishers require; 2) DSPs do not see a material upside from doing so - the cost of having a publisher BD team may not be worth it; 3) DSPs find some value in working with SSPs, including fraud prevention and algorithmic bid throttling; 4) their focus is simply on other things, like OTT video. It's unclear what the correct answer is, but it simply hasn't been observed to date at a significant rate.
8) Channels. Currently, header bidding is really only in play for web inventory. It is an eventuality that header bidding will catch on for every type of ad, including mobile app, video, etc. Many focus heavily on the notion of a "header" - meaning the <head> tag in HTML, for a reason why it doesn't work in mobile. This misses the point - header bidding, conceptually, is multiple demand sources competing for a given impression concurrently. In the app concept, this will likely be done either through an SDK that performs multiple ad calls, or through some S2S intermediary. But this seems like the most likely next step.