Navigating the Headwaters of Today’s Header Bidding Options

Open header bidding stacks versus proprietary point solutions – Arel Lidow, VP, product management, Publisher Technology Group, AppNexus (pictured below) argues in favour of the former and lists the benefits. 

Nearly unheard of two years ago, header bidding is ubiquitous these days – to the point where describing how it works feels slightly redundant. The appeal is simple: header bidding enables publishers to work around the disadvantageous auction logic and additional costs of Google’s DoubleClick for Publishers (DFP)/AdX bundling. It provides publishers with greater transparency into the true value of their inventory; it gives them access to demand; it lets them earn more money for the impressions they serve; and, when properly implemented, it helps solve the problem of latency.

But the reality behind it is becoming a bit more complex. Like so many disruptive technologies that preceded it, header bidding has developed into an industry in its own right. Header bidding wrapper code development is now a 'big business', one with its own competing companies, each with its own vision of how its code should operate.

And, with Google’s release of Exchange Bidding in Dynamic Allocation (EBDA), Google itself is tossing its hat into the header bidding ring in an attempt to dissuade publishers from breaking free and keep them tied to its platform.

Basically, header bidding technology now falls into three separate camps: one camp believes that header bidding technology should be open and free, another sees header bidding as a proprietary point solution to be sold, and then there is Google’s EBDA.

When it comes to evaluating EBDA, we have to ask whether it solves the underlying issues header bidding now solves. Does it allow publishers to access any demand source they choose, directly? Will Google impose taxes that hurt publisher monetisation? We don’t know, as Google has not publicly disclosed in detail how Exchange Bidders will compete against its own ad exchange. On top of these uncertainties, and perhaps most importantly, Google reportedly won't allow private marketplaces (PMPs) or deals to run through EBDA.

Unless and until Google can answer these questions satisfactorily, header bidding still offers advantages that publishers cannot afford to forego. This leaves publishers with a choice: open header bidding stacks or proprietary point solutions.

While there are many good proprietary point solutions now in the market, they can limit publisher choice and flexibility. The provider that controls the wrapper code determines with what header bidding demand, analytics, and services partners the publisher can work. Open header bidding stacks, on the other hand, enable publishers to manage their own configurations and control their own monetisation, without sacrificing service and support.

Open header bidding stacks – with four specific parts – offer several distinct benefits.

1. Wrapper technology: This is the code that a publisher needs on its page to manage relationships with multiple header bidder partners. Wrapper code is quickly becoming commoditised; and most wrappers are proprietary point solutions. This means the wrapper provider handles the setup in DFP, integrates with header bidding demand partners, and provides reporting and services. On the other hand, there are a small number of wrappers that are, in essence, a 'public utility' available to any and all publishers through open-source code (two examples include prebid.js and pubfood.js).
2. Header bidders themselves: These are the companies that want access to the publisher’s supply (e.g. Rubicon, Index Exchange, OpenX, AppNexus, and many more). With a proprietary point solution, a publisher is beholden to the header bidder integrations offered, which may or may not include their preferred partners. But, with an open stack, any demand partner can write its own plugin to integrate with an open-source wrapper, offering publishers much more choice. In fact, there are more header bidders who wrote their own code to integrate with prebid.js than any other wrapper solution.
3. Analytics: Because header bidding is a real-time auction, much like traditional RTB (but moved from the server-side into a browser), publishers want to report on similar metrics, such as bid landscape data and latency. In the same way that open stacks provide options among a wide range of header bidding partners, they also allow publishers to choose their own preferred analytics partners, such as Adomik, AppNexus, or Google Analytics, which are all solutions available to work with prebid.js.
4. Services: Some proprietary point solution vendors claim that open-source wrappers provide insufficient service and maintenance, or even none at all. But in fact, open source code and top notch service aren’t necessarily at odds. Many of technology’s most successful platforms were built on the open-source Linux kernel, for example. And, with an open source header bidding stack, a publisher could choose whatever service provider they prefer, whether that is from the open source provider, a third party, or in-house talent.

The beauty of an open header bidding stack is that a publisher can plug and play as they choose. Over time, as publishers become more sophisticated with header bidding monetisation, they might want the option to work with more demand partners, different analytics providers, or a new service offering. With a proprietary solution, if a publisher is dissatisfied with one component of the header bidding stack, they’d have to start all over again. But, with an open stack, publishers own the code, and their integrations won’t disappear if they choose to switch out one component.

The added collaboration, customisation, and liquidity provided by an open stack helps publishers maximise their control and monetisation. After all, isn’t that what header bidding is all about?