Deconstructing the Header Bidding Auction
In modern programmatic advertising, every millisecond matters. When a user loads a webpage, a complex header bidding auction begins behind the scenes to determine which advertiser wins the impression. Nowhere is this more apparent or financially impactful than in the world of online advertising, specifically in Header Bidding.
In this post, we’ll explain the many layers of this invisible auction analytics using a technical timeline diagram as our guide. We’ll explore the lifecycle of a Prebid.js auction, focusing on the critical interplay of bid response times, network latency, and auction timeouts. Understanding this isn’t just about increasing revenue, it’s about protecting user experience and ensuring the long-term health of your digital business.
Inside the Header Bidding Auction Process

Let’s slow down something that happens incredibly fast.
When a user lands on your website, a fast header bidding auction immediately runs behind the scenes to determine which advertiser shows an ad. More importantly, this process generates a rich stream of analytics signals. Each bid, response time, and decision point creates data revealing which bidders maximize your revenue, which slow down your page, and how to balance the two. This auction isn’t just a technical detail – it’s the core of modern programmatic advertising, and analytics is the lens through which you can measure and optimize your entire monetization setup.
Using our timeline diagram as a guide, let’s walk through what happens between 0ms and 1200ms (milliseconds), and what each moment tells us from an analytics perspective.
0ms: Ad Requested
When a user loads the page, the auction process starts with the download and execution of the Prebid.js library. The Prebid.js bundle is optimized to remain lightweight and is cloud-hosted to minimize latency.
Once executed, Prebid.js initializes bidder adapters, issues parallel bid requests to demand partners, and aggregates bid responses before passing the results to Google Ad Manager (GAM) for final auction decisioning.
At 0ms, the auction clock starts.
Prebid.js – an open-source JavaScript library embedded in your page head – initiates the header bidding auction.
The system constructs each bid request from your adUnits configuration, incorporating details such as format, size, page context, and various identifier solutions:
- Prebid Client – Sends separate requests from the browser to each demand partner, which can introduce latency but generates most revenue.
- Prebid Server – Sends a single request to the Prebid Server, which then forwards requests to all server-to-server (S2S) demand partners. It reduces browser-side latency and improves performance, typically representing 20–40% of total Prebid demand.
400ms: Bid Responses Arrive (Latency in Action)
By around 200ms, fast-responding SSPs begin returning bids, while the vast majority respond at around 400ms. Bid Response is the formal data packet that an SSP sends to the browser’s header-bidding wrapper.
Response Transmission: The bid response – containing the bid price, creative markup (or creative ID), and associated metadata – is returned to the user’s browser. The total round-trip time, including network latency, SSP processing, and the return journey, was 400ms for SSP1 and 600ms for SSP2. Since these responses arrived before the Auction Timeout, they qualify as valid bids in the Prebid.js auction. Prebid stores all bids received within the timeout window and selects the winner. Prebid passes the winning bid to Google Ad Manager (GAM), which serves the corresponding creative to the user.
Winner Selection & Creative Assembly: every SSP selects its highest internal bid and packages the corresponding creative (HTML, JavaScript, or VAST) into a response object.
Even though SSP2 had higher latency, its bid price was higher than SSP1’s. Therefore, Prebid.js selects SSP2 as the winner of the header bidding auction and forwards the bid to GAM for user delivery.
Average Latency in Header Bidding Explained
Average latency is the typical time it takes an SSP to respond to a Bid Request. Higher bid density improves auction performance, but publishers must balance this against the browser’s total wait time.

The result reflects the combined impact of:
- User-side factors, like browser performance and the particular Prebid setup weight
- Network conditions (geo, internet speed, and bid density)
- Demand-side processing according to each SSP infrastructure’s capabilities
Prebid stores low-latency bids, which remain eligible when the auction closes. While a healthy bid density fosters competitive bidding and higher CPMs, excessive demand partners can slow down the page. Every publisher should experiment to find the optimal balance that maximizes revenue without compromising user experience.
1000ms: The Auction Timeout
Most header bidding setups operate under a strict timeout – commonly 1000ms. Meanwhile, you can still see plenty of publishers using the default 3000ms setting.
When the configured timeout expires, the auction closes; any network connections still waiting for a bid response are closed, and Prebid proceeds only with the valid bids received within the timeout window.
This timeout represents a deliberate tradeoff between waiting longer to potentially receive higher bids and protecting page performance and user experience.
Why Ideal Timeouts Exist
The main constraint is the user experience: longer auctions delay page rendering, cause layout shifts, and decrease viewability. Timeout is a predetermined setting, meaning it does not adapt in real time to bid behavior. However, the analytics data can indicate a point beyond which a longer waiting period does not increase competition.
In practice, timeout configuration often reflects a balance between Prebid demand and Google AdX demand. Shorter timeouts tend to favor faster paths (Adx); longer timeouts favor broader competition (Prebid). Analytics reveal where the current balance sits – and whether it’s working to generate maximum revenues.
Publishers typically track three timeout types: Client timeout (for initial browser-side bids), Server timeout (for S2S partner responses), and the Refresh timeout, which can be set significantly longer than the first-load timeout because an ad is already visible to the user, allowing more time for bidders to compete without impacting the user experience.
Together, these timeouts optimize revenue potential while keeping auctions predictable and user experience smooth.
It’s also important to note that direct campaigns in a publisher’s Google Ad Manager will receive the impression regardless of header bidding results, particularly those running in Sponsorship or Standard priorities. It means that even if the header bidding auction produces a high bid, the impression can still be allocated to these direct campaigns, limiting the auction’s impact on certain impressions. Only the direct campaigns in price priority compete in the Header Bidding auction.
This auction operates within a strict 1000ms timeout as part of the page’s overall latency budget. The system discards any bids that arrive after this window to ensure deterministic completion of the auction. It prevents the auction from blocking the browser’s rendering pipeline and ensures the ad decisioning process finishes on schedule.
1200ms: No Bids and the Late Bid discrepancy
The auction ends with a timeout, and the system records all SSPs that didn’t bid as “No bid” at 1000ms. To clarify the full picture (timeout diagram), we only assume there was another bid at 1200ms. In fact, there was no response after the 1000ms timeout because the SSP3 was late, which contributed to a higher SSP3 timeout rate in the analytics. Even if the bid price had been higher than all others, Prebid already discarded it as ‘no bid’ due to the timeout. From the auction’s perspective, such a late bid is equivalent to no bid at all.
The Hidden Cost of Late Bids
There is no other way to evaluate the revenue potential from the No Bids than by increasing the timeout and observing if the SSPs manage to return their Bids. E.g., increasing to 1200ms would allow all three SSP1, SSP2, and SSP3 to compete with their bids.
Meanwhile, there are hidden costs associated with Late Bids that arrive shortly before the Timeout. Publisher GAM recorded a Winning Bid. However, the demand partner failed to render the ad before the user left, which is a primary source of discrepancies between publisher GAM reports and SSP reports. The ad didn’t render because the bid was close to a timeout, and the user left the page right after the timeout. This results in the SSPs or GAM reporting revenue that the Publisher never actually sees in their bank account. To resolve this misalignment, implement an additional bid price adjustment in the Prebid settings.
What Rates do Analytics Measure
This phase is all about participation:
- Bid rate (response rate): How often an SSP responds to bid requests. E.g., SSP1 and SSP2 in the diagram.
- Win rate: How often an SSP wins. E.g. SS2
- Timeout rate: How often an SSP fails to respond before the auction timeout. E.g. SSP3.



These rates help distinguish the SSP’s technical capability from demand strength and determine whether the SSP is timing out or simply lacks demand strength.
An SSP that rarely responds isn’t really competing- even if it’s technically “integrated.” Over time, low response rates reduce auction pressure and suppress CPMs. Analytics here help publishers distinguish between theoretical demand and real, active demand.
Understanding and Using Win Rate
Win Rate measures how often an SSP wins when it submits a valid bid. It reflects competitive success once the SSP is actively in the auction. That distinction is important because Win Rate on its own does not indicate value – it must be interpreted in context.
Unlike the Prebid Stack report, which focuses on outcome metrics such as eCPM, impressions, and revenue, Win Rate explains competitive positioning. The Stack report tells you what happened. Win Rate helps explain why it happened. An SSP with a high eCPM may appear strong in the Stack report, but if its Win Rate is very low, it may be bidding selectively rather than competing broadly. Conversely, an SSP with a moderate eCPM but a consistent Win Rate may exert steady auction pressure and contribute more to overall yield stability.
Win Rate becomes actionable when evaluated alongside participation and latency data. For example, a low Win Rate combined with a high Bid Rate suggests the SSP is participating frequently but losing on price. That points to demand competitiveness. However, a low Win Rate combined with significant timeouts indicates a technical or latency constraint rather than weak demand. Without this broader context, it is easy to misdiagnose performance issues.
It is also important to recognize what the win rate does not tell you. A high Win Rate does not necessarily mean the SSP is paying the highest market price. In some cases, it may reflect limited competition or specific auction mechanics. Similarly, a low Win Rate does not automatically mean the SSP lacks value; it may still exert meaningful price pressure, improving clearing prices across the auction.
Ultimately, Win Rate should be used as a diagnostic metric rather than a success metric. While revenue and eCPM reflect direct financial outcomes, Win Rate indicates how effectively an SSP competes in the auction environment. When analyzed alongside bid participation, timeout behavior, and pricing data, this analysis provides a clearer understanding of whether demand strength, technical constraints, or auction dynamics drive performance.
Optimizing the Header Bidding Auction with Actionable Insights
Understanding auction analytics is only the first step. The real value comes from turning these analytics signals into concrete optimization decisions.
Our Actionable Insights in Practice
To simplify the optimization process, our platform generates specific, logic-driven insights based on the real-time data from prebid. Instead of guessing the optimal settings, actionable insights make it easy to identify the changes needed to increase the win rate and Prebid efficiency for both client-side and server-side connections.
Recovering Potential Revenue Loss
The platform flags instances where a bidder’s CPM is more than 10% above your average, but their timeout rate exceeds 15%. In these cases, the data shows that high-value demand is being lost simply because the bidder cannot meet the current auction window. We interpret this as a “near-miss” revenue opportunity and recommend increasing that specific bidder’s timeout threshold by 200ms to capture those aggressive bids.

Addressing High Volume / Low Yield
When we see a bidder with a win rate over 15% but a CPM more than 20% below your average, it indicates they are winning significant inventory at a price point below the market’s true value. Our system identifies this as a “low-yield” scenario and recommends raising the floor prices for that bidder, forcing them to bid more competitively to win and ensuring you aren’t leaving money on the table for high-demand inventory.
Mitigating High Latency Impact
Performance is just as important as revenue. If we find a bidder with latency over 800ms (or 20% above average) that contributes less than 1% of your total revenue, our platform identifies them as a performance risk because their minimal financial contribution does not justify the “latency tax” they place on your Core Web Vitals.

Removing Non-Performing Bidders
To keep your wrapper efficient, we monitor for bidders with a bid rate below 1% and zero impressions, or those bidding at negligible CPMs. These partners consume client-side HTTP requests and bandwidth without providing any competitive pressure or revenue. Our platform identifies these non-performers so you can prune them from your stack, reducing overhead and improving response times for your top-tier bidders.

Summary
Ultimately, the Prebid auction lifecycle balances speed and competition. Analyze data points from 0ms to the final ‘Bid Won’ event to understand the ‘why’ behind performance, moving beyond surface-level revenue metrics. Analytics reveal whether an SSP consistently misses the timeout cutoff or has low latency – rather than superior bid prices – driving a high Win Rate. Fine-tune timeouts and demand partners using real-world participation data to ensure every millisecond of the user experience contributes to the long-term health and profitability of your digital business.


