This post is the first 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 Matt Jacobson. Matt has been a Product Manager at AppNexus for three years, and over the past year, a big focus of his has been leading product development on Prebid.js.
What’s your role as it relates to header bidding?
I’m a Product Manager here at AppNexus on our tagging team within the Publisher Integrations capability, which means that I work on any technology that goes onto publishers’ pages. As part of that role, I’m the product development lead on Prebid.js.
I was actually a late arrival to the project. Prebid was started two years ago by our Engineering Manager Matt Kendall and another Product Manager who’s since left the company. I took over the Product Manager role about a year ago. But I think that me getting started a year into Prebid’s lifetime has been helpful, in that I’ve really been able to put myself in the shoes of a publisher learning about header bidding wrappers for the first time, and objectively assess how easy this wrapper is to use.
For example, one of the first things I did was attempt to build an end-to-end Prebid integration using only our documentation – this is essentially what we are asking new publishers to do. I try to apply that logic to all the other Prebid workflows, even seemingly trivial things like what we name our functions and parameters. It’s an ongoing, iterative process. We’re never going to say, “Okay, this is THE Prebid workflow.” It has to be constantly improving.
What are the biggest benefits to come from the Prebid open-source community?
One exciting aspect is the rate of growth with which vendors build new adapters for Prebid. When I first joined the project, there were about 30 adapters. At that point, we could have confidently said that was the most of all the industry-leading wrappers, and I remember thinking to myself, “Wow, how many more could there be?” But every release cycle, we’re excited to see new ones added, whether they’re supporting basic banner ads or new formats like outstream video. Right now, there are about 75 adapters.
That constant growth really validates the principles we’re trying to design for. In addition to making it easy for publishers to integrate, we also want to make it as easy as possible for new partners to make their demand available through Prebid, or for existing ones to add support for new formats.
It’s also great because with an open-source project, anyone can participate. There are lots of small demand partners out there that only work with a handful of publishers. A company operating a closed solution might not be incentivized to build an adapter for those platforms, but with Prebid, they can build it themselves.
What advice do you have for publishers who want to build on top of the Prebid architecture?
First of all, please reach out to us if you have any questions or suggestions for the project so that we can help you out. If you have the ability to write new code yourself, then go ahead and put it on the Github. We love pull requests, and we commit to reviewing all open PRs for acceptance into the project.
Our basic philosophy with Prebid is that we want to provide the core wrapper functionality, and then enable publishers to build whatever else they need on top of it to fulfill their unique use cases. Any publisher who’s using Prebid in a customized way is a validation of that decision. Plus, a community of hundreds of contributors will always produce more new ideas and incorporate a broader set of use cases to a project than a single team that’s focused on the same set of tasks and ingrained in the same way of thinking, which helps us build a better product in the long run.
Bid order randomization is a great example of that. Back in November, we noticed that publishers were building and implementing their own mechanisms to randomize the order in which bidders were contacted. That wasn’t a feature inherent to Prebid, but seeing people build it themselves made the light bulb go off for us – with our support, it has become a widely used feature.
What should publishers look for as they decide which demand partners to work with through their header bidding wrapper?
The biggest piece of advice I would give is this: Each new demand partner added to your header bidding setup will have a nonzero impact on page performance, so they should be bringing unique demand to the table. When you’re evaluating a potential demand partner, try to get a sense of what brands and advertisers they have relationships with. Make sure they’re not just repackaging your impressions, layering some extra data on top, and sending them back out to the demand partners you already have – that does nothing for you.
You also need to constantly evaluate your existing demand partners to make sure they still ought to be included in your setup. This means looking at things like mean and median response time, bid rate, win rate, and the average CPMs they provide. If you have a demand partner that’s seeing millions of impressions a day, bidding on 10% of them, only winning 1% of those impressions, and taking a long time to respond to calls on top of all that, you should probably remove them.
One last tip on a more tactical level: Make sure your demand partners have a wide server presence worldwide, or at least have servers in regions where your pages are being loaded. If your request to a demand partner has to travel to a data center overseas, that’s hundreds more milliseconds of latency before you get the demand.
What excites you most about the future of the header bidding wrapper?
The new formats we’re expanding into. Even today, the vast majority of Prebid adoption is for traditional banner ad placements. Now that publishers have proven header bidding increases incremental revenue for those placements, the natural next step is to offer support for other media types. We’ve released support for instream and outstream video, as well as alpha support for native. In the not-too-distant future, we intend to support multimedia auctions, through which any combination of banner, video, and native demand will be able to compete to fill a single slot.
Another exciting development people across the industry are talking about is server-to-server header bidding, which can lower latency compared to the traditional client-side setup. Removing the performance barriers that prevent publishers from adding new demand partners opens up huge possibilities. To that end, we recently announced Prebid server, which allows publishers to implement server-to-server header bidding in a uniquely transparent, open way.
Anything else you’d like to say about Prebid?
Header bidding is a seismic shift for this industry, and we’re excited to help as many people benefit with our open source wrapper. There are several projects happening in parallel to make Prebid a better tool, and as usual, we welcome community feedback.