This page has answers to some frequently asked questions about Prebid.js. If you don’t find what you’re looking for here, there are other ways to get help.
Nope. The only approval process is a code review. There are separate instructions for:
As for membership in Prebid.org, that’s entirely optional – we’d be happy to have you join and participate in the various committees, but it’s not necessary for contributing code as a community member.
Below is a set of recommended best practice starting points for your timeout settings:
The former setting is used to track the auction once it started; if it expires, we will use whichever bidders have responded and select the winner(s) accordingly.
The latter setting is used when for some reason Prebid did not load (or there’s some other serious issue); if it expires, we will default to the adserver.
For examples of setting up these timeouts, please refer to the Basic Example page.
See the Prebid Timeouts Reference for more information about timeouts in general.
Every publisher is different. In order to answer this question you’ll need to run some tests, gather data, and decide what works for you based on your performance and monetization needs.
Generally speaking, in a client-side header bidding implementation, you should aim to bring in approximately 1-5 demand partners. In a server-to-server implementation, you have some flexibility to add more partners.
In both scenarios, your goal should be to see your inventory fill at the highest CPMs without adding too much latency in the process. When selecting your demand partners, it’s important to choose marketplaces that have premium demand at scale, high ad quality and low latency.
There is an analysis from the Prebid team here which may be useful:
How many bidders should I work with?
It can. Versions 1.x of Prebid.js would re-consider previous bids under limited circumstances. In Prebid.js 2.0 and later, the useBidCache
option can be used to enable this functionality.
The “limited bid caching” feature applies only:
Since the storage is in the browser, cached bids only apply to a single page context. If the user refreshes the page, the bid is lost.
Each bid adapter defines the amount of time their bids can be cached and reconsidered.
This setting is called “Time to Live” (TTL), documented in the pbjs.getBidResponse
parameter table here.
Examples of scenarios where a bid may be reconsidered in Prebid.js:
Here’s how it works:
targetingSet
or rendered
.You will want to adjust the gross bids so that they compete fairly with the rest of your demand, so that you are seeing the most revenue possible.
In Prebid.js, you can use a bidCpmAdjustment
function in the bidderSettings
object to adjust any bidder that sends gross bids.
Short answer: not out of the box, because of header bidding partners’ limitations. But there are workarounds.
Take GPT synchronous mode as an example - if you’re loading GPT synchronously, there is no simple way of delaying GPT library loading to wait for bidders’ bids (setTimeout()
cannot be used).
Therefore, it requires Prebid.js to run in a blocking/synchronous fashion. This will require all header bidding partners’ code to be blocking/synchronous. We’re not even sure if this is possible. We do not have a great out-of-the box solution for turning Prebid.js blocking at the moment.
Here are a couple of alternative workarounds:
Option 1:
Load a blocking script that has a load time of 300-500ms. This script does nothing but keep the page waiting. In the meantime Prebid.js can run asynchronously and return the bids. After the blocking script finishes loading, GPT can start synchronously; at this point there will be header bidding bids available.
For the best user experience, you probably want to insert this blocking script after the above the fold page content has loaded. Or if you’re okay with additional 500ms latency added to your page load time, this can be easily done.
Option 2:
Use post-bid. The downsides are that post-bid no longer allows your header bidding partners to compete with Google Ad Manager/AdX, but they can still compete with each other. For more information, see What is post-bid?.
All prebid adapters that get merged should automatically detect if they’re serving into a secure page environment and respond appropriately.
In other words, you shouldn’t have to do anything other than make sure your own page loads Prebid.js securely, e.g.,
<script src='https://cdn.jsdelivr.net/npm/prebid.js@latest/dist/not-for-prod/prebid.js' async=true />
(Except that you should never never never use the copy of Prebid.js at that URL in production, it isn’t meant for production use and may break everything at any time.)
See the GitHub release schedule for more details.
Prebid.org does not support any version of Prebid.js prior to the previous version. e.g. if the current version is 4.x, we’ll help debug 3.x, but not 2.x. If you want continued support through updates and documentation you should upgrade to a newer version.
If you need different price granularities for different AdUnits (e.g. video and display), the only way for now is to make sure the auctions don’t run at the same time. e.g. Run one of them first, then kick off the other in the bidsBackHandler. e.g. here’s one approach:
setConfig
to define the priceGranularity for the first set of AdUnitsrequestBids
setConfig
to define the priceGranularity for the second set of AdUnitsrequestBids
The handling of this scenario will be improved in a future release.
One way to limit the number of bytes sent to the ad server is to send only the winning bid by disabling the enableSendAllBids option. However, there are optimization and reporting benefits for sending more than one bid.
Once you find the right balance for your application, you can specify what’s sent to the ad server with targetingControls.auctionKeyMaxChars and/or sendBidsControl.bidLimit
It’s technically possible, but we don’t recommend doing this:
If all this wasn’t enough to warn you away from trying, it should work if you name the PBJS global differently for each instance (Update the value of ‘globalVarName’ in https://github.com/prebid/Prebid.js/blob/master/package.json)
Yes. Many bidders provide metadata about the bid that can be used in troubleshooting and filtering. See the list of bid response metadata and the filtering example.
Yes, but in a way that could cause discrepancies in reporting. It’s recommended that bid adapters resolve OpenRTB macros themselves before giving them to Prebid.js.
For historic reasons, Prebid will resolve the AUCTION_PRICE macro. Header Bidding is a first-price auction, the best candidate for “clearing price” is the original bid itself. Prebid may deprecate this resolution; it is not recommended to be resolved client-side, as it opens opportunities for abuse.
Google is developing this technology to help publishers create and manage line items in bulk. This should enable more publishers to integrate their sites with header bidding on the open web. Here is Google’s official blog post on yield group. This feature is currently in beta production.
What we know about yield group feature:
Sometimes the owner of a bid adapter or other kind of module wants to rename their module. However, Prebid considers module renames a ‘breaking change’ – publishers’ build processes and pages could break as a result of a renaming, so Prebid’s policy on renaming is:
1) Create the new Prebid.js module files (js and md) 2) If they’re basically the same code base, change the old file so that it includes the new file. This prevents duplicate maintenance of code. In general we don’t approve modules including each other, but we’ll approve it to avoid repetition. 3) The docs repo should contain both names, with the old name referring to the new name. You can add the “enable_download: false” flag to prevent installations of the old name. 4) At the next major release the old files may be removed.