Header Bidding: The Industry’s Cronut?

craigberlingo"On TV And Video" is a column exploring opportunities and challenges in programmatic TV and video.

Today’s column is written by Craig Berlingo, vice president of product, publisher platforms, at Tremor Video.

I’ve been thinking about cronuts a lot lately. They came out of nowhere, and all of a sudden everyone is talking about them. People line up in New York for hours to get a true Dominique Ansel Bakery cronut.

To be clear, I’m not craving a hybrid croissant-doughnut treat. I’ve just been thinking that ad tech’s latest buzzword – header bidding – is becoming the industry’s cronut.

Header bidding is an increasingly common method in display advertising to compete direct and mediated demand head to head. Publishers put all of their demand sources for display ads on the same footing, allowing buyers to start fighting over it before the page even loads. This enables the publishers to see who will give them the best price for ad slots on the page. The best price wins, no matter where it came from.

The basic laws of supply and demand say the competition should drive up the cost, leveling the playing field and increasing yield for publishers. But a recent study from AdMonsters and Sizmek suggests that the jury is still out on header bidding, with 8.9% of publisher respondents indicating they’ve not seen any revenue lift in using tagless solutions, and 15.3% – the largest segment within the header bidding user set – stating that they are experiencing increased revenue, but not very much.

What’s more is that some advertisers and technology partners are requiring publishers to implement tags in their headers, making more work for the publisher if they want their business. These types of advertisers are likely doing heavy user targeting and benefit by being in the header because they get the "first look" at that precious cookie, yet are ultimately adding to the time it takes the page to load. With consumers already intolerant of waiting and buffering, do we really want to make it worse?

I want to nip this in the bud before it gets out of hand in video.

Header bidding is a workaround that isn’t necessary in video today, and simply forcing yet another display technique on video without serious consideration would be an egregious mistake.

The goal of header bidding is to increase yield in spite of a set of imperfect tools. But most video SSPs already allow publishers to manage demand in a fully transparent priority waterfall and compete demand at a given priority level so that price wins, just like with header bidding. Only it happens within the tool built for this type of transaction, on the server side.

When this works the way it’s supposed to, there’s no negative impact on the consumer experience and the publisher gets the highest yield for its content. A win-win for the viewer and the publisher.

Video content and video advertising by its very nature is a rare and valuable product requiring a considerable investment of time and resources to successfully create and deliver. On the other end of the spectrum is display advertising where there is a huge glut of inventory at low CPMs and buyers are focused on just the user data but not the true user context.  In the case of display, I’m not surprised publishers use header bidding to squeeze every cent out of the marketplace possible. In video, there are higher CPMs and more sensitivity to latency and scarcity, so this does not make sense. Losing impressions due to latency in video is far more expensive.

It’s been said that header bidding is a hack against inefficiencies in the ecosystem. Right now those inefficiencies don’t exist in video. Today when it comes to video, it’s about delivering high-quality sight, sound and motion quickly. Current technologies can do that.

The industry needs to educate itself and understand hot topics. Any feature that improves publishers’ ability to monetize should be supported if it’s in their best interest and improves the end-user experience. Because at the end of the day, no matter how long consumers will wait in line for cronuts, they won’t wait for their content to load.

Follow Tremor Video (@TremorVideo) and AdExchanger (@adexchanger) on Twitter.

5 Comments

  1. Alexander Dean

    A very interesting perspective, and I like the Cronut analogy!
    However, in my opinion the conclusions presented are based on factually wrong claims, and impartial look would lead to a different conclusion.

    Claiming that "price wins, just like with header bidding" with current video SSPs technology is plain wrong. A waterfall approach always gives advantage to one provider over the other, even when it's managed by "performance", because such prioritization is based on averages, not on per-impression competition. This makes a huge difference in the bottom line, because the preferred demand source can very realistically buy an impression for less than demand sources arriving after it in the waterfall. This phenomenon also happens with DFPs 'dynamic allocation' scheme, which has already been shown to be bad for the publisher (as it compares per-impression bids from AdX against network averages).

    Moreover, a huge issue with video ads today is the latency in loading the video stream itself (especially for prerolls). In real-life the delay is in the order of seconds (and easily more than that in mobile environment). Allowing the RTB process to start while the page load, and possibly also letting the video be prefetched, would have far-larger positive impact on user experience than any minuscule delay caused by (asynchronous) header bidding scripts.

    Reply
  2. J Florence

    The article cites a study by AdMonsters and Sizmek regarding header bidding, and says that "the jury is still out" because about 9% of publishers haven't seen revenue lift and 15.3% have seen just a small increased revenue.
    However, looking at the study itself, this seems a little misleading. The study actually indicates that out of publishers who currently use header bidding (44.4% of participants), 66.8% see strong or moderate revenue lift, and only 33.2% see small or no increase.

    Reply
  3. Video latency is nearly non-existent when small segment adjustable bitrate video is employed. Even in territories where bandwidth is scarce, such as Latin American, the delay between clicking a poster frame and the start of smooth play is nearly immediate.

    Reply
  4. julien delhommeau

    I completely agree with Alexander Dean here.
    Comparing the header bidding with current waterfall implementation of video SSP is plain wrong in my opinion, Alexander explained that in great details and I think this analogy is completely missing the point of the header bidding technology, which allows competition on real time basis, while there was, at best, only competition on average value before with the waterfall system.

    Also I think that one way to overcome one of the biggest challenge today in video, which is latency, can be achieved by calling the adServers/SSP before the user watching the content (before the player loaded). This can be done by calling the video ad content directly from the header of the page rather than from the player when needed. It happens to be how header bidding works today for display, so if tech provider where to provide similar approach for video, that would probably solve part of the latency issue as well (pre fetching the best winning ad based on price, caching it, and serving it right away when player is loaded). This is actually very similar to mobile experience where latency is an issue and some player such as AppNexus solved with their header bidding solution (http://adexchanger.com/mobile/appnexus-tosses-its-mobile-header-bidding-solution-into-the-ring/)

    Just like display and mobile evolved from waterfall, to mediation tool and finished with header bidding, I am sure we will see similar pattern for video, where first mediation tools already appeared, and first header bidding technology will probably be out soon.

    Reply

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>