Thought Leadership

Header Bidding 3.0: The Prebid Evolution Continues

May 1, 2018
By Tameka Kee, Director, Marketing & Content Strategy

With nearly seven out of ten publishers doing some form of header bidding, it’s safe to say that the monetization tactic has grown out of its experimental phase into a more mature, established practice.

But ad tech never sleeps. So in the interest of helping our publishers stay informed about all the latest tools and trends that might impact their monetization, we caught up with Alexandra Smith and Philip Meyer — two of Rubicon Project’s product managers — for an update on the Prebid solution overall and our specific developments.

Rubicon Project & AppNexus launched in mid-Sept 2017. How has the team further invested in the org (and the code) since then? What are some of the most recent updates that benefit publishers?

Philip Meyer (PM): We’ve worked with AppNexus and the other members to develop several improvements and new features over the past few months, including:

  • A module that streamlines A/B testing of server-side header bidding
  • A reporting adapter
  • Support for the DigiTrust universal identifier
  • Improved support for websites with infinite scroll responsive pages

What are the top three reasons a publisher should adopt Prebid vs. a proprietary header bidding solution?

Alexandra Smith (AS): There are several specific characteristics of Prebid that set it apart from the rest:

  • Neutral, open, and fair. Prebid is governed by a code of conduct, which ensures that the publisher’s goals come first.
  • Open source and standardized. Open source means that Prebid takes advantage of the pooled resources of several companies, which allows it to grow faster and be more innovative than a solution that is developed in a silo. That standardization makes it easier to develop new, valuable technology quickly and easily, while reducing the amount of time spent “fixing the pipes.”
  • Flexible. Prebid is the only wrapper that currently supports web, app and video across both client and server.

“Open source” has always been promoted as one of Prebid’s key benefits, but to some, open source is synonymous with instability, and a need for advanced development resources. How does the community counter that?  

PM: All of the code, technology and product features that come out of are peer reviewed and endorsed by the organization before they are used for a Rubicon Project integration. This ensures that the technology publishers rely on actually works the way it should.

And at Rubicon Project, we’ve integrated several Prebid features into our core platform, including the Prebid Reporting and Header Bidding Management Center features that will be available in Q3, so we’re very experienced at supporting publishers that want to use Prebid.

Let’s get technical. What are the core differences between Prebid.js and Prebid Server?

AS: Prebid.js is the client-side code used for Prebid web integrations. In a client-side integration, Prebid,.js initiates requests from the browser to client-side bidders. In a Prebid Server integration, Prebid.js is responsible for initiating requests from the browser to Prebid Server. Then Prebid Server will send requests to bidders via a server-to-server connection.

Prebid also supports “hybrid” integrations in which some bidders receive requests directly from the browser, while others receive requests from Prebid Server.

This can definitely get granular for people on the publisher team who don’t work directly on integrations, so we recently developed a guide to Rubicon Project’s Prebid Solutions for Publishers and App Developers that further explains these nuances.

We’ve talked a lot about Prebid Server and the move to server-side header bidding, but what’s the migration process from client to server like?

PM: Most publishers will introduce Prebid Server as a limited test running alongside client-side bidder integrations in Prebid.js. In this case, Prebid Server is integrated as if it were a new client-side bidder.

A publisher can choose to have a bidder integrated both client-side and server-side (i.e. directly into Prebid.js and also into Prebid Server) and can use the Prebid S2S testing module to configure an A/B test of Prebid Server.

If a publisher wants to migrate completely to server-side header bidding (which we haven’t seen yet), they would simply add all of their bidders to Prebid Server and remove those bidders’ client-side adapters from Prebid.js.

What are some of the features that app developers should pay attention to in terms of the ongoing evolution of the Prebid for App SDK?

AS: The Prebid for App SDK is the app version of Prebid.js — in other words, it’s the client-side code that connects a user’s device to advertisers that want to reach them.  The key difference between Prebid for App and Prebid for Web is that there are no “client-side” integrations in an app like there are for the web.

In a mobile app, all of the demand sources are accessed from the server-side. This means the Prebid SDK sends a request to Prebid Server, which sends requests to the bidders (like exchanges and DSPs). The bidders respond to Prebid Server, which collects the responses and sends them to the Prebid SDK.

PM: What’s unique about Prebid SDK is that a single SDK will be able to offer access to several demand sources, and developers will not need to update it or resubmit their app to the App Store or Google Play Store. Because all bidder integrations live server side, a developer can add and remove partners without needing to change the client-side code.

Any teasers on Prebid features coming down the pike from Rubicon Project?  

AS & PM: Look forward to a robust reporting system, a configuration UI that allows publishers to add and remove bidders and change wrapper settings on the fly, and additional bidders for Prebid Server.

For more information about our Prebid solutions, reach out to us at

Tags: , ,