Yieldbot logo

The Open v. Closed Header Bidding Debate

by Mike Siems, VP of Publisher Development
April 28th, 2016

The Ideological Battle of Header Bidding Frameworks

The header bidding framework debate that began last year – and continues to wage today – is not unlike any conflict of ideas. Tech companies are urging publishers to install JavaScript frameworks that simplify the management of header bidding technology. Although there are more than two companies representing frameworks with the publisher community, two rival technology and business philosophies, open and closed  are framing the debate within the publisher community.

What are ‘Open Auction’ and ‘Closed Mediation’ Header Frameworks?

The open auction approach gives data, transparency and control to the publisher. The code can be customized to meet each publisher’s technical, business and data needs.Timeouts and other important technical requirements can be tested and optimized by the publisher on a per bidder basis. There is full demand and price transparency, flexibility and control as all bids go into the publisher’s ad server (typically DFP). In an open approach the publishers maintain a direct price and performance relationship with the header partners plugged in.

On the other side are closed mediation frameworks. Publishers essentially outsource their header bidding to a third party. Some companies do it for free, some charge a fee. The companies offering this approach mediate the auction in a “black box,” determine a winner and send the winning bid into the ad server. It’s header bidding as a managed service. The company mediating the auction collects and stores all of the auction data, and shares it with the publisher in various ways (Excel doc, API feed, UI, etc.). Some of these companies have even offered to host all partner code within an outside server, calling it a “server side” solution. The code is physically removed from the publisher page, and the auction is mediated within an external system.

The Advantages and Disadvantages of Each Framework

A key advantage to the closed/mediation approach is less work for the publisher. Someone else is managing the auctions and answering the tough questions for the publisher. For example, how much latency is acceptable per partner? What timeout should I set? Where do I strike a balance between revenue maximization and latency minimization, per partner, and across the entire auction environment? Also, by removing code from the page, theoretically the server side solution mitigates the latency that comes with header bidding integrations.

In contrast, the developer team of a publisher using an open auction framework must be interested, engaged and passionate about understanding and implementing header-bidding technology in an optimal way. This team typically receives guidance initially, but once they implement the code it’s on them to maintain it, tap into the available analytics and make adjustments as needed. These teams are provided the tools they need to deploy the code in a way that works for their sites, and become header bidding technology and demand experts. Auction analytics / event data, including how fast each partner is making it back to the page and how much each is bidding, is sent to a publisher’s data warehouse of choice. Only the publisher sees this data. They are armed with what they need to make adjustments within the framework on an ad hoc basis.

The closed/mediation camp typically tells publishers to throw all header bidders into price priority, set a timeout and let them battle it out. A key weakness to this approach is that the third party company managing the auction is often also a bidder within it, creating a potential for bias. These companies offer publishers “full audit rights,” but the core, log level data isn’t available to the publisher’s developer team. The auction data being stored in a separate system and being made available to the publisher in a “rolled up” fashion creates a large barrier to transparency.

Also, though  server side approach physically removes code from the page, it creates an extra “hop” between the demand source (DSP, ATD, agency) and the publisher. This causes latency. These companies are recreating the SSP model, and managing all aspects of the demand relationship (technical, business) on behalf of the publisher.  Even if free to start, one assumes as their workload goes up they will start charging either a fee per bidder integrated within the server server, and/ or a fee to the end publisher.

Why Yieldbot Created Pubfood.js as an Open Auction Framework

Over the past months, we at Yieldbot have often been asked, why we released Pubfood as an open framework – including open sourcing of the code. Doesn’t it encourage publishers to add more bidders into the auction? Isn’t going to affect your ability to win impressions? Doesn’t Pubfood encourage publishers to set competitive timeouts which could affect your ability to make it back to the page? The answer to all these questions is that we feel it is up to the publisher to make these decisions and that’s what we wanted to ensure with Pubfood. With Pubfood and other Open Auction/Non Mediated frameworks (Index’s Header Tag is another example), publishers keep control of their media, their buying relationships and their yield.

When you compete as well as we compete what you want to ensure in the marketplace is transparency and fairness. As the company that’s been bidding in publisher headers since early 2012, Yieldbot is striving to preserve an unbiased marketplace where the fastest header bidders representing the most revenue reign supreme in the publisher community. We feel very confident in our ability to compete. As long as the competition is fair not only will our business be successful, so too will the business of publishers and they we can start to win back the trust of consumers. Long live publishers. And long live header bidding!

Contact Us

Download Case Study