Header Bidding has become a hot topic in ad tech over the last six to nine months. The conversation started in 2011 / 2012 when buyers like Criteo and Amazon's A9 hit the scene, leveraging DFP key-value pairs in concert with a publisher-side pixel to buy their client's first-party audiences on a "first look" basis; before the publisher supply was offered to direct-sold partners or open-exchange buyers. Over the last nine months, this header bidding approach has hit the mainstream and has become an extremely popular way for ad exchanges and ad networks to compete more directly with Google's Ad Exchange while helping publishers improve many of the mediation issues endemic to working with ad networks, ad exchanges, and passbacks within an ad server.
As with most things, this new solution creates new pain-points, in this case managing a lot of third-party advertising pixels directly in the header of your site. Header bidding literally "turns the ad stack on its side", allowing every buyer to compete directly with the ad exchange at the end of the line. It relies on the ad server to do the heavy lifting and by doing so creates more accurate liquidity in the dynamic allocation market and vastly improves partner mediation (who is actually paying you and for what). If Header Bidding helps you meditate this new horizontal stack than Prebid and Pubfood are what allow you to manage those partners’ pixels in the header for the same auctions.
First and foremost, what are Pubfood and Prebid? Pubfood and Prebid are "header tag wrappers". Their fundamental goal and value is the elimination of a publisher's need to add and remove certain third-party advertising pixels from the <head> section of their site. Conceptually, it is similar to an iFrame for header bidder pixels. The solution eliminates a variety of material risks these third-party pixels could pose and reduces the on-going QA and developer resources required to add and test new third-party advertising partners that require a client-side pixel. Both Pubfood and Prebid are open-source and they both aim to help a publisher solve mediation issues endemic to managing ad exchanges, networks, and "a stack".
While Prebid and Pubfood's goals and approaches are similar, what separates them is the sizes of their open-source communities, the degree of sophistication they allow for, and where bids are parsed (which has important reporting and optimization implications).
Prebid, or Prebid.js, is an open-source project spearheaded by AppNexus and is supported on GitHub. Prebid has more market adoption than Pubfood and therefore has a more robust open-source community and info around its implementation. Many top ad networks and exchanges like AppNexus, INDEX, Rubicon, sovrn, Yieldbot, District M, and Sonobi have developed straightforward tag adaptations that allow you to nest their pixles and tags within your Prebid.js instance for quick and easy testing.
What is great about Prebid is its quick, easy setup requiring a lower level of tech chops to get it working. The technical difficulty is intermediate to expert AdOps and beginner to intermediate level Developer work. Prebid allows for two main configurations within your DFP instance, one set of line-items for ALL bidders or one set of line-items for EACH bidder, though we see most Prebid users leaning towards the ALL bidders approach. What is great about this all-in-one approach is that you can quickly and easily iterate thru new header bidder partnerships. What isn't so great about the all-in-one approach is you lose reporting granularity within the ad server at the Order and Line Item levels (where AdOps teams are used to looking). This can be resolved by setting up Prebid.js to dump into Google Analytics but that presumes you are using Google Analytics and is generally a more sophisticated step that I see most publishers and AdOps teams skipping over.
The second config for Prebid, one set of line-items for EACH bidder, solves many of the issues central to the ALL bidders setup. The difference between one set of line-items for ALL bidders versus EACH bidder is what gets passed to DFP. In an ALL bidders setup, Prebid only passes the winning key-value pairs (KVPs) to DFP, leaving DFP less auction work to do and creating a lean infrastructure to organize new header bidding partners around. Within the ad server, the EACH bidder setup more directly aligns with traditional Order and Line Item builds (with a lot of line item granularity) and more closely aligns with how you would directly integrate a header bidder without a wrapper. If you already work with three or more header bidders without a wrapper, or you are positive you want line item and key-value pair level revenue reporting out of DFP, you need to look at Prebid.js's EACH bidder setup which means you also need to evaluate Pubfood.
Pubfood, or Pubfood.js, is a Yieldbot project and is supported via Slack and GitHub. Pubfood has seen a lower, but absolutely relevant, level of publisher adoption so the open-source community around it is smaller. Interestingly, as a buyer, Yieldbot has a Prebid.js integration which to me signals that Yieldbot is in the game to drive the best publisher-oriented solution for the market. As Prebid is an AppNexus project, it is a little harder to be certain whose interests AppNexus will support in the long-run.
All Pubfood setups are similar to Prebid’s EACH setup, so the technical difficulty of setup is near expert level AdOps and can be more labor intensive. What materially differentiates Pubfood is that Pubfood isn’t handling the KVPs from the buyers and passing them to DFP in the same way. Pubfood is not determining the winner of an auction then sending that one bid into DFP. This is an important difference to consider when making a long-term decision. Pubfood sends all bids from all buyers into DFP, manages pixels, and create log files for reporting. They are not deciding winners in the way Prebid’s most basic and popular implementation does.
Pubfood’s EACH setup results in every active bid and KVP being passed into DFP. This means all revenue-oriented reporting can be pulled directly from DFP. Pubfood is a great choice if you are a more technical organization or if you are already working with two or three header bidders, want to try more partners, and don’t want to tear down all of your work in DFP or if you
In the end, both Pubfood and Prebid are first wave iterations of the “header tag wrapper” concept that has hit the market and it is easy to achieve near identical results with both solutions. Prebid can be easier to implement and caters to a Sales and Ops teams’ skillsets more than Pubfood, whose solution is more elegant but also more complex; possibly better suited for publishers and teams with a more developer-oriented or indirect sales culture. Pubfood also caters to publishers who have more active header bidder partners, need a way to manage new and growing list of partner pixels, but don’t want to tear down and start over in DFP.
If these sound like problems you are looking to solve, please feel free to reach out. We can help.
There are two more options besides Prebid or Pubfood; DIY and using a monetization platform’s wrapper (INDEX, OpenX, and Sonobi currently offer Prebid/Pubfood-esque wrappers while Rubicon, sovrn, and others have their tech in development). The pros, cons, risks, and trade-offs with those approaches are another topic. Once we have the header bidding wrapper dialed in we can start understanding where and how to optimize the partners within the wrapper, the implications of this new setup on the auction logic, and how latency now factors into revenue performance.