December 11, 2017

Prebid.js 1.0 is Released!

We’re pleased to announce the release of Prebid.js 1.0! Download it or build it from master!

As a publisher, you can look forward to the following improvements when adopting Prebid.js 1.0:

For more information, see:

September 25, 2017

Announcing Prebid.js 1.0

Prebid 1.0 - here at last

It’s been a long time since we first released Prebid.js; so long, in fact, that people have questioned why were are still a pre 1.0 library. While I’d like to think it’s because we had everything right from the start - we definitely did not - we’ve been hard at work to make things even better. We’ve also grown a lot since then, and even made some friends along the way.

Suffice to say, we are ready to cross over the 1.0 milestone :rocket:. A great part about us working on the Prebid 1.0 journey is that we ended up delivering many of the original ideas already, instead of waiting for the big release. So, some of these features are already inside Prebid.js today.

What to expect

The best part of Prebid.js has, and always will be, the community that supports it. Since the library has many open ended APIs, we haven’t had to change many core things about the library. So you won’t have to do a whole lot to get a lot. Here are some things that are changing:

As a publisher, you can look forward to the following when adopting Prebid.js 1.0:

  • Universal adunit type support for Native, Video and banner.
  • Faster performance due to cutting out of additional JS libraries and simplified adapter code.
  • Module integration support for things like multiple currency support, user syncing, simplified config APIs.
  • Better support for single page applications/sites (concurrency).
  • Better size mapping and responsive site support.

If you have a Demand Adapter that works with Prebid.js - we need your help to work with Prebid 1.0!

  • Once you update your adapter to work with the base adapter in 1.0 - you will be able to integrate with more ad formats easier such as Native and Video.
  • We have broken down the parts of what an adapter does into separate functions - this will make it easier to integrate and test your adapter.
  • We have some additional requirements on what needs to be returned and what kind of endpoints are supporteed (only XHR). Please see the full adapter guide for details.

What’s next

We’ve released Prebid 1.0! Download or build it now from master!

How to get involved

We need the community’s help to successfully launch Prebid.js 1.0. We have been working hard to make sure that it will be as painless as possible to transition, while still being able to make some needed breaking changes.

Please let us know your feedback and how we can make Prebid.js and the Prebid community even better!

Prebid 1.0 Documentation:

As always, we love PRs. Thanks for contributing.

By Matt Kendall, PMC Chair, Prebid.js & Engineering Manager, AppNexus.

September 11, 2017

Announcing the formation of an independent

(This post originally appeared on the AppNexus blog. It has been lightly edited for clarity.)

This week, we’re pleased to announce the formation of an independent organization dedicated to open source tools that drive publisher monetization.

We sat down with Michael Richardson to answer a few questions about why is being launched as an independent entity and what it means for publishers and vendors. Michael is a Product Line Manager at AppNexus and Chairman of

What’s the background on

Prebid.js has been a transformative piece of technology for our industry. It makes it a lot easier for publishers to do header bidding, choose which demand partners they want to work with, and quickly add new ones at will.

Given how much header bidding has benefited the digital ecosystem – including advertisers and consumers – we want to bring it to as many different publishers and vendors as possible. It’s so important to us that, rather than backing a proprietary solution, we want it to be a group effort. We want to work together with the rest of the industry to keep driving header bidding adoption and effectiveness.

That’s why we’re launching a coalition to champion open-source header bidding and its ongoing development. will act as an independent voice on how publishers should interact with programmatic, help ensure that header bidding remains fair and transparent across all parties affiliated with Prebid, and continue to develop and work on features like we do today.

Why are openness and transparency so important with header bidding?

We’ve governed Prebid in an open-source manner since the beginning of the project, so thematically, this is nothing new. The coalition allows us to make this a more concerted group effort. We can bring together talent from different ad tech providers and solve problems together, rather than work on them independently or focus only on our own companies’ offerings.

But let me also answer your bigger question about why openness is so crucial to the Prebid project in general. One of the core benefits of Prebid – and header bidding in general – is that it allows every advertiser an equal chance at every impression. Open-sourcing Prebid makes it easy for everyone to see that there aren’t any tricks or biases happening in the wrapper, proving to users that the benefit is really there.

Beyond that, open-sourcing Prebid makes it easier for the industry to adapt as it changes, since the users of Prebid are the ones driving new features and functionality. It’s also made it easy for new companies to work with Prebid. There are over 80 demand partners with adapters available for Prebid, and multiple analytics companies who have built extensions for Prebid. Only an open-source project can reach such broad adoption.

I think you see these values – fairness, adaptability, openness to new partners – reflected most in’s Wrapper Code of Conduct. The code is a set of rules and principles that govern how we think all wrappers should operate. We want to build a consensus around what wrappers should and should not be doing so that publishers and demand partners can trust that their wrappers are treating them fairly.

Who is part of

We’re launching with Rubicon Project to start. They’ve contributed a ton to Prebid already – some great additions to the project have come from the AppNexus and Rubicon Project teams working together.

Moving forward, we envision many other partners joining SSPs, analytics providers – pretty much any ad tech vendor who works with publishers and supports header bidding will likely come into contact with Prebid at some point. We’d welcome any of them to join and collaborate with us.

Should current Prebid users expect any changes?

There will be no changes to functionality in the short term. In the long term, we hope that users will see Prebid continue to get better and better. Getting more people involved is the best way to foster the creation of more tools to support more use cases and generally ensure Prebid is easy to use.

Any parting tips for publishers using header bidding?

Header bidding has unlocked huge revenue gains for publishers, but they need to stay on top of the latest trends to keep getting the most out of it. I have two key tips for publishers to set themselves up for long-term success with header bidding.

First, don’t just use header bidding for display only. Channels like video and mobile app are really heating up right now, and header bidding can make them even more lucrative for publishers.

My second piece of advice would be to put a lot of thought into the demand partners you work with. As the existence of our Wrapper Code of Conduct suggests, we as an industry have nailed down the basic criteria for what a wrapper ought to do. The next problem every publisher needs to solve is building a roster of partners who bring them unique demand without compromising user experience.

August 21, 2017

Prebid Adds Support for Mobile App Header Bidding

Last week, the prebid-mobile-android and prebid-mobile-ios repositories were open-sourced under the Prebid GitHub project. The addition of these libraries marks another milestone for Prebid, representing its first formal steps towards providing an end-to-end open-source header bidding solution for mobile app publishers.

Prebid Mobile - Banner and Interstitial Ads running on iOS

Why Should I Be Interested in Prebid Mobile?

This year, mobile programmatic spend in the US is expected to exceed $21 billion, representing 78% of all mobile display spend1. Prebid Mobile helps app publishers unlock a greater portion of this mobile app growth by solving for many of the problems endemic to today’s mobile programmatic ecosystem, and by applying the advantages of “traditional” web header bidding to mobile app environments.

Major benefits include:

  • Increased Transparency: Prebid Mobile brings transparency and fair, real-time competition to the mobile app monetization black box. Today, most mobile publishers route impressions to mediation partners without knowing how much each impression is actually worth. By enabling real-time impression-level competition among all configured demand partners, Prebid Mobile allows publishers to more efficiently monetize their most valuable impressions.

  • Better User Experience: Prebid Mobile offers significant improvements to the end-user experience by reducing latency and resource contention on the user’s mobile device. By establishing a single server-side point of integration for programmatic demand partners, Prebid Mobile eliminates the need to set up sequential mediation waterfalls. And, by continuously pre-caching creatives in the background, Prebid Mobile can deliver ads with near-zero delay without interrupting the app’s workflow.

  • Streamlined Integration for App Developers: Prebid Mobile is designed to be as streamlined as possible for mobile app developers. Once integrated, Prebid Mobile ad unit configurations are maintained and managed server-side. This means that publishers can subsequently add or remove demand partners, change demand partner parameters, or alter global settings without making any updates to native app code.

How Prebid Mobile Works

How Prebid Mobile Works

Initial Setup

Mobile developers register each ad unit with the Prebid Mobile framework (ideally early in the application lifecycle). In doing so, each Prebid Mobile ad unit is associated with the ad object in your primary ad server SDK, and with a unique configuration ID pointing to a set of Prebid demand partners maintained server-side.

In parallel, the publisher ad ops team will configure Prebid Mobile line items and creatives in the primary ad server targeted to Prebid key/values. This ad ops setup is nearly identical to Prebid.js for web and should be familiar for publishers that have integrated.

Prebid Server Config Page

In the App

As the Prebid Mobile module runs, it sends bid requests to Prebid Server via a single integration point. Prebid Server looks up the settings associated with the ad unit’s configuration ID, and makes server-side OpenRTB requests to each appropriate demand partner. Prebid Server caches the creative content associated with each demand partner bid response, and sends lightweight bid-level metadata (including bid price) back to the client device as key/value pairs.

The client-side Prebid Mobile module communicates this key/value targeting to the primary ad server SDK. If the primary ad server selects a Prebid Mobile line item based on this targeting, the Prebid Mobile JavaScript creative is served into the ad server’s ad view. Once delivered, this placeholder JavaScript fetches the actual cached creative content from Prebid Server, and the winning demand partner counts the transacted impression.

Getting Started

Once you’ve reviewed the Prebid Mobile Documentation on, the most important first step is to register for a Prebid Server account through the Prebid Server Homepage. Upon registration, you will be assigned a Prebid Server account ID, and can begin setting up demand partner configurations that will be associated with Prebid Mobile ad units.

From there, you can download the Prebid Mobile Android and/or iOS SDKs from GitHub, and can begin working with your ad ops team to configure Prebid Mobile line items and creatives in your primary adserver.

What’s Next for Prebid Mobile

Moving forward, we will focus on adding additional support in two key areas:

  • Ad types: The initial Prebid Mobile rollout includes support for banner and interstitial ads running through the DFP and MoPub ad server SDKs. We are working to add support for additional ad types in each of these ad server SDKs, including interstitial video, rewarded video and native ads.

  • Demand partners: In parallel, we are working to increase the available set of Prebid Mobile demand partners, focusing initially on mobile-first SSPs as well as the set of demand partners already integrated with Prebid Server for display.

How to Contribute

Prebid is an open-source project, and we very much encourage community participation in driving its design and development. The prebid-mobile-android and prebid-mobile-ios repositories are now available on GitHub, along with the source code for Prebid Server.

We love pull requests, and will be looking to collaborate with the community as we look to broaden Prebid Mobile support across ad servers, mobile ad types, and demand partners.

by Matt Jacobson, Product Manager at AppNexus

June 08, 2017

Prebid.js Releases Outstream Video Support

(This post first appeared on the AppNexus Product Blog.)

Late last year, Prebid.js took an important first step beyond traditional display advertising formats with a release of formal support for instream video. Today, Prebid.js is doubling down on its focus on formats with the release of outstream video support.

Outstream Prebid

Given the high cost of creating true instream video inventory and the inherent constraints that this places on supply, outstream video formats are proving extremely valuable for publishers looking for video monetization alternatives, and for marketers looking for more available video supply.

How Does Prebid Outstream Work?

For those already familiar with the workflows for “traditional” Prebid display, getting started with outstream video through Prebid.js is very simple!

In the Ad Server

Within the ad server, you will need one or more display adUnits mapped to the intended size(s) of your outstream placement(s), or you can assign these adUnits a custom outstream size like 1x1. From there, you just need to configure Prebid line items in the same way that you would for display. The key / value targeting and creative setup will be identical!

On the Page

Making sure to update Prebid.js to its latest release version, the on-page setup requires only a few steps:

  1. Add one or more adUnits to your page with the new video-outstream media type
  2. Include at least one bidder on these adUnits capable of ingesting outstream video bid requests
  3. Invoke your ad server for the outstream adUnit from the body of the page in the same way that you would for a display adUnit
var outstreamVideoAdUnit = [
    code: 'video-1',
    sizes: [ 640, 480 ],
    mediaType: 'video-outstream',
    bids: [
        bidder: 'appnexusAst',
        params: {
          placementId: '5768085',
          video: {
            skippable: true,
            playback_method: [ 'auto_play_sound_off' ]


With its brand new support for “renderers”, Prebid.js is able to traffic outstream video through display placements. In general, a renderer is the client-side code (usually a combination of JavaScript, HTML and CSS) responsible for displaying a creative on a page. Fundamentally, a renderer for outstream ads must provide a player environment capable of playing a video creative (most commonly, a VAST XML document). However, in practice, most outstream renderers provide additional functionality / logic, including, but not limited to:

  • Volume, pause, and play controls for the user
  • Ability to expand the player to fullscreen
  • Skippability controls
  • Vendor-specific text, color schemes or logos
  • Expanding the video player when the user scrolls into view
  • Contracting the player on video completion, or when the user scrolls out of view

Renderers, though, are not specific to outstream video ads. In fact, all creatives must have a renderer. The properties and required functionality of these renderers differ depending on the type of content being displayed. For example, native content (which is usually defined as a JSON structure containing a collection of assets) requires a renderer capable of assembling the included assets into the ad displayed on the page.

Today, for outstream video impressions, Prebid requires that each participating demand partner return its own renderer on the bid response. In general, however, it should not really matter where the renderer comes from, as long as at least one is specified. In the following section, we will discuss upcoming plans to expand the possible set of renderer sources and Prebid.js renderer selection logic.

What’s Next for Prebid Outstream?

In upcoming Prebid.js releases, we will be continuing to iterate on top of this initial outstream support to ensure that it satisfies the needs of the broadest possible set of publishers and demand partners. As such, we are focusing on a few key topics.

Running Outstream Without an Ad Server

Prebid.js has always been ad server agnostic, and so we do not believe that publishers looking to create and monetize outstream inventory should be tied to third-party publisher ad servers if they choose not to be. Publishers will be able to choose to give Prebid.js the ultimate responsibility for rendering outstream placements, thus removing the reliance on an ad server to monetize outstream video inventory.

Renderer Selection Logic

To ensure that publishers can take advantage of outstream video with every demand partner, we are expanding the logic by which Prebid.js will select the appropriate renderer to invoke for a given outstream video adUnit. As a result, demand partners will be able to participate on Prebid outstream video impressions even if they do not have their own outstream renderer. In order of priority, Prebid.js will choose a renderer on a given adUnit in the following way:

  1. If the publisher specifies a renderer, Prebid.js will invoke it across all demand partners
  2. If a demand partner specifies a renderer, Prebid.js will invoke it if and only if that demand partner serves
  3. If neither the publisher nor the demand partner specify a renderer, Prebid.js will invoke its own open-source default renderer

Combining the Power of Both Instream and Outstream

We will consolidate instream and outstream video impressions under a common video adUnit definition, and add support for format-specific targeting parameters that demand partners will be able to ingest. As a result, instream and outstream video supply will have access to the same set of video-capable demand partners by default.

Supporting documentation specific to Prebid outstream video is available through, including How to Show Outstream Video Ads and an outstream end-to-end working example page.

December 15, 2016

First Open Header Bidding Solution for Video Now Available on Prebid.js

(This post first appeared on the AppNexus Product Blog.)

At its core, Prebid.js has always worked towards achieving a few simple goals: providing publishers with fair and transparent access to demand; improving monetization by unlocking the true value of publisher inventory; and, asserting control over the (often narrow and unfavorable) auction dynamics kept locked by closed publisher adservers.

The release of PreBid Video marks an important step forward for the open-source project, as market participants can begin to realize these same benefits across inventory formats beyond those of traditional display.

In a supply-constrained video ecosystem in which the majority of inventory is monetized via direct sales, PreBid Video offers a programmatic avenue through which publishers can achieve incremental value while still maintaining these guaranteed and/or direct buys.

PreBid Video Evian

The true value of an open-sourced project is realized through the ability to incorporate new functionalities, feature development, and bug fixes from a wide contributor network which encompasses diverse expertise and an array of market positions. We encourage and welcome these contributions as we look ahead towards iterative improvement on PreBid Video. With help from the community, we expect to be able to build portfolios of video-capable adapters to match the nearly 40 demand partners integrated today with PreBid display; of video player and adserver integrations with Prebid.js; and, of video-specific formats.

This paradigm has already netted tangible positive results among the several publishers with whom AppNexus has been working closely to enable PreBid Video on live traffic.

One alpha partner who had already been monetizing display traffic through Prebid.js was able to expand upon the open-source code to integrate PreBid Video directly with hundreds of publishers using their proprietary video player and adserver stack. While Prebid.js currently offers built-in support for Google’s DoubleClick for Publishers’ Video Adserver, this partner was able to seamlessly incorporate PreBid Video demand into their existing Prebid.js implementation and their own adserver with only a few extra lines of code. Shortly after implementation, PreBid Video was providing real-time demand from some of the largest advertisers in the U.S. at CPMs ranging from $15 to $30, helping to realize strong incremental revenue lifts without adding page latency or compromising user experience.

var videoAdUnit = {
  code: 'video',
  sizes: [640,480],
  mediaType: 'video',
  bids: [
      bidder: 'appnexusAst',
      params: {
        placementId: '123456' // <-- Replace this!
        video: {
          skippable: true

PreBid Video is and will continue to be adserver, video player, and demand partner agnostic, and is designed to work seamlessly with existing Prebid.js implementations. The Prebid.js source code is now available in beta on GitHub.

Supporting documentation is available through, including:

October 05, 2016

Show Responsive Ads with Size Mapping

Prebid is making it easier for you to adjust ad sizes based on the device’s screen width. Using the new size mapping feature, you can:

  • Change ad sizes depending on the user’s screen size

  • Use declarative syntax during ad unit setup

  • Avoid adding tricky custom logic to your code

For more information, see the example code here.

August 31, 2016

Happy Birthday, Prebid.js!

(This post originally appeared on the AppNexus blog. It has been edited slightly for clarity.)

The Beginning

About a year ago, the publisher engineering team at AppNexus began noticing a common problem with some of our forward-looking publishers: many of their websites were taking a long time to load.

Since all the pages were written in JavaScript and HTML, our team was able to dig deep and see why all those pages were taking their sweet page-load time. What we soon found was that these forward-looking publishers had started experimenting with header bidding, but the integrations weren’t designed in the best interest of publishers.

To be specific, these integrations were blocking the page content from loading, and they interfered with other header bidding integrations. Some publishers reported 10 - 20% impression loss, because once a site stacks up a few header bidding partners, the page blocking effect goes up significantly.

After speaking one-on-one with our clients, we came to a pretty straightforward conclusion: the header bidding integrations were opaque. Publishers weren’t given enough information about how they worked. In addition to the blocking behavior that causes latency and impression loss, each header bidding implementation was taking several weeks for publishers: in other words, way too long. Somewhere in the intensive process of writing a few hundred lines of code, of setting keywords and loading the right creatives, header bidding was devolving into a real-time traffic jam.

We quickly realized there is something we can do to significantly improve sites’ user experience and monetization. After a very intensive two weeks, we managed to build the first Prebid.js container prototype, and presented it to the rest of the company and our publisher friends.

We knew how important this solution would be. Just like our forward-thinking publishers were willing to adopt this industry change with header bidding, we owed it to our publishers to pioneer this technology. The Prebid.js container solution was one of the first container solutions available to publishers. While others in the industry were still trying to figure out header bidding, we were already thinking ahead on how we can make this technology better for publishers and easier to implement.

Only one question remained… how would we distribute it? The ad tech market has always been so competitive on revenue and profit, and there were other companies selling their proprietary solutions at a premium price. However, at AppNexus, our ultimate goal has always been to make the Internet a better place. We believe header bidding is on the right track, and the best way to help publishers is to teach them everything we learned, including the code we wrote, the challenges that early adopters have faced, and the efficient ad ops setting we were experimenting with. We also do not believe our solution can fit all, or is the best yet - publishers are smart and they know their pages the most.

Therefore, we open sourced the Prebid.js code on GitHub and documented everything we learned on We wanted to help publishers unlock ideas and innovate faster, and to accelerate the growth and adoption of header bidding.

And - gulp! - we sent our baby out into the world.

The Response

The first week after the launch of Prebid.js we started receiving Github responses from publishers. The responses were positive - several key metrics were telling us publishers were deeply engaged with this product, even from day 1 with the minimum viable product. For example, users on average spent over 5 minutes on the site, and over 35% of the users came back to the site almost every day during the week - a sign suggesting they were reading and implementing Prebid.js.

And the power of open source started kicking in. On Github, publishers started posting comments, fixing bugs, and contributing code, big chunks of code! For example, our first version of Prebid.js didn’t have a popular header bidding partner implemented. Within a week, we received 3 versions of it, submitted by 3 different publishers!

To date, our Github repo has received over 485 tickets (we closed 452 of them), 1600 comments, 237 pull requests, 173 forks, and 59 contributors. Over 25 companies have submitted their header bidding adaptors, making Prebid.js one of the most collaborative ad tech projects. Over 2100 people have given us their emails to stay up to date with the latest news on Prebid.js. In June 2016 alone, we’ve had over 350 downloads of the custom built version of Prebid.js!

We are also happy to see the fast growing adoption of Prebid.js on publisher pages. According to the third party analytics provider Builtwith, Prebid.js saw exponential growth in the past year, and has been installed on over 12,000 sites!

The Product Evolution

The Prebid.js Engineering team has spent time and effort making sure the industry comes together to provide guidelines and consistency around header bidding. We began publishing more content around the problem of latency, strategies on how to reduce latency, and tips on how to simplify ad ops set ups for header bidding.

We also started building products to benchmark header bidding integrations. For example, we designed Headerbid Expert, a browser plug-in, because we noticed publishers struggling to find out accurate latency information on their header bidding partners. To date, 3,000 users have downloaded Headerbid Expert - all the more interesting because the development of Headerbid Expert was a weekend project, plain and simple. During the course of one 48-hour mini-hackathon, we managed to build a tool that publishers and tech vendors alike seem to find cool and useful.

So, what’s in store for the future of Prebid.js? Well, header bidding is still in its early stages, and there is plenty of room for improvement and innovation. We want to keep Prebid.js super light, simple, and fast, and that’s our grand mission. Today’s adaptor integrations still require much more data transfer than they need, and we know we can score a 10x speed improvement in the very near future, especially with the amount of support and adoption from the community.

We also want to make Prebid.js excel on mobile pages, and we have a good plan for that. For the remainder of the year, we’re going to invest heavily in those efforts so that publishers can enjoy faster page load, higher viewability rate, and much more efficient header bidding integrations.

Ultimately, as we see the continued success of header bidding, we’ll continue our commitment to the evolution of header bidding - and our community will see the fruits of this labor in the near future. Happy Birthday to! Be sure to stay tuned for more exciting developments in this space.

June 21, 2016

Enable Deals in Prebid

Prebid is making it easier for publishers to run deals in header bidding!


  • No development change is required to enable deals! If your pages are using the standard key-values, simply upgrade to the latest prebid.js to enable deals.

  • Easy ad ops setup with a complete step by step guide. Setup deal line items in a few minutes.

How to implement it?

In order to enable deals for prebid, the ad ops setup are slightly different from the standard header bidding setup. Specifically:

  • From the ad ops side, you’ll create separate orders and line items that target the deal ID key-values. These line items will be at different priorities than your standard header bidding line items. Follow the step by step Deals Ad Ops Guide to implement.

  • From the dev side, if your page is using the standard prebid.js key-values, no change is required.

Note that the initial list of bidders that support deals are: Pubmatic, TripleLift, AppNexus, bRealTime. More bidder adaptors are implementing deals currently. If you’d like to check progress on a bidder, create a Github issue.

May 10, 2016

Load DFP Lightning Fast with Prebid

Prebid is introducing a new way of loading GPT and sending GPT requests. Compared to the previous mechanism, the new method has the below advantages.


  • Further reduces latency: the new method loads ads 40-80ms faster than the old method on fast Internet connections, and more (go up to 150ms faster) on slower Internet connections, such as those of mobile cellular. Reasons:

    • The new method requires no need to delay the loading of the GPT library. The GPT library can be loaded upfront.

    • Instantly send out ad server ad requests when bids are ready or timeout is hit. No need to wait until the GPT library finishes loading.

  • Easier implementation and maintenance: The new method requires no change to your pages’ original GPT implementation. It’s a simple code snippet insertion now. This can be done by the ad ops teams within a tag management system.


GPT Instant Load (right) sends GPT ad requests about 100ms faster than the previous method (left):

Prebid Instant Load Benefits

What is GPT Instant Load?

GPT Instant Load leverages the googletag.pubads().disableInitialLoad()call to disable GPT from sending out ad requests out immediately. This call informs GPT to wait until the first googletag.pubads().refresh() is executed. GPT Instant Load triggers the refresh() call when all requested bids are back, or when timeout is hit, whichever happens faster.


  bidsBackHandler: function() {

How to implement it?

Please follow the line by line code example documented here.


Credits to Bart Van Bragt in the Github suggestion.

April 20, 2016

New Adaptors Sonobi, Brightcom, Adequant

New adapter for Sonobi - how to add:

var adUnits = [{
  code: '/9968336/header-bid-tag-0',
  sizes: [[300, 250], [300, 600]],
  bids: [{
    bidder: 'sonobi',                 //  New format
    params: {
      ad_unit: 'PER SLOT'        //  <String> ad unit code
    bidder: 'sonobi',                     //  Old account format
    params: {
      placement_id: 'PER SLOT'  //  <String> placement Id

New adapter for Brightcom - how to add

var adUnits = [
    code: '/9968336/header-bid-tag-0',
    sizes: [[300, 250], [300, 600]],
    bids: [
        bidder: 'brightcom',
        params: {
          tagId: 12345 // Tag ID supplied by Brightcom -

New adapter for Adequant - how to add:

var adUnits = [{
  code: '/9968336/header-bid-tag-0',
  sizes: [[300, 250], [300, 600]],
  bids: [{
    bidder: 'adequant',
    params: {
      publisher_id: '1234567',  // REQUIRED int or str publisher ID. To get one, register at
      bidfloor: 0.01            // OPTIONAL float bid floor in $ CPM
March 18, 2016

New UI to Customize Prebid.js with Selected Adaptors


Since we introduced Prebid.js 8 months ago with only 4 adaptors, more than 15 SSPs have started contributing and maintaining their adaptors through Github. The number of demand adaptors Prebid.js supports has now grown to 17! (more are coming)

The average number of adaptors publishers use are between 3 to 8. It makes more sense now for publishers to choose and pick the adaptors they would like prebid.js to include.


  • Load prebid.js and header bidding ads faster, with a smaller file size of Prebid.js. For example, prebid.js with one bidder is of file size 30KB. Prebid.js with 17 adaptors is of size 80KB. Browsers can download a smaller file size faster.

  • Higher level of control: While prebid.js with all 17 adaptors gives convenience to the publisher when adding new partners, being able to choose which adaptors to include gives more control back to the publisher.

What is it:

A new UI to customize Prebid.js with the adaptor you choose:

Prebid.js Customize Download UI

How to use it:

The service is now available at Prebid Download.

March 14, 2016

New Adaptors TripleLift, NginAd

New adapter for NginAd - how to add

var adUnits = [{
        code: '/9968336/header-bid-tag-0',
        sizes: [[300, 250], [300, 600]],
        bids: [{
            bidder: 'nginad',
            params: {
        	    pzoneid: '7', // <String> PublisherAdZoneID
                nginadDomain: "" // the domain where you installed NginAd

New adapter for TripleLift - how to add:

var adUnits = [{
        code: '/9968336/header-bid-tag-0',
        sizes: [[300, 250], [300, 600]],
        bids: [{
            bidder: 'triplelift',
                params: { 
                    inventoryCode: 'headerbidding_placement' }
March 14, 2016

HTTPS proof comes to Prebid and all its adaptors


Many publishers require their users load some of, or all of their pages securely via HTTPS. The main motivation for HTTPS is authentication of the visited website and protection of the privacy and integrity of the exchanged data. source.

What does it mean that HTTPS has come to Prebid and all its adaptors?

1. Prebid.js library can be loaded securely via HTTPS.

When the prebid.js library is loaded securely via HTTPS, it will auto ensure the adaptors are also loaded securely via HTTPS. The adaptors should also return the bid responses and ads securely via HTTPS.

2. All adaptors that Prebid.js supports can be loaded securely.

Some adaptors may load external Javascript. During the prebid.js adaptor certification process, we ensure these external Javascript are also loaded securely via HTTPS.

3. All bid responses and ads returned by the adaptors are via HTTPS.

When a page is loaded securely via HTTPS, all the data exchange and communication have to be in HTTPS. This includes the data coming back from the servers as well.

How to turn on HTTPS for prebid?

Load prebid.js library via HTTPS. All examples documented on provide examples for how to load prebid.js via HTTPS.

February 11, 2016

New Adaptors Adform, bRealTime, Springserve

How to add bidder Adform:

var adUnits = [{
        code: '/9968336/header-bid-tag-0',
        sizes: [[300, 250], [300, 600]],
        bids: [{
         bidder: 'adform',
           params: {
             adxDomain: '', //optional
             mid: 74042

How to add bidder BRealTime:

var adUnits = [{
        code: '/9968336/header-bid-tag-0',
        sizes: [[300, 250], [300, 600]],
        bids: [{
            bidder: 'brealtime',
            params: {
                placementId: '2251610'

How to add bidder Springserve:

var adUnits = [{
        code: '/9968336/header-bid-tag-0',
        sizes: [[300, 250], [300, 600]],
        bids: [{
                bidder: 'springserve',
                params: {
                    impId: 1234,            //Required - number
                    supplyPartnerId: 1,     //Required - number
January 11, 2016

New Adaptors AOL, Pulsepoint, IndexExchange

How to add bidder AOL:

var adUnits = [{
        code: '/9968336/header-bid-tag-0',
        sizes: [[300, 250], [300, 600]],
        bids: [{
            bidder: 'aol',
            params: {
                placement: 'TO ADD', //String placement
                network: 'TO ADD'    //String network,
                //optional params
                sizeId : 123,       //Number
                alias : 'TO ADD,    //String
                size : [300,250]    //Array[Number]

How to add bidder Pulsepoint:

var adUnits = [{
        code: '/9968336/header-bid-tag-0',
        sizes: [[300, 250], [300, 600]],
        bids: [{
            bidder: 'pulsepoint',
            	params: {
            		cf: '300X250',  //String adSize identifier 
            		cp: 123345,     //Number Publisher Id
            		ct: 123456      //Number  Ad Tag Id

How to add bidder IndexExchange:

var adUnits = [{
        code: '/9968336/header-bid-tag-0',
        sizes: [[300, 250], [300, 600]],
        bids: [{
                bidder: 'indexExchange',
                params: {
                    id: 'TO ADD',  //String - id of placement required
                	siteID: TO ADD,  //Number - site id required
                	timeout: 1000, //Number Optional
                	tier2SiteID: 'TO ADD', //String Optional
                	tier3SiteID: 'TO ADD' //String Optional
January 11, 2016

Adjust Bid Price for Gross/Net Now Supported


Bidders may have different pricing deals with publishers, and the returned bid prices may or may not reflect what the publisher will truly receive in the end.

For example, some bidders returned the bid prices in gross (before any fee is taken). This artificially sets that bidder’s bid (say $1.2) at an unfair advantage, because the bidding price, when bid wins, is in fact not what the publisher will receive. The publisher in fact got paid $1. However, if there was a competing price $1.1 in net (after the fee is taken), the publisher would have earned more if taking that $1.1 bid.

What is the feature

This feature allows the publisher to adjust the bidding price before the bids targeting are set on the ad server tag. This is especially relevant for publishers who choose to let prebid.js send only the top winning bid to the ad server, because the price adjustment is done before the top winning bid is chosen.

Prebid.js Adjust Bid Price

How to use the feature

See the Publisher API Reference for more details.

October 11, 2015

Analytics for Prebid.js Coming Soon!

Are my header bidding demand partners generating more revenue for me? If not, is it because of latency or is it due to low bid CPM? How about discrepancy?

Prebid.js is launching its Analytics Platform to help you better manage your header bidding partners. Analytics Platform includes:
  • Bidder bid/win price analysis by geo, domain, with price range distribution.
  • Bid latency by bidder, geo, and domain.
  • Seamless integration with your Google Analytics account and scheduled reports delivered to your mailbox.

Example reports by Prebid.js Analytics:

The day starts from making sure the bidders are not generating less revenue:

Blocking Ad Calls 1

Something is not right here - total revenue from yesterday dropped quite a bit. This could be caused by certain bidders were down or experienced technical issues. Let’s take a look at the bidder timeout rate:

Blocking Ad Calls 1

Bidder timeout seems okay. The problem might then be caused by bidders’ lower bid rate:

Blocking Ad Calls 1

Here we go. Bidder 1 and 4 bid much less than usual. You may want to drill down even further - Prebid.js Analytics also provides:

  • More metrics such as: bid load time, avg bid CPM, bid rate, avg win CPM, win rate.
  • Filter the above metrics further by geo, domain, and OS

Try out the product and explore the demo dashboard here! This will be the base of your dashboard!

Histogram analysis of latency and CPM distribution:

To understand exactly how much time per bidder spent, the Analytics Platform allows you to make the below query:

  • For country X, what are bidders’ bid load time, for mobile traffic on Android only?

Blocking Ad Calls 1

You might derive:

  • Bidder 1 is really fast, because 1/3 of its bids are in red, which is in the 200 - 300ms response time range.
  • Bidder 5 is really slow, as 1/3 of its bids are in 800 - 1000ms.

Similar query for bidders’ bid CPM:

Blocking Ad Calls 1

Try out the product and explore the demo dashboard here! This will be the base of your dashboard!

How does it work?

Prebid.js has a seamless integration with Google Analytics (other analytics software support coming) and Google Spreadsheet.

  1. Prebid.js has a built-in plugin for Google Analytics, i.e. zero development work if your site uses Prebid.js.
  2. All data are sent as Events to Google Analytics. You can build reports and dashboards there just as you do today with web traffic data.
  3. We’ve also built dashboards and data visulization in Spreadsheet (where all the above diagrams come from). You can copy our demo dashboard and link it to your Google Analytics account in a few minutes!
  4. The Spreadsheet dashboard can be scheduled to run every morning (or in other intervals). You can get 7 day revenue lookback, latency/CPM distribution analysis and more every morning!

Try out the product and explore the demo dashboard here! This will be the base of your dashboard!

Leave your comments below for questions or early access to Prebid.js Analytics!

August 29, 2015

What is post-bid?

What is post-bid?

Post-bid allows a publisher’s mediated demand sources all compete in one auction based on price, after the ad server has picked the post-bid line item.

In post-bid, the competition among your mediated demand sources compete AFTER your ad server has chosen the winning line item (vs. in header bidding, demand sources compete BEFORE your ad server has seen the impression). In post-bid, your mediated demand sources no longer run daisy chain; they all compete in one single line item based on price.

Add Creative to Line Item


  1. The webpage sends an impression to the ad server.
  2. The ad server chooses a winning line item among class 1, exchanges, and the post-bid line items. In this case, the post-bid line item wins because the eCPM on the line item is high (based on historical price) and the higher priority class 1 line items have all exhausted their spend.
  3. The post-bid line item’s creative is served to the page. The creative runs an auction for the bidders using prebid.js, which then displays the highest price creative in that creative’s ad slot.

Why post-bid?

The main reasons we have seen publishers opt for post-bid (instead of header bidding) are:

1. The post-bid setup does not need engineering resources.

The Post-bid creative is just a 3rd party tag. Once it’s served to the page, prebid.js runs an auction across all demand sources. The only technical work is to insert the tag Ids into the 3rd party tag’s JSON config for your demand sources. It’s trivial work.

2. The post-bid setup adds no latency to class 1 ad delivery.

Because post-bid is just a 3rd party tag, your ad server receives the impressions as soon as the page loads. The post-bid setup does not affect the class 1 or exchange spend. Post-bid actually reduces latency compared to a daisy chain mediation setup, because in post-bid all demand sources are requested concurrently, instead of in a waterfall.

Additionally, post-bid does not need additional line items. The initial setup is easier than header bidding.

How to choose between header bidding and post-bid?

We’ve listed the advantages of post-bid over header bidding in the previous section. The disadvantages are listed below:

1. No dynamic allocation across all demand sources.

The bid price on the post-bid line item is static (based on historical price). It thus has the typical problems of a 3rd party tag line item. Due to this downside, the Post-bid setup cannot make your demand partners compete with class 1 or exchanges.

2. Reporting is harder.

In your ad server’s post-bid line item report, you’d only get an aggregated report of all demand sources. You may need to rely on a 3rd party reporting service to record which demand partner wins how much inventory.

  Mediation Post-bid Pre-bid (header bidding)
Engineering Resources Not required Not required Required
Ad Latency No additional class 1 latency. Waterfall adds latency when networks do not fill. No additional class 1 latency. Parallel auction for demand sources thus minimum latency. Additional class 1 latency from the page’s timeout setting.
Compete among demand sources No Yes Yes
Compete with Class 1 & AdX dynamic allocation No No Yes
Monetization Capability Low Medium High
Block page content from loading? No No No (with prebid.js)


1. If none of the post-bid demand sources fill, can I still passback to another tag, say from Adsense?

Yes. Check out the example.

2. How can I get started?

If you need help, email

August 12, 2015

How many bidders should I work with?

While helping publishers run header bidding, we hear the same questions asked many times:

  • How many bidders should I work with?
  • How can I maximize revenue while maintaining a good user experience?

We’ve all heard anecdotally a webpage should not have more than 10 bidders’ bids, or the page should not wait for longer than 1 second before it sends the bids to the ad server. Are they true?

Luckily, the publishers using Prebid.js are curious about these questions too. We thus ran A/B tests and collected real data from pages running header bidding. We measured overall revenue & latency versus the number of bidders and how long the ad server waits for.

Q1: How is revenue affected by different factors?

Prebid Diagram Image (the above data is normalized to CPM = 1 for anonymity)

Revenue is mainly determined by:

  • How many bidders the page works with (as the blue and orange line show).
  • How long does the page wait so the most number of bids can get back in time (X-axis).


1. You make more money when you include more bidders!
  • Perhaps not surprising - more competition, better yield. But the below 2 points are even more interesting:
2. When you include more bidders, the page should wait longer too!
  • Working with 10 bids (orange) makes incrementally more money as the ad server waits longer. But the 5 bids revenue plateaued.
  • As the graph’s 0 - 300ms (X-axis) shows, either working with 5 bids or 10 bids makes no difference; In fact, working with 10 bids has a slight dip at 200ms, possibly due to the latency caused by sending out more bid requests.
3. Revenue actually drops if the page waits for too long
  • This could be caused by users leaving the page, when the ads took too long to load.

Q2: How is page content load time affected?

Prebid Diagram Image (The above page has on average 130 HTTP requests, 1.5MB data transferred per refresh)

Page content load time is critical to measure user experience. Your page’s content taking 200 millisecond to load delivers a MUCH BETTER experience than if it takes 2 seconds.

In this test, we measured the front section’s load time. We define the front section as what’s visible to the user when they open the webpage. For example, when the above graph’s Y-axis is at 100ms, it means that the front section took 100ms to load before a user can see it.


Page content load time is NOT really affected by the number of bidders or by how long the page waits.
  • The front section continues to load between 60 to 120ms, unaffected by the given factors.
  • This is expected, as Prebid.js sends out bids asynchronously and they do NOT block the page content from loading. Modern browsers also prioritize the page content load over asynchronous Javascript scripts.

Q3: How about ad load time?

Prebid Diagram Image (The above page has on average 130 HTTP requests, 1.5MB data transferred per refresh)

Ad load time measures how long a user has to wait before he/she can see the ad. This is less important than the page’s content load time. However, the initial blank space in the ad unit, or the page elements shifting around due to a late ad load, can both demage the user experience.


1. It’s linear. Longer the adserver waits, longer it takes the ads to load.
  • This makes perfect sense. It’s important to note that the ads load at around 1200ms even when the adserver waits for 2 seconds, because most of the bids come back within 1200ms and Prebid.js stops the adserver from waiting.
2. When your ad server waits for < a threshold (500ms in this case), working with more bids take longer for the ads to load.
  • This makes sense, because sending out more bid requests takes longer.
3. When your ad server waits for > a threshold (500ms in this case), ads load in the same amount of time regardless of the number of bids.
  • Our guess is, when the ad server waits for long enough, there’s enough time for 10 bid requests. Thus it didn’t further delay the ads from loading.


Every webpage is different. Every site’s users are different. Different publishers will put different weights on revenue vs. user experience. Our main recommendation is: Create the above 3 graphs. They will help you understand how many bids you should work with and how long your page should wait for.

Prebid.js is a good place to start for free : )

Note that the above data is collected by pages that run true header bidding auctions, which is defined by Prebid.js as:

  • All bid requests are sent out concurrently, not blocking each other or blocking the page content to load.
  • All participating bidders are treated equally, given the same amount of time to respond.
  • Ad server only waits for a limited amount of time, ignoring all bids that come after.

If your page does not run a true header bidding auction, the above analysis may not apply.

August 07, 2015

Bidder Analysis on price and latency

The content on this page is from 2015 and is now obsolete.

While implementing Prebid.js’ adaptors for different bidders, we’ve noticed not all bidders return exact price to the publisher’s page. Different bidders also have vastly different response latency. We hope the analysis here can help you make smart decisions when implementing header bidding.

Bidder Price *Latency (rough estimate)
AOL Unknown Unknown
AppNexus Exact 200ms, however async calls have to be made for multiple slots
Casale Exact Unknown
Criteo Estimated 200ms
OpenX Exact 500ms
Pubmatic Exact 400ms
Rubicon Exact 400ms
Sonobi Exact Unknown
YieldBot Estimated at $1.00 increment Unknown

*Note that the above latency estimate was done in New York, US with fast Internet connection. To provide more accurate report, publishers can implement latency trackers through the prebid.js API.

Live Test

Refresh this ad
loader gif

The above ad is auctioned with Prebid.js.

  • Hover over the timeline bars to discover how long each bidder takes.
  • Ad server is set to only wait for up to 400ms. If all bidders respond faster than that, Prebid.js will load the ad server early. If not, Prebid.js will ignore bidders that took too long.
  • You may notice Javascript cannot initiate all bidder calls at once. To prevent bidders that get installed last to always have less time to respond, Prebid.js helps you keep the auction fair and rotate the order that bidders get called.
July 25, 2015

How to reduce latency of header bidding

Why do header bidding cause latency? How to reduce it?

Having seen almost all bidders’ header bidding API calls, we’ve observed the few problems listed below:

  • Many bidders can NOT load their Javascript library asynchronously.
  • Publishers make more money if all bidders are treated fairly. However, bidders that offer asynchronous integrations today (better for the publisher) are given LESS time to respond.
  • Blocking ad calls is bad for user experience. Users leave the site if content takes too long to load.

Here’re a few screenshots of websites’ network calls after implemented header bidding. In a later section, there’s a screenshot showing how header bidding is accelerated by prebid.js.

####Blocking Call Screenshot 1

Blocking Ad Calls 1

  • All header bidding requests combined took 4 seconds to load!
  • Users have to wait for 4 seconds of blank space in their web browser before any content can load.

####Blocking Call Screenshot 2

Blocking Ad Calls 1

  • All header bidding requests in total took 1 second to load.
  • However, if all calls are made asynchrnously, latency can be dramatically reduced.

After prebid.js’s acceleration:

Blocking Ad Calls 1

  • #####All Pre-bid Calls are made concurrently within 100ms.

    Note that AppNexus, Pubmatic, OpenX, Rubicon header bidding calls were all made within the first 100ms.

  • Timeout at 400ms is respected.

    We set the timeout to 400ms. As you can see from the graph, the GPT tag (gpt.js) is loaded at around 500ms. The reason that GPT didn’t get loaded exactly at 400ms is Javascript’s timer is underterministic. Some partners take longer than the others. The ones that took longer than the timeout setting did not get a chance to bid due to latency concerns.

  • Rotate order of bidders

    To help publishers maximize yield, all header bidders should be given the same amount of time to respond. However, Javascript doesn’t make calls exactly at the same time, so we help you rotate the order that the bidders get called.

July 20, 2015

How to simplify line item setup

Let’s do the math:

  • Per bidder per size: $0.01 increment, capped at $10 => 1000 line items
  • 10 creative sizes
  • 5 bidders

1000 x 10 x 5 = 50,000 line items and creatives for header bidding!

How to reduce the number of line items for header bidding?

Prebid.js helps you use 1 set of line items for all bidders and all creatives.

By removing the size and bidder dimension, the number of line items now becomes:

1000 x 1 x 1 = 1000 line items! 50 times less!

Simplification 1: Remove the size dimension

In this section, we’ll learn how to remove the creative size dimension for header bidding. Before, a publisher would have to create different set of line items for different creative sizes. With Prebid.js, a publisher only need to create 1 set of line items for all creative sizes.

Let’s first clarify what “different set of line items for different creative sizes” means. In this scenario, a line item’s creative is only of one size. In DFP, this looks like:

Header Bidding Normal Line Item Creative

Because a site would have many creative sizes, with this setup you need X number of line item sets for X number of creative sizes.

There’s a reason bidders recommend different set of line items for different creative sizes. If we simply attach all creative sizes to a line item, the line item wouldn’t know which size of creative to choose. Consider this case:

  • Your line item has all creatives of different sizes attached.
  • Your ad unit can accept both 300x250 and 300x600. A bidder bid $6.00 for the 300x600 size and has the highest price.
  • The $6.00 line item got picked by the line item.
  • The best your ad server can do is to RANDOMLY choose a creative. If the 300x250 one is chosen, the ad will be cut in half.

How Prebid.js solves this problem:

Prebid.js can dynamically resize the returned creative to the right size. Here’s the setup:

  • Submit a few creatives of size 1x1 and make them override the line items’ sizes.
  • Your ad unit can accept both 300x250 and 300x600. A bidder bid $6.00 for the 300x600 size and has the highest price. Prebid.js passed the bid in, as well as a generated bid ID.
  • The $6.00 line item got picked by the line item.
  • Your ad server randomly choose a 1x1 creative. However, because all creatives have the same content, it does not make a difference.
  • The creative content has the bid ID. Prebid.js reads this bid ID, which is mapped to size 300x600.
  • Prebid.js resize the returned creative to size 300x600 and injects the bid’s cretive payload.

There you go!

Simplification 2: Remove the bidder dimension

In this section, we’ll learn how to remove the bidder dimension for header bidding. Before, a publisher would have to create different set of line items for different bidders. For example, 3 different set of line items for AppNexus, Pubmatic, and Rubicon. With Prebid.js, a publisher only need to create 1 set of line items for all bidders.

There’re a few reasons why previously you’d need different set of line items for bidders.

  1. Bidders did not design their implementation guide with other bidders in mind.
  2. Bidders all have different targeting parameters.
  3. You need to run reports to learn fill rates and CPM from different bidders.

Assume we have 1 set of line items for ALL bidders. Consider the below key-value pairs came in: (AppNexus bid $1.60, Rubicon bid $1.20. Ad IDs are used for rendering the right creative):

  • appnexus_cpm: 1.60
  • appnexus_adId: 65432
  • rubicon_cpm: 1.20
  • rubicon_adId: 23456

The line item for $1.60 is chosen because it has the highest price. However, the creative attached to this line item will be given both appnexus_ad_id: 65432 and rubicon_ad_id: 23456. There’s not an easy way for the right creative (in this case the AppNexus creative) to render.

How Prebid.js solves the problem:

Prebid.js only picks the highest price bid and sends its key-value pairs to the ad server. Given the above example, Prebid.js will send:

  • hb_pb: 1.60
  • hb_adId: 65432
  • hb_bidder: appnexus

This simplifies the setup and the right creative (with adId 65432) will get displayed.

How about reporting?

It’s important to understand the fill rates and CPM from different bidders. Prebid.js therefore passes in hb_bidder: bidderCode. This enables DFP to report on query strings. You can therefore run queries like:

  • For bidder X, at what CPM does it fill?
  • For bidder X, what’s the fill rate out of all the winning header bidding bids?

Note that because Prebid.js only sends in the highest price bid, DFP does not see the rest of the lost bids. However, from working with publishers, we conclude that the rest of the bids do NOT matter that much. Let’s say one bidder always fills at 1 penny and bids 100% of the time. Is that information helpful? Not really, only the winning bids count. We belive the above 2 queries well serve the reporting and analytics needs.


Enjoy the much more simplified line items, creatives, and targeting setup!