Friday, March 29, 2019

Different Deals versus public (RTB) auctions

Preferred deals offer the following advantages over regular RTB buying on public exchanges:
  • Unique inventory: Preferred deals help buyers gain first-look access to unique inventory they wouldn't normally be able to buy in the open exchange.
    Buyers can also customize which inventory sources to purchase inventory from. The buyer can work closely with the publisher so that they can unlock specific sets of unique inventory (for example, more above the fold inventory). This point is dependent on the system controls and the publisher's ability and willingness to segment out their inventory.
  • Improve yield for publishers: Preferred deals can help publishers capture incremental spends at higher rates.
  • Holistic view of inventory: Buyers can gain a more holistic view of key publisher partnerships when managing them programmatically, and are able to analyze and compare the direct-based buys with the programmatic buys.
Additionally, private auctions allow publisher first-party data to be integrated with programmatic buying.

Preferred deals versus buying reserved inventory

Preferred deals offer the following advantages over buying served inventory:
  • More flexibility: If a deal is not performing well, budgets can be re-allocated more quickly than with a direct or reserve buy. This makes it easier to make sure that spend is flowing towards top-performing inventory.
  • Powerful targeting: Accessing the inventory programmatically provides more targeting controls, including: audience (third-party data integration), geo, dayparting, language, frequency and pacing controls.
  • Efficiency gains: Going programmatic provides workflow efficiency gains. The nature of direct/reserved buys involves paperwork, and ongoing negotiations and budget adjustments. When buying programmatically, once a preferred deal is set up for an advertiser, subsequent campaigns can reuse the deal, assuming the terms of the deal remain the same. Marketplace streamlines and centralizes the back-and-forth negotiation between advertiser and publisher.

Header Bidding vs Waterfall: How the Two Revenue Optimisation Hacks Differ



What is a Waterfall?
Waterfall setup, quite simply, works like this: A ladder of networks and/or exchanges, arranged top to bottom in order of performance to the publisher – based on the networks’ past record in terms of yield (eCPM), fill rate, latency, and more.


The impression(s) is passed from network to network, from the top-down, until it is sold.


This process of redirecting an impression from one SSP/exchange/network to the next and so on until it is sold is called daisy chaining. Yes, waterfall and daisy-chaining are the same.





It’s a matter of prioritization. As you move down the waterfall, the CPM price floors decrease, but there’s also less access to the best inventory for advertisers to bid on. The process theoretically ensured that no inventory was left unsold and fetched a publisher the best price it could.


Theoretically.
So, What’s Wrong with the Waterfall?


First of all, the passback, which is what happens when no one wants the impression at the floor price painstakingly set up by the publisher.


It means that the impression, after making its way across all the demand sources in a waterfall, will be eventually returned to a fallback ad server – typically Google AdSense or Google AdX (for their high fill rates and usually acceptable yields), or run some in-house ads.





This volleying around means high latency (ad loading times). It also sets up the scene for the next big problem. Here’s an excerpt from Adexchanger’s sell sider column explaining the issue:


Publishers daisy-chain supply-side platforms (SSPs). They send an impression to their preferred SSP with a relatively high floor price, then if the impression doesn’t clear, they redirect it to a second SSP with a slightly lower floor price, and repeat the process until AdSense clears the impression at pennies. This (Waterfall) is essentially differentiating demand based entirely on the buyers being unaware that they could buy the same inventory cheaper. This is the ugliest secret in programmatic.


— Ari Paparo, CEO, Beeswax


Then there’s the question of maximizing yield. In a waterfall setup, the bidding for inventory stops when price floor is met. Let’s say that happened at exchange/network 3.


Now, if an advertiser were willing to pay a higher price but was bidding only through exchange/network 4 or 5 (but not 3), too bad. The inventory is sold to a higher priority (and lower yield) buyer.


There’s also a lot of tinkering required to set up the sequence in a way that minimizes latency and produces the best yield, continuously.
That’s Where Header Bidding Comes In


This sequencing of networks and/or exchanges goes away with header bidding. Quite simply, the inventory is up for sale — a “notification” goes out to multiple demand sources (SSPs, networks, or exchanges) simultaneously. Publisher’s ad server collects the bids.


The Demand Source that puts out the highest bid (after conducting a second price auction amongst its own buyers) wins, gets congratulated by publisher’s ad server, and sends the winning buyer’s creative across to be served on impressions bought.


This is also called advanced bidding or pre-bidding. The impression itself is not carried around, just the notification that it’s up for sale (as soon as a visitor loads a web page). The original wrapper tag is named prebid.js after the concept.


Here’s how it works:





Publisher gets to select how many demand sources to plug in (again, keeping fill rate, yield, and latency in mind). The process requires a JavaScript wrapper to work that goes into a webpage’s header tag.


Now, a lot of vendors have come up with their own bidders and adaptors, but here are the five most popular ones, along with number of websites that use them:





When everyone bids at the same time, the value of inventory increases proportionately with the number of demand partners. Publishers typically see 20-50% uplift in yields thanks to header bidding. This is why client side header bidding wrapper really took off in 2016.


That brings us to the next part.