The Prebid Expert Series: An Interview with Header Bidding Consultant Nick Jacob

This post is the second 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 Nick Jacob. An early contributor to Prebid while at, Nick helped publishers and ad tech companies implement and optimize header bidding as an independent consultant. Nick is now the CTO of AppMonet, working on a managed header bidding container for mobile apps.

How has header bidding changed the way you work?


Prebid and header bidding in general have been my life for the last year and a half. I first started using Prebid in May of 2015 while I was working as an engineer at A-plus, and soon after I became an independent consultant focused specifically on helping publishers set up Prebid.

Obviously, header bidding has had a huge impact on revenue. But it’s also opened up other opportunities. It’s given more control to publishers by letting them take an active stance in what demand partners they work with and how they monetize their programmatic inventory. On the buy-side, performance buyers like Criteo benefit a lot from seeing impressions at the same time other bidders do inside the header, which then opens up more revenue opportunities for publishers.

In a more practical sense, Prebid has had a huge effect on the organizational side of things. Since Prebid is open source, this is one of the first times publishers have had a chance to own the tech side of ad ops, and they’re realizing that gives them huge optimization opportunities and new levers to find the best monetization strategy for their specific inventory. But it also means more technical responsibility than publishers have had in the past. The result is that ad ops and engineering have had to come together more to build the best possible solutions. I think we’ll see that trend continue, with more and more publishers hiring for roles that fall in between engineering and ad ops.


Have any of the companies you’ve worked with built on top of the Prebid open source architecture?


Yes, and I’ve done a lot of that myself. At A-plus, we put together a custom version of Prebid, and I’ve built Prebid-based solutions for other publishers. There are definitely publishers who can get a lot out of the baseline, open source version of Prebid on its own. In fact, there are even benefits to not customizing – you’ll have more community support if you’re using the default version of the code.

But I would say most publishers could benefit from a customized version of Prebid. For example, with a little setup, Prebid lets you monitor performance against traffic sources, which is super useful for publishers who do lots of paid acquisition. Those publishers could then build a system that tells them their margin on paid traffic in real time. Previously, a publisher would have had to manually pull daily reports and put them in a spreadsheet to do that – an ad ops person’s worst nightmare.

Customization is also useful for people who have complex, proprietary ad servers or legacy CMS systems in place. I’ve done several integrations for those kinds of publishers where we’ve taken the open source version of Prebid and used it as the core of a larger framework that integrates their existing ad serving code and other systems.

Even if those publishers wanted to use a proprietary header bidding wrapper, they’d still have to do dev work integrating it with their existing systems. Those publishers are going to have to do some work either way, but with Prebid, they get the flexibility to change their wrapper on the fly if they update their site or add new demand partners, whereas with proprietary solutions they need to coordinate with the vendor to change anything.


What best practices would you recommend to publishers who want to build on top of the Prebid architecture?


The most important thing is to track your KPIs – numbers like ads per page, viewability, and latency. Prebid makes that pretty easy with its Google Analytics integration, but it gets harder the more complex your Prebid setup is. So, make sure you start measuring this stuff right away when your setup is still relatively simple. That way, as you iterate, you can make sure the changes you make are having a positive effect.

You also need to make sure your developers have a good set of test cases for every type of demand you’re serving. So, if you serve direct ads, make sure you check that tools like roadblocks or competitive exclusions still work after you implement. Make sure that you’re not having issues with creative rendering and that your line items are trafficking correctly.

That brings me to another crucial thing to keep in mind: educating your engineering team. Prebid is all pretty simple Javascript, so it’s not hard for them to work with it. But at the same time, most engineers don’t know ad ops – they’re probably the segment of the population most likely to install an ad blocker and pretend ads don’t exist. They need to at least know the basics of how ads are requested from the ad server and rendered on-page. So, publishers need to keep the information flowing between ad ops and engineering and have them work closely with one another to build the ideal wrapper for their inventory.


What should publishers look for as they decide which demand partners to work with through their header bidding wrapper?


This has always been important even pre-header bidding, but you need to find partners with unique demand. You can also get in interesting situations where partners can offer you multiple demand types through the header. It’s exciting but adds another layer of complexity – if someone offers both display and video demand, then you have to evaluate them as both a display and video partner. At the same time, you also need to look at how that’ll affect page load time.

From a more technical perspective, when I add a new demand partner to the header bidding mix, I grade them on the impact they’ll have on page performance. I ask myself questions like, “How much weight do they add to the page?” “How often do they come in under the timeout?” “Do they make one request per size or one for the whole page?” In a mobile web environment, that last one has a huge impact on latency. It’s also possible to get a partner who makes lots of requests per impression or downloads a large Javascript file – that can slow down the other partners in your stack who bid after them.

What I’m saying is, there’s a lot to watch out for. But one thing that’s nice about Prebid is that by letting you traffic all your line items as one set of orders operating on keywords, it makes it easy for you to test new demand partners and quickly turn them on or off depending on performance.


What excites you most about the future of the header bidding wrapper?


A few things. One coming out of Prebid itself is the introduction of video header bidding. The idea of adding more types of supply and even allowing auctions across all formats is really exciting. Server-to-server (S2S) is also interesting and could be a huge opportunity for certain publishers, especially those with low session duration who get a lot of mobile traffic. For instance, if you get a lot of mobile Safari traffic, you should see a big lift from S2S since you’re not getting much cookie matching anyway.

Greater investment in analytics is another big opportunity. At A-plus, for example, we looked a lot at timeouts per partner and how timeouts changed based on traffic segments. If your integration is set up correctly, you can control timeouts really granularly – say, by user segment – which gives you some interesting opportunities for optimization. Prebid’s analytics adapter is helpful here, and you can use it as the foundation to build a custom system that lets you easily control all these different parameters of your auction.

Again, publishers’ ability to tap into these resources depends on their engineering resources. These developments are great opportunities for ad ops and engineering to start working together long term, and there’s a lot of money to be made through that partnership.


Anything else you’d like to say about Prebid?


It’s exciting to see more publishers take control of their ad tech. It’s hard for them to bring it in house, but it’s good for the industry overall. Overall, it’ll mean publishers involving engineering more in monetization and ad optimization. That’s ultimately positive because it means publishers have more control.

I also think this is the start of the flattening of the supply chain. We’re getting toward the end of all the middlemen, and the arbitrage opportunities that come with it. Publishers are forming a more direct relationship with the buy-side. The minute publishers start working directly with DSPs, the industry will be much better for everyone, including advertisers.

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!

  • AppNexus Updates
  • Industry Perspectives