Server-Side Header Bidding's Potential Effects

Header bidding, as we've discussed numerous times, is transforming the programmatic ecosystem in a dramatic and abrupt fashion. It quickly pushed many exchanges from 2nd- to 1st-price auctions, it compressed SSP margins, it largely eliminated buy-side fees that SSPs had taken, and it has fundamentally lessened the impact of Google's dominant position as publisher adserver of record.  Yet the move from client- to server-side header bidding may precipitate additional changes.

LiftLetters-ServerSide_HeaderBidding.jpg

Client-side header bidding is implemented with javascript code, including Prebid, index and others, soliciting bids from SSPs, which conduct their own auctions with DSPs. Prebid, like many wrappers, has code to adjust the bid prices if they're submitted in gross v net. This means if SSP 1 submits the bids in "gross" (before margin), but takes a 15% fee from publisher later, whereas SSP 2 submits bids in "net" (after the margin), but takes a 5% transparent fee (Header Direct's price and model) from the publisher, it might appear that SSP 1, without adjustment, has more money for the publisher. In other words, if SSP 1's highest bid is $1.00, it would submit $1.00, and beat bids of $0.95, but it would pay that publisher $0.85 later. Absent the gross-to-net adjustment discussed above, the 5% net bid from an SSP like Header Direct, that would come in at $0.95, would lose to the $1.00 (yet really $0.85) bid from SSP 1. Prebid sensibly has the logic to adjust bid prices so that every SSP competes on net (post margin) prices.

Prebid on the client side (and any other client-side header platform, for that matter) is transparent. This means the code that executes the auction, that determines the effective value of a bid, decides the final winning bid to submit to DFP, etc can be inspected by a user. Notwithstanding the fact that AppNexus wrote the initial version of Prebid and is largely responsible for maintaining it, it is easily discernible that AppNexus is given no special advantage in the client-side auction. Ultimately, however, the final auction is handled downstream - generally in DFP. DFP, if you ignore exchange bidding (EB, formerly known as EBDA), would use the value of the client-side auction in determining which "line item" to serve.

The challenge comes when auctions are held in a non-transparent fashion. As discussed above, there is a normalization in Prebid client side between gross and net bids. What the publisher makes on any impression should ultimately control who wins. Yet it is straightforward to imagine this not being the case. In any server-to-server scenario, the code that executes the auction is not visible to anyone but the entity that actually wrote and runs the code - so users or exchanges that have their bids evaluated relative to each other can't make sure it's fair. So using the hypothetical above, if SSP 1 submitted the $1.00 gross bid - it could just pretend that there was no $0.95 bid and say that the $0.85 net bid won, or it could elect to drop its margin to 4% for this one impression and win at $0.96. Either way is bad for the publisher.

In example above, the first way is obviously bad, and borderline fraudulent - the publisher will be cheated out of bids. The second is more subtle but equally bad. While that single impression appears to be have a good result for the publisher, it also means that, with a high likelihood, the entity holding the auction will manipulate its bids the other way - it may take much larger margins on those impressions where there is less competition. This means its average margin will be what it may have negotiated with the publisher, but it's actually costing that publisher money. The publisher would necessarily make more money overall if the exchange took a consistent margin. As a single, obvious example, if SSP1 negotiated a 20% margin, and SSP 2 has a 5% margin, and the following two impressions happen:

Impression 1:

  • SSP 1: $2.00 gross
  • SSP 2: $1.94 net

Impression 2:

  • SSP 1: $2.00 gross
  • SSP 2: $1.00 net

Assuming SSP 1 runs the server side header bidding auction, it knows its gross bids, but it would also know the net bids of SSP 2. It could adjust its net bid to $1.95 (2.5% margin) for impression 1 and $1.25 for impression 2. Between the two impressions, it would pay the publisher $3.20, which would be the same as if it had paid the consistent 20% rev share on all impressions ($4.00 * 0.80 = $3.20). Yet if it had applied a fixed 20% revue share, SSP 2 would win impression 1 at $1.94, and SSP 1 would win impression 2 at $1.60, meaning the publisher would make $3.54, which is $0.34 more than it does in the first example. Thus the inconsistent application of margin would cost the publisher almost 9% of its revenue through these two impressions.

One could argue that any potential losses in revenue like the one discussed above are mitigated by the fact that there is significantly increased competition overall through server side header bidding. While this is true, server-side header bidding represents such a tremendous upside for publishes that can only be realized through transparency and consistent auction dynamics in the downstream auction. All of the challenges discussed above result from either information asymmetry or contractual ambiguity. In the case of information asymmetry, the party holding the server-side auction knows its own gross bids and target margin, in addition to knowing all other net bids. Meanwhile, other parties only know their net bids and win rates.

Shenanigans like those discussed above have been with other shenanigans. For example, some SSPs have moved away from charging a revenue share. Instead, they calculate roughly what their revenue share would make them on a CPM basis, then charge a CPM fee - perhaps across all impressions, as opposed to those they win to reduce the quoted CPM. Prebid doesn't have a CPM fee adjustment mechanism, and definitely not one that would apply equally to won and lost impressions, so the SSP is effectively submitting gross bids as though they were net. While this is silly - the effect may actually be that SSPs through the ecosystem move from a percent of media basis to a CPM fee, which could have dramatic effects.

Movement from percent of media to charging on a fee-per-impression basis is a superficial change that is intended to back into the same overall take (if not more). Yet the change may end up being pronounced for the industry. Utilization models begin to look like SAAS contracts, and may even begin to be structured that way - with tiers and minimums. This trend could result in a series of counter-intuitive effects: 1) publishers and SSPs begin to enter into more fixed-fee type contracts rather than per-impression-filled contracts, 2) publishers would likely limit the number of SSPs that they work with as a result, 3) transparency increases significantly, 4) all bids would be submitted in gross and considered in gross, 5) the ability of the party conducting the server-side auction to adjust the bids in their favor is significantly mitigated. Steps one and two would probably increase SSP valuation by presenting them more as software platforms (yes, they do the same thing and make the same amount, but SAAS companies get higher multiples than media companies), step three is good for the industry as a whole. Finally, four and five result in significantly improved monetization for publishers. While these outcomes are far from guaranteed, they could benefit nearly everyone in the ecosystem.