This post is the third 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 post comes to us from Jeremy Blencowe. Jeremy is a Solutions Engineer at Oath in San Francisco. Jeremy studied Computer Science and Artificial Intelligence at the University of Edinburgh in Scotland before escaping the weather across the ocean in California. When he’s not tapping at a keyboard, he’s shredding mountain bike trails across the Bay Area.
How has header bidding changed the way you work?
I’m a solutions engineer at Oath (formerly AOL) leading ONE by AOL display header bidding integrations for publishers in North America, as well as performing troubleshooting and quality assurance. If a customer wants to start header bidding with ONE, I run the process of either plugging us into an existing header bidding integration or helping them get started with the wrapper of their choice. Originally, I did ad server, SSP, and API support, but header bidding has eclipsed everything else I was working on – I do it full time now.
The subtleties of a functioning header bidding integration require a lot more time to set up and test than a tag-based one. If you do it wrong, you’re missing out on potential monetization opportunities in ways that will be difficult to detect and correct. For example, I see a lot of publishers whose line items in the ad server don’t match the granularity settings they’ve chosen in the wrapper – it’s a small error, but it can cause them to miss out on a lot of revenue without even realizing it.
That said, wrappers like Prebid have definitely made the process much faster and easier.
I understand that ONE by AOL’s wrapper is built on top of Prebid. Can you tell us about it?
Yes, we offer an extension of Prebid with an analytics plugin that provides unified reporting within the ONE Display Marketplace portal, as well as per-bidder timeouts for our users. We also give publishers the option to get automatic updates using semantic version numbers in our content delivery network URLs. They can opt in to accepting those updates for only small things like bug fixes, or for bigger ones like feature releases.
What best practices would you recommend to publishers or ad tech providers who want to build on top of the Prebid architecture?
I actually didn’t work on those modifications myself, but I’ve learned a lot about the process from Marian Rusnak, one of our front end developers. He’s part of the team responsible for our changes to the Prebid project, and he shared a few tips for anyone who wants to build on top of the architecture.
First, try not to change the core code of Prebid. If you do, it’s harder to pull in updates since your code will be in conflict with the open source project.
The second tip is to stay involved with the project in Github. There are a few components to this. You always need to keep an eye on how Prebid changes. New updates and features come out really fast – usually at least once a week. If you’re not paying attention, you might find yourself building your own version of features that have already been built and released. The Prebid team also often reaches out to the community there for feedback on ideas and new features.
Beyond that, you can go a step further and contribute the improvements you make back to the Github repo. It’s great for the rest of the community and it’s an opportunity to shape the future of the product.
Finally, write tests for your code. This is true for any software development, but it’s especially important here. You need to understand all the implications of the changes you make when you’re dealing with code that controls the monetization of your site, and there are a lot of pitfalls to watch out for.
What should publishers look for as they decide which demand partners to work with through their header bidding wrapper?
Well, of course every partner needs to provide solid fill and CPMs, but there’s a lot more to it than that. You also need partners who are accountable for ad quality and offer solid support.
But I think the most important thing is transparency. A good example of that is bidding in net. Publishers need bids that are representative of the actual revenue they’re going to get, so the ability to bid in net instead of gross is really important.
Another good example of transparency is in reporting. There needs to be enough detail for publishers to easily understand what they’re getting in revenue and what they’re paying the partner for – you can’t have anything hidden away.
What excites you most about the future of the header bidding wrapper?
One of the coolest things on the horizon is the development of hybrid wrappers that offer both server-to-server header bidding and client-side header bidding. That’ll allow publishers to cut down on latency with server-side partners and still have the flexibility to work with partners who don’t have server-side connections.
On that topic, I’m also excited about the transparency Prebid Server is going to bring to server-side header bidding. You usually think of server-to-server as a black box, but Prebid Server gives publishers visibility because of its open source underpinnings. Transparency is one of the most important things in our industry, so that’s great to see.
Finally, I’m really excited to see wrappers that can move more of the configuration into a server-side user interface, so that publishers can make changes to the wrapper setup without getting into the code. That would give them so much more control. Take timeout settings for example. Right now, a publisher would have to talk to developers and schedule a sprint to change their timeouts. If that process was moved to a user-friendly interface, they could change timeouts on the fly and have more freedom to fine tune the user experience-monetization balance.
Anything else you’d like to say about Prebid?
I think Prebid is the greatest technological development we’ve seen in header bidding so far. The way it empowers publishers, exchanges, and SSPs to work together efficiently is very powerful. We’ve seen occasional collaboration before, but this is breaking new ground as an open source project. And it makes perfect sense. It’s in everyone’s best interest – publishers and demand partners alike – to have a wrapper that works efficiently and gives buyers a fair look at publishers’ auctions.
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!