“Which one is daisy chaining, again?”
“You know. The old one.”
“Right…”
That’s how a lot of conversations about ad tech go. If you’re a web publisher, try explaining how you earn a living through ads to someone outside the industry without getting some confused nod-alongs.
It’s why we came up with a low-pain, jargon-free ad tech primer. You can sign up for it right here.
Awkward social interactions aside, there are two common ways in which inventory can be put up for selective auction. Publishers can automatically set up their impressions to be sold, either via the Publisher Waterfall (aka daisy chaining) or Header Bidding.
In this Header Bidding vs Waterfall post, we quickly review what they both mean.
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.
Header Bidding is Not Perfect
Header Bidding is not free from latency issues and yield optimization raises some very hot questions about second price vs unified auctions.
The chief publisher concern, for now, is latency. There’s a distinct correlation between number of demand sources plugged, the CPM, and loading times.
The real question is whether the latency is significant enough to impact important things like UX and Google rankings.
A year ago, Christopher Reid of Sortable shared some interesting latency data as they tested and optimized their header bidding stack for CPM, viewability, and load times.
CPM increases with no. of demand sources, but so does page loading time.
It’s a well-touted header bidding best practice to keep the demand sources to a select few (think 5-8) to keep latency (relatively) low. The browser is making the calls and too many simultaneous redirects will slow things down exponentially, ruining basic user experience.
Latency is why header bidding is moving server-side (browser makes a single call to SSP, then the SSP takes it from there, making calls to every other demand source from there, collecting bids, picking winners, and getting the winner’s ad to the slot).
Large publishers like Business Insider, Purch, Trinity Mirror, The Guardian, Mashable, etc. are have already moved to server-side header bidding.
Tl;dr
The two programmatic selling techniques have similarities: They both originated as revenue optimization hacks for publishers.
And both waterfall and header bidding (the commonly known version with wrapper tags and the works) are done client side — meaning that the ‘calls’ to demand sources are made on a visitor’s browser.
The key difference is this: In waterfall setup, the calls are made sequentially. In header bidding, they are made simultaneously.
Header Bidding allows premium publishers to sell premium inventory to the highest bidder at scale, rising over one of the biggest limitations of the tedious waterfall setup.
No comments:
Post a Comment