This post is the fourth in our Prebid Expert series! In each installment, we’ll be speaking with someone close to the Prebid project – either as a contributor or a user – and learning about the benefits and best practices of using an open-source header bidding wrapper.
This week, we’re talking to Pieter de Zwart. Pieter is VP of Software Engineering at Rubicon Project, where he oversees the development and integration of strategic company initiatives. Pieter brings more than 15 years’ experience in engineering and technology. Prior to joining Rubicon Project, he held positions at Originator Media, SNOCAP, and Cisco Systems. He holds a B.A. in Mathematics and Computer Science and a M.A. in Software Engineering from Santa Clara University.
How has header bidding changed the way you work?
Thanks for starting with a softball! Obviously, header bidding has changed the industry a tremendous amount. Some of the changes are good, and some are less good – every new technology is going to create new challenges and have unforeseen implications.
Header bidding has been great for the industry in that it lets programmatic demand compete with direct demand. That drives higher yield for publishers and makes programmatic a more attractive channel overall. But there have been other side effects. Header bidding has increased the amount of traffic between the different participants in the programmatic ecosystem, which has increased costs and, in some cases, hurt user experience. People are concerned about those implications and are working to address them, but the benefits of header bidding are unquestionable.
What kind of work has Rubicon Project done with Prebid?
We believe open source technology is the best approach for header bidding integrations, and Prebid happens to be a very good example of open source done right. We’ve worked on the project in several ways. We’ve been contributors, pushed patches, and had lots of conversations with people at AppNexus and elsewhere about what Prebid should be doing. Our goal has been to influence the direction of the project in a positive way, and in a way that keeps Prebid neutral.
To us, neutrality means three key things. First, we believe every demand partner needs to get the same information about what inventory is available. Second, everyone needs to get the same amount of time to answer each ad call whenever possible. And third, we need to make sure that everyone’s bid response is sent back to the primary decisioning system – that is, whatever ad server the publisher uses – and that there’s no siphoning off of data so as to either change the responses of some demand partners or influence their bidding patterns in the future.
We’ve done a lot of work contributing to the product road map as well. For instance, we were actively involved in the development of the DFP Express Module, which allows for simpler installation. As with almost any open source project, collaboration has been extremely helpful in shaping Prebid. There have been so many times we’ve made a suggestion to improve Prebid’s functionality, only to have the idea morph into something bigger and better as we have conversations with more people.
What best practices would you recommend to publishers using Prebid?
As with any open source community, the key is getting involved – especially if you’re planning to build on top of the Prebid architecture. In addition to the Github project, there’s a devoted subreddit and an active Slack organization you can join. This is where open source really starts to shine – you get more participants with diverse viewpoints, who in turn create a more holistic product that’s suitable for a much larger audience. We welcome anyone who wants to join the conversation.
Even if you’re just using the default version of Prebid as opposed to building on top of it, the community is a great resource whenever you need help. It almost becomes a self-fulfilling prophecy: Someone who’s new to Prebid goes to these different communication channels to ask questions, they learn a lot, and in turn they can answer questions when someone else comes along. It becomes this virtuous cycle where the community builds on itself.
What should publishers look for as they decide which demand partners to work with through their header bidding wrapper?
With server-side header bidding, publishers will have the opportunity to work with the maximum number of partners. So, what are the key considerations as they decide whom to add and whom to leave out? Number one is diversity and density of demand. The more DSPs — and agencies and brands – an exchange can access, the greater the impact will be on CPMs and overall revenue. Beyond the number of integrations, other key factors are strength of reporting, customer service, scale of operations, ability to support PMPs as well as OMP, and transparency of auction dynamics and fee structures.
What excites you the most about the future of the header bidding wrapper?
Practically speaking, Prebid 1.0 – an upcoming, major release of Prebid.js – is going to be a big improvement in terms of how a lot of the code is structured. For example, Prebid 1.0 will provide more structure around how bid requests are called in order to prevent anyone from building adapters that slow down the overall performance of Prebid with non-performant code.
At a higher level, what’s interesting to me is the ecosystem that can be built around Prebid given that it’s open source. For instance, lots of companies are building analytics systems for Prebid. That gives publishers far more choice – and higher quality choices – to pick and choose the different modules that make up the best solution for them. Header bidding isn’t a one-size-fits-all model. There’s a long, broad menu, and publishers can customize every element of that menu to their liking.
Want to know more about the future of header bidding? Download our latest white paper to learn everything you need to know, including info on choosing the right demand partners, whether server-to-server is right for you, and more!