July 24, 2020

Prebid Releases 4.0

We’re excited to announce the release of Prebid.js 4.0! Version 4.0 includes some important updates related to TCF 2.0 and a number of housekeeping items. You can find a bulleted summary of features included in this release on the Github release page. Here are the details of included features.

Moving Towards Standardization

Parameter Locations
Beginning now, rather than accepting parameter locations on bidder-specific parameters, new bidders will be required to conform to standard locations for the following parameters: first party data, floors, schain, video params, page referrer, and COPPA. Currently, bidders that support these parameters do so in a bidder-specific way, which means publishers have to copy the data from different locations and in different ways across different bidders. Since these parameters are often shared across bidders, we’ll be enforcing standard methods for passing these parameters across new bidder adapters, and will require existing adapters to change in a future major release.

Video Parameters
On a similar note, we are introducing another standardization to streamline consumption of OpenRTB video parameters. The vast majority of bidders require OpenRTB parameters for prebid video requests. However, there is currently no standard object for them to retrieve these parameters from in request objects. Rather, the parameters are typically duplicated individually for every bidder in unique or free form taxonomies, creating extra work for publishers and increasing opportunities for error. Adapter reviewers will now enforce that video parameters be retrieved from the mediaTypes.video object. This is an important step towards streamlining implementation of Prebid Video.

meta Taxonomy
Finally, we’ve found that Prebid has historically struggled with making granular data about bid responses easily consumable by publisher analytics and reporting systems, significantly limiting their ability to report and take action on individual ads running on their site.

We’re addressing this by introducing standards in the bidResponse.meta object that we plan on enforcing in future versions. Specifically, we’re outlining that the bidResponse.meta object will contain:

          networkId: NETWORK_ID,
          networkName: NETWORK_NAME
          agencyId: AGENCY_ID,
          agencyName: AGENCY_NAME,
          advertiserId: ADVERTISER_ID,
          advertiserName: ADVERTISER_NAME,
          advertiserDomains: [ARRAY_OF_ADVERTISER_DOMAINS]
          brandId: BRAND_ID,
          brandName: BRAND_NAME,
          primaryCatId: IAB_CATEGORY,
          secondaryCatIds: [ARRAY_OF_IAB_CATEGORIES],
          mediaType: MEDIA_TYPE

Field Scope Type Description
meta.networkId Optional int Bidder-specific Network/DSP ID
meta.networkName Optional string Network/DSP Name
meta.agencyId Optional int Bidder-specific Agency ID
meta.agencyName Optional string Agency Name
meta.advertiserId Optional int Bidder-specific Advertiser ID
meta.advertiserName Optional string Advertiser Name
meta.advertiserDomain Optional array Array of Advertiser Domains for the landing page(s). This is an array to align with the OpenRTB ‘adomain’ field.
meta.brandId Optional int Bidder-specific Brand ID (some advertisers may have many brands)
meta.brandName Optional string Brand Name
meta.primaryCatId Optional string Primary IAB category ID
meta.secondaryCatIds Optional array Array of secondary IAB category IDs [“IAB-222”,”IAB-333”]
meta.mediaType Optional string “banner”, “native”, or “video” - this should be set in scenarios where a bidder responds to a “banner” mediaType with a creative that’s actually a video (e.g. outstream) or native.

While various fields may currently be passed in via bidResponse today, we think it’s important to the future functionality of Prebid to have a standardized taxonomy for this data. You’ll notice a number of important fields, for example meta.advertiserName and meta.advertiserId, that provide publishers with the ability to report against which advertisers are running on their website. This is all with an eye towards eventually being able to implement logic in the page relating to advertiser, DSP, category, etc.

In version 4.0 these fields are not required and this is not a breaking change. However, we expect some or all of these fields to become a requirement in the future. Bidders should begin implementing these fields properly as soon as possible. While not yet a global taxonomy, the bidders actively using the field in the near term will shape the community discussion around the final execution of the standardization.

Staying on top of Privacy

Prebid has developed flexible software solutions to help Publishers conform to TCF 2.0. This release includes updates to Prebid’s enforcement, specifically with regards to TCF Purposes 1 and 2. While Prebid.org can’t provide legal advice, and takes no position with regards to responsibility, we’ve provided an intuitive toolkit for publishers to implement header bidding per their internal requirements. From 4.0 onward, Prebid.js will enforce Purposes 1 and 2 by default, meaning that without consent or legitimate interest, Prebid.js may restrict device access and may remove some (or all) bidders from the auction. All of these settings are of course configurable, and can be changed with modifications to gdpr.rules[].enforcePurpose. See our privacy documents for more details.

Additional Changes and Details

Prebid.js 4.0 also contains a few other changes and coming updates:

  1. Remove AudienceNetwork adapter and Quantum bidder (deprecated).
  2. Stronger enforcement for bidders return bid meta data (#3115 (comment)) needs refinement. PR here #5358.
  3. #3873 - Proposal: set cookie domain in pubcid / userid on main domain, not subdomain.

Detailed discussion and links can be found here.

July 22, 2020

Index Exchange Joins Prebid.org

We are excited to announce that Index Exchange (IX), one of the world’s largest independent ad exchanges, will be joining Prebid.org at the Leader level. Read the official announcement.

March 12, 2020

Prebid.org Support for TCF v2.0

The IAB’s Transparency and Consent Framework (TCF) version 2.0 for enhanced support of GDPR is scheduled to take effect April 1, 2020. This is a major update from TCF version 1.1.

The key changes are:

  • More defined ‘purposes’.
  • More flexibility for the legal bases used by vendors.
  • Different in-page JavaScript API.


Consult with your legal counsel before determining how to utilize Prebid features in support of your overall privacy approach.

The following is a summary of how various Prebid components will support TCF v2.0 and the estimated availability dates:


Support for TCF2 is broken into several phases:

Phase Description Est. Availability
1 DONE - Support a ‘deviceAccess’ flag. Publishers can parse the TCF string on their own and configure Prebid.js appropriately. Released with v3.12
2 DONE - Update the [GDPR ConsentManagement module(/dev-docs/modules/consentManagement.html) to read TCF v2.0 strings and forward to bid adapters. Released with v3.12
3 DONE - Support a ‘default GDPR scope’ flag to allow control over scenarios where the CMP doesn’t respond in time. Released with v3.13
4 DONE - Add a new ‘GDPR Enforcement Module’ to support parsing TCF v2.0 strings and enforcing Device Access. Released with v3.14
5 DONE - Update the GDPR ConsentManagement module to support parsing TCF v2.0 strings and enforcing Purposes 2 Prebid.js 4.0

Prebid Server

Phase Description Est. Availability
1 DONE - Support parsing the TCF v2.0 string and enforcing Device Access. PBS-Go v0.105.0, PBS-Java v1.32
2 DONE - Support parsing TCF v2.0 strings and enforcing Purposes 2, 4, 7 and Special Feature 1 PBS-Go v0.109.0, PBS-Java v1.35.2

Prebid SDK

Phase Description Est. Availability
1 DONE - Support the ‘deviceAccessConsent’ flag and passing TCF v2.0 strings to Prebid Server. SDK v1.5
December 04, 2019

Prebid.js 2.43.0 supports CCPA/US Privacy

Prebid.js 2.43.0 includes a new consent management module for supporting the California Consumer Privacy Act (CCPA). The IAB has generalized CCPA support to cover future regulations, referring to the feature as “US Privacy.”

The module works with supported Consent Management Platforms (CMPs) to fetch an encoded string representing the user’s consent choices, making it available for adapters to consume and process. Bidder adapters can consider making use of this additional consent data in the header bidding auction.

Prebid functionality created to address regulatory requirements does not replace each party’s responsibility to determine its own legal obligations and comply with all applicable laws. We recommend consulting with your legal counsel before determining how to utilize these features in support of your overall privacy approach.

See the US Privacy Consent Management Module page for details and which adapters are supporting the US-Privacy parameter.

October 07, 2019

Prebid.js 3.0 Major Release Announcement

The Prebid core team is excited to announce a major release: Prebid.js 3.0! Here are the main items that will be included in this release:

  • Upgrade all bidder adapters to HTTPS all the time.
  • Removal of miscellaneous legacy APIs and functions (should be a minor publisher impact). (Issue 4118)
  • Unbundle PubCommon ID and Unified ID from the User ID module build.
  • Fix for getHighestCpmBids to not return rendered bids. (Issue 2959)
  • Remove the legacy PBS adapter endpoint support. (Issue 4172)
  • Improve caching behavior if enabled. (Issue 4148)
  • Remove the ‘min’ attribute from custom pricegranularities.

See the full list of items that are associated with the 3.0 release.

Publisher-facing API Changes

Review these changes to make sure you’re ready to upgrade to 3.0.

1. AdUnit.sizes can no longer be used

To upgrade to Prebid.js 3.0, you’ll need to make sure that ad sizes are in mediaTypes.banner.sizes.

For example, instead of including sizes like this:

    var adUnits = [
               code: 'test-div',
               sizes: [[300,250],[300,600]],

You will need to define adUnits sizes like this:

    var adUnits = [
               code: 'test-div',
                mediaTypes: {
                    banner: {
                        sizes: [[300,250],[300,600]]

AdUnit.sizes should not have been used for video player size, but be aware that video requires mediaTypes.video.playerSize. e.g.

    var adUnits = [
               code: 'test-div',
                mediaTypes: {
                    video: {
                        playerSize: [640, 480],

2. The userSync API no longer supports iframeEnabled, pixelEnabled, or enabledBidders

There has been a much more flexible syntax for userSync available for a long time, and it’s what you need to be using now. See the Publisher API docs for more details, but here’s an example of the improved syntax:

    userSync: {
        filterSettings: {
            iframe: {
                bidders: ['def'],  // only this bidder is excluded from syncing iframe pixels, all other bidders are allowed
                filter: 'exclude'
            image: {
                bidders: ['abc', 'def', 'xyz'],  // only these 3 bidders are allowed to sync image pixels
                filter: 'include'
        syncsPerBidder: 3, // and no more than 3 syncs at a time
        syncDelay: 6000, // 6 seconds after the auction

3. Remove legacy protocol support for Prebid Server

You will need to check the s2sConfig.endpoint defined for Prebid Server. If it’s /auction, you’ll need to change to /openrtb2/auction. No other changes are necessary, but you should test the change with your Prebid Server provider.

4. pbjs.loadScript() is gone

If you happen to be using this ancient function, you’ll need to find an alternative.

5. Be aware that the getHighestCpmBids() function will no longer return already-rendered bids

This is a bug that some of you may have implemented workarounds for. More details here.

6. The ‘min’ attribute is no longer used on pricegranularity

The existence of the ‘min’ attribute should not harm existing price granularities, but if anyone has defined price granularities with gaps between the buckets, they won’t work anymore. (EDIT: see box below)

For example, this is no longer possible. (It’s unclear to us why anyone would need this.)

const customConfigObject = {
  "buckets" : [{
      "min" : 0,
      "max" : 5,
      "increment" : 0.01
      "min" : 5.25,             // ignore bids between $5 and $5.25
      "max" : 10,
      "increment" : 0.05

EDIT: since launching Prebid.js 3.0, we’ve discovered that some publishers had explictly defined non-overlapping min/max ranges like 0-0.99, 1-4.99, 5-19.99, etc. Unfortunately, this arrangement doesn’t work as expected in 3.x. Instead of producing values 1.00, 1.05, 1.10, etc. it produces 0.99, 1.04, 1.09, etc. We apologize for missing this breaking change.

7. Specifically pull PubCommon ID and Unified ID into your build

In previous versions, PubCommon ID and Unified ID were automatically included as part of your Prebid.js build when you included the userId module

This is no longer the case; in order for a Prebid.js package to include PubCommon ID and Unified ID, the gulp build command will need to specifically include them.

More details

Implementation details for all Publisher-facing changes are here

Adapter Maintainers Action Required

If you’re responsible for any adapters, be sure you’ve taken the actions outlined here.

1. Ensure your bidder doesn’t use deprecated functions

Referrer detection and related code

Bidder adapters should review their implementation to see if they are relying on getting referrer information from updated APIs in utils.js. If they are, they should instead use the new referrer methods on the bid request (bidderRequest.refererInfo).

Important If you are using a deprecated function, your bidder adapter will be removed from the 3.0 branch. You will need to re-submit compliant code. Please target re-submission by November 1, 2019. This will give enough time for the core team to review and target the release of mid November.

2. Verify bidder supports HTTPS

We ask all bidder adapters to ensure they are compliant with secure requests to their endpoints (HTTPS). It is already a requirement for bidders to support it on secure pages, so hopefully this will not be a big issue. For the 3.0 release the Prebid core team will automatically update all the endpoints to secure if they are not already updated.

3. Verify adapter reads sizes from mediaTypes.banner.sizes

We are telling pubs that they need to confirm that their adUnits define sizes in mediaTypes.banner.sizes instead of just sizes.

Adapter code and examples must be updated to reflect this change.

Target release date

Mid-November, 2019

September 17, 2019

Prebid Meetup and Leadership Summit in San Francisco on Oct 24th 2019

Prebid Meetup and Leadership Summit in San Francisco on Oct 24th 2019

Prebid.org invites you to attend a Prebid Meetup and Leadership Summit in San Francisco on October 24, 2019. Our event will be at the historic Merchant’s Exchange Club. There will be presentations from 1.30–4.30pm, followed by networking and socializing over appetizers and drinks until 6.30pm. Space is limited, so register now to reserve your spot!

What To Expect

The Prebid Meetup and Leadership Summit is an educational event including overviews, deep dives and conversations about Prebid, its evolution, roadmap and vision. It’s a chance to get key insights on the latest Prebid solutions and how they work for different kinds of publishers. Here are a few things you can expect from this event:

  • Insights from member organizations and premium publishers into current best practices and future plans for Prebid
  • Panel discussions on the expansion of header bidding into emerging formats, such as video and native
  • Networking opportunities for publishers and Prebid members
  • And more!

We look forward to seeing you at the event!

June 19, 2019

Prebid Leadership Summit in London on July 11th 2019

Prebid Leadership Summit in London on July 11th 2019

Prebid.org invites you to attend the Prebid Leadership Summit in London on July 11th, 2019. It will be held at the IAB UK venue from 1:30–4:30pm, followed by networking until 6:30pm.


What to expect:

The Prebid Leadership Summit is an educational event including overviews, deep dives and conversations about Prebid and its evolution. It’s a chance to explore the latest Prebid solutions and how they work for different kinds of publishers. In particular:

  • Insights from member organizations and premium publishers into current best practices and future plans for Prebid
  • Panel discussions on the expansion of header bidding into emerging formats, such as video and native
  • Networking opportunities for publishers and Prebid members
  • And more!

Who should attend?

The audience is meant to be Product, Engineering, and AdOps from the Publisher side, so people close to the technology. Space is limited, so be sure to register. Feel free to forward to your colleagues.

Please email event-committee@prebid.org if you have any questions.

We look forward to seeing you at the event!

May 22, 2019

Prebid Leadership Summit in New York on June 11th 2019

Prebid Leadership Summit in New York on June 11th 2019

Prebid.org invites you to attend the Prebid Leadership Summit: NYC on June 11th, 2019, at Xandr’s Razzle Dazzle space in NYC, from 1– 4.30pm, followed by networking until 6.30pm.


What to expect:

The Prebid Leadership Summit is an educational event including overviews, deep dives and conversations about Prebid and its evolution. It’s a chance to explore the latest Prebid solutions and how they work for different kinds of publishers. In particular:

  • Insights from member organizations and premium publishers into current best practices and future plans for Prebid
  • Panel discussions on the expansion of header bidding into emerging formats, such as video and native
  • Networking opportunities for publishers and Prebid members
  • And more!

Who should attend?

The audience is meant to be Product, Engineering, and AdOps from the Publisher side, so people close to the technology. Space is limited, so be sure to register. Feel free to forward to your colleagues.

Please email event-committee@prebid.org if you have any questions.

We look forward to seeing you at the event!

March 05, 2019

4 Ideas from the Barcelona Prebid Summit

(Originally posted on Marfeel’s site, slightly edited for clarity.)

Barcelona Summit

As Mobile World Congress has brought the digital publishing world to us this week, we welcomed our industry partner Prebid.org to the Marfeel’s offices to host their third ever Prebid Leadership Summit. Led by the Chair of Prebid, Alexandra Smith, the mission of the day was to understand the changes leading the header bidding industry, and the role of the Prebid organization in driving these changes.

We were also joined by Remi Boudard from AppNexus, Enrique Blanc from Grupo Zeta, and Lucas Isern and Xavi Beumala from Marfeel, discussing the rise and challenges of adopting server-side header bidding.

To recap the key points for those that weren’t able to attend, we’ve collated everything publishers need to know.

Here are the key takeaways:

1. Header Bidding is still in the early-adopter phase, especially for Server Side

In Europe in 2017, 10-15% of display impressions were generated using header bidding. By the end of 2018, it was closer to 50%. Client-side is still the dominant method of implementation.

Client-side header bidding was always supposed to be a temporary phenomenon before a rapid migration to server-side. This was due to the impact of page-load on the user experience and the efficiency gains provided by server-side.

But, there are still limitations that prevent server-side from being rolled out across advertisers. One of the main challenges for adoption is user identification. When you add an additional step for cookie matching, match rates can go down and in turn, impact monetization. Buyers only bid high when they know who the user is, so losing match rates can severely impact monetization for many. Until universal ID solutions come to fruition, the industry is hindered.

Whats more, web publishers already have working systems for display. There is not currently enough incentive to apply wholesale changes to their approach. They don’t want to spend time and money shifting to a system that will be more advanced and more rigorously industry-tested in a year or so.

Publishers are waiting for companies and organizations such as Marfeel and Prebid to solve these issues before fully committing to server-side.

To bridge this gap, Marfeel has a dedicated team that has built our own header bidding solution, now incorporated into the Prebid open-source platform. Working alongside our publishers and the Prebid organization has allowed us to create one of the industry’s first server-side header bidding solutions, that is live across our publishers now.

2. Mobile will be the driving force for mass-adoption

Most major publishers operate with a hybrid solution, across their formats, such as web, mobile, app, and video. But, running different ad logic for every format is costly and difficult, as is running many SDKs.

However, mass-adoption of server-side header bidding will require a catalyst that proves its value and utility. For publishers, this revolution will start with mobile, since the Prebid Mobile SDK works hand in hand with Prebid Server. Since Prebid Mobile relies on Prebid Server, publishers will begin to adopt it and consider its use-case for web traffic as well. As more and more publishers adopt, the community will dedicate more time and energy to its development.

Once mobile proves the market for server-side header bidding, publishers will start to migrate towards it, making Prebid Server become a unified header bidding solution across all formats and devices.

3. Hybrid Models will dominate 2019 but after that…

No-one at the event was expecting server-side header bidding to be universally adopted by all publishers, across all formats this year. However, the increasing value of this technology and the rise of header bidding in mobile will lead to some major changes.

It’s expected that, with the adoption of EB (Google’s Exchange Bidding) and Prebid Server that SSPs will eventually become commoditized. This may force them to shift into more technology and service-focused companies, helping publishers navigate the complexities of the ecosystem and providing them with the latest developments.

Until this mass-migration to Server, publishers are able to incorporate different Prebid implementations to maximize their revenue, which is where the beauty of the platform lies. However, client-side will gradually evolve to be replaced by server-side header bidding and is likely to spread across all formats after a successful initial implementation across mobile.

4. Header Bidding and Machine Learning = Intelligent Ads

Finally, the results of mass-adoption—though the proving ground of mobile—will enable the development of more advanced systems of header bidding.

The combination of a unified platform like Prebid Server, alongside machine learning, will allow advertisers to break down impressions and revenue by demand partner, ad format, inventory, and region. Publishers and advertisers will be able to track deal performance across multiple exchanges with a single report to see who is winning, where, and be able to infer why.

Machine-learning powered algorithms will segment data by size, ad format, and Google Ad Manager ad unit. Automated systems will see through the entire monetization funnel to spot bottlenecks and eliminate inefficiencies in real-time. Effective server-side header bidding will help facilitate the development of these intelligent ads.

Prebid open-source tech: Deeper development through collaboration The current challenges of Prebid Server go beyond just cookie matching. They stretch to scaling server infrastructure and building creative caching. However, the accelerated development of the Prebid open source tech will create advancements beyond reduced latency, including intelligent ads and ad delivery that comes directly from Prebid server.

The collaborative Prebid organization creates independent standards that benefit everyone. There is no bias because the technology is not created or operated by a single content provider and anyone can build on it and improve it. This collaboration is helping define a transparent industry standard that will ease the path for the implementation of header bidding into publisher’s platforms.

Marfeel’s product manager in our monetization department, Lucas Isern summarized what this ethos will help deliver:

‘Prebid Server is not just Prebid.js without its latencies. It’s an opening door to many more improvements and making crucial steps towards getting out of the browser.’
February 12, 2019

Prebid Leadership Summit in Barcelona on Feb 25th 2019

Prebid Leadership Summit in Barcelona on Feb 25th 2019

Prebid.org invites you to the first Prebid Leadership Summit of the year, taking place in Barcelona during Mobile World Congress on 25 February. The event will take place at Marfeel’s office, from 3:00PM – 6:00PM CET, followed by cocktails until 8:30PM.


What to expect:

The Prebid Leadership Summit is an educational event including overviews, deep dives and conversations about Prebid and its evolution. It’s a chance to explore the latest Prebid solutions and how they work for different kinds of publishers. In particular:

  • Insights from member organizations and premium publishers into current best practices and future plans for Prebid
  • Panel discussions on the expansion of header bidding into emerging formats, such as video and native
  • Networking opportunities for publishers and Prebid members
  • And more!

Who should attend?

The audience is meant to be Product, Engineering, and AdOps from the Publisher side, so people close to the technology. Space is limited, so be sure to register by 18 February. Feel free to forward to your colleagues.

Please email event-committee@prebid.org if you have any questions.

We look forward to seeing you on 25 February!

January 31, 2019

Prebid.js 2.0 Released

Prebid.js 2.0 is a minor major release

Compared to Prebid.js 1.0, the 2.0 release will be a non-event for most sites.

The Prebid.js team has adopted a policy of incrementing the major version number whenever there’s a ‘breaking change’ – a change in behavior we want everyone to be aware of. The idea is that everyone will wonder “what’s with the new version”, and come looking for blog entries like this. For 2.0, the change is:

The “limited bid caching” feature is now off by default.

Any publisher that was utilizing this limited form of bid caching may turn it back on. Do this by calling setConfig() with the useBidCache option.

January 08, 2019

Prebid.org Website Updated


  • Prebid.org is more than Prebid.js: Prebid.js is likely to remain our most important product, but the new website has placed Prebid SDK and Prebid Server on equal footing with it – all products are in their own areas now.

  • Updated Navigation: The top and left navigation elements have been completely revised. The goal was to have everything in the left nav, and the most commonly used pages in the top nav.

  • Adaptive: the site should look better than ever on small screens.

  • Cookie Permission: you may have noticed already that we have a ‘cookie banner’ on the bottom asking for permission to set cookies. If you don’t grant permission, some content like code examples and videos won’t be available. There’s also a new privacy policy.

  • New Content:

Coming Up:

We’d like to have your feedback about the changes and any other things you’d like to see. Email us at website@prebid.org. Here’s what’s on our list so far:

  • Search
  • Left nav for blog pages
  • Differentiate expanded arrow on left nav
  • Clean up extra space at the bottom of the home page
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 Prebid.org

This week, we’re pleased to announce the formation of Prebid.org: 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 Prebid.org 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 Prebid.org.

What’s the background on Prebid.org?

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 Prebid.org: a coalition to champion open-source header bidding and its ongoing development. Prebid.org 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 Prebid.org 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 Prebid.org’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 Prebid.org?

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 Prebid.org. 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 Prebid.org 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 Prebid.org, 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 Google Ad Manager 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 prebid.org, 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 Prebid.org, 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!

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 Prebid.org. 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 Prebid.org 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 Prebid.org! 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.

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 - brightcom.com

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 https://control.adequant.com
      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: "server.nginad.com" // 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 Prebid.org 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: 'adx.adform.net', //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 support@prebid.org.

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 Google Ad Manager, 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 Google Ad Manager 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!