Supply Path Optimization

This means DSPs will start to look at, for any given publisher, what is the least expensive means to reach that publisher. An SSP that has a higher fee will be more expensive than an SSP that has a lower fee, all things considered. An SSP that purports to be a second price auction and approximates a first price auction (meaning the DSP uses second price optimization but doesn’t benefit from it) will also be more expensive.

Read More

Amazon's Header Bidding

Amazon recently announced a server-to-server header bidding solution. For an overview on header bidding generally, see the previous Lift Letter on the same subject: Header Bidding. This has the potential to be very important in the development of ad tech, so it's worth discussing in more detail.


First, what makes Amazon's solution the most interesting is that it's server-side and transparent. Most header bidding wrappers have client-side javascript code that issues a number of nearly-parallel requests to the endpoints of each header partner. All partners must respond within a timeout, the winning bid is sent to DFP and - assuming no line item in DFP beats it - that ad serves. The challenge is that if you have 8 header partners and 5 ad placements, your browser needs to make potentially 40 header calls before rendering the ads (they can be chunked, so it might not be necessary to do 40). While one request isn't an issue, 40 is. This can materially impact the user experience. But, of course, header bidding democratizes access to the ad server and publishers make a lot more money this way. Several companies have also taken a reluctant position about integrating into other company's headers - Amazon in particular - because of fears about their bids and userdata being stolen by other parties.

Google's preferential treatment of AdX - and the revshare that comes with it - is most at risk with header bidding's proliferation (one could also question the long-term strategic value of DFP if header bidding really catches on, but that's a whole other can of worms). As a result, Google created an exchange bidding program. This is server-to-server protocol where companies like TripleLift would theoretically bid into AdX/DFP. In this implementation, there is no client-side code - just an ad call by the browser. Much like a normal ad exchange, Google would then issue ad requests, but include header partners as well. This means that there are far fewer ad calls on the browser and a much better user experience. But Google takes a revshare here - and currently doesn't disclose the revshare - and thus will likely disadvantage partners against its own demand, and otherwise take a cut. From the perspective of a publisher, it's a better user experience, but Google is keeping much of the upside of header bidding, as opposed to the publisher for client-side opportunities. Google also may keep partners' bidding data. Payment also would need to go through Google, meaning partners wouldn't be able to have direct relationships with publishers. Finally, in its current implementation, Google doesn't support PMP deals through other partners.

Amazon's solution - to some degree - is the best of both worlds. First, it's a server-to-server implementation. This means there is a single request per ad call (it's actually one more ad call per ad slot than Google, but much better). It also means that a publisher could have many more partners without directly impacting their user experience, because the partner requests are made on the server side. Amazon charges the publisher a CPM fee for using its service, as opposed to a revenue share (1 cent CPM) and it allows the partner to maintain a direct relationship with the publisher - meaning there is real transparency on fees.

There are concerns about whether Amazon will actually run honest auctions, or instead prioritize its own bids when it chooses to. This may not be audit-able by the publisher. Further, Amazon may be collecting everyone's bid data, allowing it to be the least it can and potentially undermine overall publisher monetization. Finally, it's unclear that they will support PMPs and the like. 
Google's exchange bidding program is certainly interesting - it opens access to publisher inventory that was otherwise not accessible. That said, it is a markedly worse outcome for us than either client- or server-side wrappers that allow price transparency and direct publisher relationships. It will be interesting to see where this takes the publisher ecosystem, but it definitely increases the value of things like formats, where we can make a unique name for ourselves and truly differentiate. Of course, publisher-direct is always the best - and that's where we always look to be. But technologies like these go a long way to improve our ability to have business relationships with publishers.

Google Server-Side Header Bidding

DFP is the publisher adserver for nearly all of the web. It's a very stable, feature-rich technology at a reasonable price. Being the publisher adserver also allows Google to have a strategic tag-on-page relationship with a high percent of publishers. This led to dynamic allocation - in which Google could route publisher impressions directly for resale in AdX when a publisher's directly sold campaigns were pacing well enough. This, in turn, allowed the publisher to achieve higher monetization while making AdX the preferred exchange. Naturally, folks like Rubicon and OpenX (really, all other SSPs, exchanges and networks) were not thrilled - their only option was to have DFP estimate their yield, which was not very accurate and undermined their value prop.



Through some clever hacking of DFP, SSPs created header bidding - where the dynamic valuation of an impression could be passed into DFP as a line item. This meant publishers could now have multiple exchanges competing for a single impression. For a variety of reasons, this wasn't the ideal outcome for Google. While it didn't fundamentally challenge DFP's prominence, its competitors certainly highlighted Google's reluctance to support header bidding. Further, the more header bidding partners a publisher added to the page, the worse the publisher's user experience became, and the worse DFP appeared as a tool. But ultimately, there was a reality that Google simply couldn't lock everyone out of DFP now that they'd found at least one way in.

As a result of the massive industry support of header bidding, Google recently opened DFP to third party server-to-server demand in DFP. This means that, as part of the dynamic allocation, Google will now make server-to-server calls to find the SSP/exchange that provides the highest monetization. This is a server-to-server call, rather than a client-to-server call in header bidding. So theoretically it's more efficient for an end user because the browser makes fewer calls - and easier for a publisher to implement, because it doesn't have to worry about wrapper tags and changing code on the page. This is a very new program and there are only a couple beta partners. 

That said, there are many in the industry that remain suspicious of Google's motives here or dubious of the product. Rubicon, for example, said "We see our partnership with Google as complementary to innovations in header bidding" - meaning this certainly won't stop their innovations in the header bidding space, having noted that it doesn't include support for deals at the moment. AppNexus, which is now largely in the business of being the anti-Google, said the following, "[i]f Google has finally embraced open dynamic allocation, that’s a good thing for publishers, and we welcome them to the party. If they’re providing tools to help publishers see exactly what’s happening inside their auctions, all the better. If, on the other hand, this proves to be just another measure to create artificial advantages and disadvantages in the market, then it’s the same old game."

So we'll see how this net out, but it seems like this is good news. Header bidding definitely isn't dead, and will likely keep growing for a while - but it appears that there are more and more interesting ways of helping publishers effectively monetize their inventory, which means more opportunity for TripleLift.

Header Bidding

Header bidding - it's all the rage. What is it and why does it matter? 

DoubleClick for Publishers (DFP) is the publisher adserver used by the majority of the web. Its primary objective is to help publishers and their sales team run campaigns that they've sold, according to priorities defined by that publisher. It is not a yield / revenue maximizing solution. By and large, publishers set up campaigns according to strict priorities (campaign priority 1 generally runs before 2, as long as it's eligible, and so forth through the decreasing priorities). Price is not a factor - so even though priority 2 may pay more per impression, DFP will respect the prioritization. For example, sponsorships might run 100% of the time on a page, for a certain number of impressions, regardless of the price.

This presents a challenge for SSPs (e.g. Rubicon, Pubmatic, etc) and other parties (e.g. Criteo, Amazon, etc.) that need to deal with the fact that publishers use DFP, DFP doesn't care about yield, and their mission is maximizing publisher revenue. Further, how could the SSPs compete in a world where they can't submit RTB bids to DFP to express the actual valuation - and preempt certain auctions? This is the problem that header bidding is meant to solve. Specifically, how can publishers maximize their yield in a DFP world focused on relatively fixed priorities that don't necessarily reflect price.



DFP lets you specify certain attributes to be included in the decisioning on the client side. So you could set a certain flag to X and another to Y, and this would influence which ad is delivered - all according to the targeting rules specified in DFP.

With header bidding, SSPs and other participants get a special request before the ad request is sent to DFP. They either hold an auction and value the impression or value it with some approximation. The results are included in the response. In a hypothetical example, there are 3 header bidding partners (Criteo, Rubicon, Amazon [and soon, TripleLift]). Their response is collected on the client by the browser, with a set of keys and values (which here are bids by partner), as well as some data about the ad that won the internal auction of each partner. This is ultimately fed into DFP with the request for the impression. The publisher, in turn, has set up DFP to handle parsing this data and prioritizing partners bids accordingly. As a result, dynamic pricing can influence the prioritization of campaigns and what serves.

It should also be noted that Google has now integrated DFP with AdX, meaning Google has ability to inject dynamic valuation into publisher's adserving, but only allowing their own SSP. Header bidding levels the playing field (to a certain degree).