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.
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.
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:
pbjs.setConfig({
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.
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.)
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.
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
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.
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.
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.
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.
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.’
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.
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.
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:
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.
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
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 . 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.
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!
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.
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.
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.
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
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.
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.
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.
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:
Add one or more adUnits to your page with the new video-outstream media type
Include at least one bidder on these adUnits capable of ingesting outstream video bid requests
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
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:
If the publisher specifies a renderer, Prebid.js will invoke it across all demand partners
If a demand partner specifies a renderer, Prebid.js will invoke it if and only if that demand partner serves
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.
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.
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.
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:
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.
Prebid is making it easier for publishers to run deals in header bidding!
Benefits:
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.
varadUnits=[{code:'/9968336/header-bid-tag-0',sizes:[[300,250],[300,600]],bids:[{bidder:'sonobi',// New formatparams:{ad_unit:'PER SLOT'// <String> ad unit code}},{bidder:'sonobi',// Old account formatparams:{placement_id:'PER SLOT'// <String> placement Id}}]}];
New adapter for Brightcom - how to add
varadUnits=[{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:
varadUnits=[{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.combidfloor:0.01// OPTIONAL float bid floor in $ CPM}}]}}];
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.
Benefits
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:
varadUnits=[{code:'/9968336/header-bid-tag-0',sizes:[[300,250],[300,600]],bids:[{bidder:'nginad',params:{pzoneid:'7',// <String> PublisherAdZoneIDnginadDomain:"server.nginad.com"// the domain where you installed NginAd}}]}];
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.
varadUnits=[{code:'/9968336/header-bid-tag-0',sizes:[[300,250],[300,600]],bids:[{bidder:'pulsepoint',params:{cf:'300X250',//String adSize identifier cp:123345,//Number Publisher Idct:123456//Number Ad Tag Id}}]}];
How to add bidder IndexExchange:
varadUnits=[{code:'/9968336/header-bid-tag-0',sizes:[[300,250],[300,600]],bids:[{bidder:'indexExchange',params:{id:'TO ADD',//String - id of placement requiredsiteID:TOADD,//Number - site id requiredtimeout:1000,//Number Optionaltier2SiteID:'TO ADD',//String Optionaltier3SiteID:'TO ADD'//String Optional}}]}];
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.
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:
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:
Bidder timeout seems okay. The problem might then be caused by bidders’ lower bid rate:
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?
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:
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.
Prebid.js has a built-in plugin for Google Analytics, i.e. zero development work if your site uses Prebid.js.
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.
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!
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!
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.
Steps:
The webpage sends an impression to the ad server.
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.
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)
FAQ:
1. If none of the post-bid demand sources fill, can I still passback to another tag, say from Adsense?
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?
(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).
Conclusions:
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?
(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.
Conclusions:
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?
(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.
Conclusions:
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.
Recommendations:
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.
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.
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.
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
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
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:
#####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.
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:
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.
Bidders did not design their implementation guide with other bidders in mind.
Bidders all have different targeting parameters.
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.
Conclusion
Enjoy the much more simplified line items, creatives, and targeting setup!
. 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.
(the above data is normalized to CPM = 1 for anonymity)
(The above page has on average 130 HTTP requests, 1.5MB data transferred per refresh)
(The above page has on average 130 HTTP requests, 1.5MB data transferred per refresh)
