Understanding the Prebid.js Previous Auction Info Module: Practical Implications for Publishers
For publishers, optimizing header bidding goes beyond simply running more auctions. Gaining actionable insights from previous auctions can be key to improving monetization and troubleshooting yield issues. Yet, most Prebid.js setups handle each auction in isolation, missing out on valuable historical data.
The Prebid.js Previous Auction Info module fills this gap. By sharing details from past auctions with bidders, it helps publishers and their ad partners fine-tune their strategies. This article breaks down how it works, why it matters, and what you should keep in mind to get the most out of it.
What Is the Previous Auction Info Module?
The Previous Auction Info module is an optional feature in Prebid.js designed to pass historical auction data to bidders. When enabled, it keeps track of bids, auction results, and related metadata for a limited number of previous auctions. This historical perspective can be injected into subsequent bid requests, allowing bidders to optimize their offers based on actual outcomes rather than blind guesswork.
Why Share Past Auction Data?
Bidder behavior is heavily influenced by feedback loops. Without knowing whether they won an impression, what the winning price was, or if there were errors, bidders operate with limited feedback. By supplying details like winning CPMs or error reasons, the Previous Auction Info module can help bidders submit more competitive bids or troubleshoot previous failures—aligning their bidding logic more closely with actual publisher needs.
Examples of Data Shared
Sample historical data points include:
– Whether a bidder’s ad was actually rendered (not just served)
– The highest CPM submitted for an ad slot in the last auction
– The currency of winning bids
– Bidder-specific errors, such as invalid request IDs
– Timestamps for when those events occurred
This empowers bidders to refine their models, potentially leading to better outcomes for publishers.
How To Enable and Configure the Module in Prebid.js
Activating Previous Auction Info requires intentional setup. By default the module is off, so publishers need to explicitly include it in their Prebid.js build and adjust their configuration. Here’s a high-level look at the process:
Step-By-Step Configuration
1. Download or build Prebid.js with the “previous auction info” module enabled.
2. In your Prebid.js setup, enable the module in your config:
pbjs.setConfig({ previousAuctionInfo: { enabled: true, bidders: [‘bidderA’, ‘bidderB’], maxQueueLength: 10 } })
– ‘enabled’ activates the feature.
– ‘bidders’ specifies which partner codes should receive this info. Leave it blank to include all bidders.
– ‘maxQueueLength’ limits how many prior auctions to track per bidder. Default is 10 if omitted.
Only bidders listed and actively supporting the module receive this data. This means both sides (publisher and bidder) must opt-in for full benefit.
How the Data Flows: Real-World Auction Cycle Example
Understanding when and how auction data is collected and injected can help avoid configuration errors and explain seemingly odd bidding patterns. The flow works as follows:
Auction-to-Auction Data Transfer
1. An auction is initiated and runs as usual in Prebid.js.
2. When the auction ends, the module collects results (e.g., which bids won, which failed, what CPMs cleared) for eligible bidders.
3. If a bid wins and is rendered, this gets marked in the data (‘rendered: 1’).
4. When the next auction fires, if any listed bidders are present, their previous-auction data is bundled into their new bid requests in the path ‘ortb2.ext.prebid.previousauctioninfo.’
5. As soon as the info is sent for a particular bidder, it’s deleted from the queue to avoid accumulating stale data.
For example: If ‘bidderA’ bid on adUnit123 in the last auction and is included in the next, bidderA’s bid request will carry a complete history of previous outcomes for that slot. This can improve bidder targeting, help spot floor price issues, or shed light on CPM trends over time.
Key Configuration Pitfalls
– If the module isn’t built into Prebid.js, the configuration will be ignored—double-check your custom build.
– Including too many bidders, or storing too many auction results, can increase payload sizes and potentially add latency.
– Only bidders who support the module and are listed in the config will ever see this data.
Decoding the Previous Auction Info Payload: Field-by-Field Review
To maximize the value of this data, publishers and their tech partners need to know what each field means. Here’s a breakdown of key fields you’ll see in the ‘previousauctioninfo’ payload, and why they matter for troubleshooting or optimization:
Key Fields and Their Uses
– bidderRequestId and bidId: Track which bidder and bid these data refer to; essential for debugging issues.
– rendered: Indicates if the bid actually made it to the page, not just if it won the auction.
– source: Shows which prebid integration (e.g., ‘pbjs’) collected the data.
– adUnitCode: Pinpoints which ad slot this result describes—crucial when correlating yield drops or errors to specific placements.
– highestBidCpm & highestBidCurrency: Reveal the competitive landscape for the slot in that auction.
– bidderCpm & bidderOriginalCpm: Show what a given bidder actually submitted (before and after potential adjustments).
– bidderCurrency & bidderOriginalCurrency: Help you spot if currency conversion or mismatches affected auctions.
– rejectionReason: Flags why a bid may have failed (e.g., invalid request), useful in root cause analysis.
– timestamp: Lets you tie auction data to site events or analytics logs.
What this means for publishers
Enabling the Previous Auction Info module increases transparency into your auction environment and empowers bidders to respond to real-world performance. It can drive up bid competition—especially if your partners use the historical data to adjust bids after missed opportunities or errors. However, it also means sharing more auction intelligence with bidders, so publishers should balance data sharing and partner trust. The operational impact includes more data-driven troubleshooting, better detection of bid suppression or errors, and the opportunity for smarter yield management across ad units.
Practical takeaway
For publishers using Prebid.js, the Previous Auction Info module is a strategic lever—especially for troubleshooting and maximizing header bidding yield. To get started, ensure your Prebid.js build includes the module, and configure it to only share data with trusted, technologically-ready bidders. Regularly review the payload data and monitor how bidder behavior shifts in response.
Stay alert for payload bloat or latency if storing too many auction histories, and audit which partners actually make productive use of the data. If bidders start bidding more accurately or reduce error rates, you’re likely seeing positive impact. Ultimately, this feature is best treated as an advanced optimization tool, not a set-it-and-forget-it switch: periodically review, fine-tune recipient bidders, and use payload insights to fuel optimization and troubleshooting efforts.
