Setting up header bidding is now considered best practice for publishers who monetize their sites through programmatic channels. That wasn't always the case. At the beginning, header bidding was best reserved for those who had the development resources to implement the necessary hacks. As header bidding started to take off, increased guidance was required so that both the buy-side and the sell-side could build tech around it. Rubicon Project's Senior Vice President of Seller Accounts, Heather Carver, shared with me how the evolution of header bidding has led to the de facto standards that we all use today.
Rob Beeler: Header bidding was something a lot of people talked about, but it took some time to be adopted. Why?
Heather Carver: The early adopters of header bidding were quite successful and quite vocal about the results. All levels of publishers -- from the long tail to premium publishers -- wanted to participate. The problem was that header bidding at the beginning was complicated to set up and maintain.
Beeler: It was a hack.
Carver: Exactly. It was complicated. Many publishers identified to us that they didn't have the dedicated development resources to launch a header bidding solution. This applied especially to Prebid, which is open source header bidding code and didn't have much documentation.
Beeler: Knowing this, how did Rubicon Project approach header bidding?
Carver: We agreed with the underlying concept behind header bidding of giving everyone equal access to inventory and to compete on a per-impression basis. It also gives publishers the control they need in order to set up their stack in a way that aligns best for their business. If, for example, a publisher wants to prioritize private marketplaces, they can use header bidding technology to control preferred access to their inventory. Standardad serving technologies make this level of flexibility and control more difficult.
Rubicon Project decided to build upon the open source Prebid code. We realized the Prebid narrative aligned very nicely with the industry initiative for more transparency. Open source isn't proprietary and black boxy. The idea of a wrapper is to not advantage one bidder over the other. If you have a proprietary solution that's being paid on just that solution's demand, it creates a situation where the incentives don't align to holistically maximize revenue.
Demand Manager, Rubicon's suite of Prebid tools and services, is our solution to help publishers adopt open source, neutral, independent technology. Technologies like UIs and analytics allow publishers to manage their wrapper without the need of development resources. They can test different timeouts within their wrappers and add and remove bidders from the wrappers that they set up.
There is also a service layer we built on top of Prebid. Part of Demand Manager is to optimize all partners within the wrapper. Instead of just focusing and being incentivized to maximize the Rubicon revenue, the idea of Demand Manager is to help publishers look at all of their bidders and figure out how to maximize revenue across their entire header bidding setup.
Beeler: Where does Prebid.org fit in the rise of header bidding?
Carver: Prebid.org is an independent, neutral organization. It's like the IAB but for header bidding. It sets the rules for how header bidding should be run. You get away from these black box solutions and you have something where it's fully documented. Publishers can now be on the board of Prebid.org, so you have a lot of different people contributing and helping to define the standards for how header bidding should [operate]. There are over 400 different contributors to the Prebid code. When one partner innovates code, all contributors reap the benefits. Other ad tech companies and publishers may contribute code, effectively speeding up innovation. No one is beholden to one proprietary solution's development team or resources to innovate.
As an industry, if we want buyers to feel comfortable investing in digital media, the foundation of that is trust and transparency. Over the last couple of years, Prebid.org has helped Prebid mature and make it easier to adopt.
Beeler: It doesn't sound like a hack anymore. How are Prebid and header bidding evolving?
Carver: Header bidding has definitely come a long way. But browsers aren't meant to process all the code that they are, and publishers are highly sensitive to things that slow their pages down and impact user experience. With that in mind, we want to move the code from the client-side (the user's browser) to the server, which will reduce latency and improve user experience.
One of the crucial pieces of functionality within Rubicon Project's Demand Manager is the ability for publishers to toggle a bidder back and forth between client-side and server-side and to analyze when and where to make that shift without impacting yield.
Identity is also an important evolutionary step. We all know there's not going to be just oneuniversal ID, but Prebid is working on an ID envelope where publishers can choose which ID partners they want to work with. It will really help the industry move away from third-party cookies and toward the use of these universal IDs. That's going to be a very, very big portion of giving publishers the true ability to 100% move to server-to-server and off of client-side solutions.
Beeler: How can Prebid help publishers prepare for the future?
Carver: Changes with how browsers handle cookies and legislation like the California Consumer Privacy Act are going to force the industry to more quickly adopt universal ID solutions. As publishers start testing, they can use Demand Manager to get the insights and manage their stack on their own and figure out how these IDs work. They can safely move over to server-to-server from client-side and recognize all the benefits of moving server-to-server.
The result will be faster pages, better consumer experiences and better monetization.
Click the social buttons above or below to share this story with your friends and colleagues.
The opinions and points of view expressed in this content are exclusively the views of the author and/or subject(s) and do not necessarily represent the views of MediaVillage.com/MyersBizNet, Inc. management or associated writers.