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.
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:
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:
for the same AdUnit,
on the same page view,
for the same user, and
up to a certain Time-to-Live (TTL) or until the bid wins and is displayed.
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.getBidResponseparameter table here.
Examples of scenarios where a bid may be reconsidered in Prebid.js:
Auto-refresh: Some pages will reload an AdUnit on a set interval (often 60-240 seconds). Previous bids for that particular AdUnit can be reconsidered for subsequent refreshes of that unit up to the TTL or until they win the unit.
Infinite scroll: As the user scrolls, the same AdUnit may be dynamically created over and over. The bid can be reconsidered for dynamically-created AdUnits with the same name. Again, the bid is only re-considered on that AdUnit up to the bid TTL or until it’s displayed.
Galleries: Some pages feature carousel-style galleries that contain an AdUnit that refreshes as the user cycles through the content in the gallery.
Here’s how it works:
Bid responses are stored in an AdUnit-specific bid pool.
When the same AdUnit is called, Prebid.js calls the bidder again regardless of whether there’s a bid in that AdUnit’s bid pool.
When all the new bids are back or the timeout is reached, Prebid.js considers both the new bids on that AdUnit and previously cached bids.
Previously cached bids will be discarded if they’ve reached their TTL or if they have status targetingSet or rendered.
A cached bid may be used if its CPM beats the new bids.
Bids that win are removed from the pool. This is automatic for display and native ads, and can be done manually by the publisher for video ads by using the markWinningBidAsUsed function.
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?.
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:
Call setConfig to define the priceGranularity for the first set of AdUnits
Initiate the first auction with requestBids
In the bidsBackHandler
Set the adserver targeting for the first auction
Call setConfig to define the priceGranularity for the second set of AdUnits
Initiate the second auction with requestBids
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.