Header Bidding Is Just Waterfalling By a Different Name

tomhermanThe Sell Sider” is a column written for the sell side of the digital media community.

Today’s column is written by Tom Herman, CEO at DashBid.

Recently, header bidding has been all the rage.

The technique is supposed to increase revenue, help publishers reassert control in the programmatic landscape, break Google’s DoubleClick Ad Exchange advantage caused by tight coupling with Google’s DoubleClick for Publishers (DFP) and solve problems caused by waterfalling.

However, the way header bidding is being implemented makes it just waterfalling by a different name. Publishers must become more adept at using all the tools of inventory management and yield optimization to truly gain an advantage and make header bidding into a positive development.

The Birth Of Header Bidding And ‘First Look’

In the earlier days of ad tech, publishers that wanted to optimize the price they secured for their ad spots would set them up in a waterfall, a sequential methodology for selling and inserting ads.

In waterfalling, a publisher offers an ad spot to the first in a list of partners. If the partner supplies an ad at the right price and perhaps with the right attributes, the ad is inserted. If there is no ad, the next partner is asked, then the next and so on. That is how most video players with ad integrations operate today. These waterfalls can include your own ad server, direct ad partners, ad networks or exchanges, even multiple real-time bidding (RTB) auctions.

By contrast, when the spot goes right to a single, simple RTB auction, the entire process – from ad call to insertion – should take only a fraction of a second, if it fills at all. Whereas in a waterfall with multiple partners, the process of running through the list can add lots of latency, especially if high floor prices are set.

In header bidding, publishers load code on the page before content is loaded and before the ad server is called. That gives a “first look” at the available spot to preferred buyers before the spot is released to, in most cases, a direct sale, an RTB auction or a supply-side platform (SSP).

And this is the root of the problem.

Return To Waterfalls And Latency

Every buyer, not surprisingly, wants the first look in order to circumvent the open market and get direct access to cherry-pick the publisher’s inventory by being in the header bid code. Every SSP and network wants code on the page so they can get “closer to the end points.” Publishers are often eager to accommodate, and in an effort to secure top revenue are manually putting multiple partners in the code that are then sequentially “pinged” and get a shot at the premium inventory, at a premium price.

Publishers are essentially loading a header-bidding RTB followed by another RTB or SSP. In other words, we’re back to the waterfall.

With DFP competing to stay atop the stack with Google’s new First Look product and SSPs offering header-bidding solutions, we’ve come full circle – yield optimization with a manually managed sequential process.

While there’s no question that a sequence of auctions can yield more revenue, it will also add more time for a page or a video to load. There is a limit to how much latency a publisher should tolerate.

Publishers that use header bidders need a data-driven approach that incorporates a strategic evaluation of their partners. Header bidding wrappers, for example, are one solution that can add customizable rules for a programmatic auction.

Header bidding can be a powerful innovation that benefits all sides, securing publishers more revenue and marketers better inventory. To be effective, header bidding has to be implemented in a seamless, transparent and technologically sophisticated way that doesn’t leave various data points stranded in different silos.

Follow Tom Herman (@tomherman), DashBid (@dashbidmedia) and AdExchanger (@adexchanger) on Twitter.

 

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>