Demystifying Header Bidding Bid Caching: Pros, Cons, and Exchange Policies

A losing bid can outlive the auction that rejected it. Bid caching stores a bid response after an auction closes and lets that bid compete again in a later auction, and the practice splits into two behaviors with very different consequences: a limited, in-browser mechanism that Prebid documents and bounds, and a cross-opportunity behavior that trade press exposed in August 2018 and that the IAB Tech Lab defined and restricted in its Programmatic Best Practices of September 16, 2026. Publishers above one million monthly pageviews meet the question through auto-refresh layouts, where a slot re-auctions every 60 to 240 seconds and a losing bid from the initial load can still sit in the browser, priced and ready.

The distinction that governs everything else is opportunity. A bid response arrives with a price, a creative, and an expiration, and the buyer solicited it for one impression in one slot on one page. Reconsidering that bid in a later auction of the same slot, on the same page view, for the same user, is one behavior. Applying it to a different opportunity, another slot or a later page, is another behavior entirely. The first is defensible when it honors the bid's expiration. The second drew buyer objections in 2018 and now carries a formal definition and an expiration rule.

How Prebid scopes the cache

Prebid's implementation runs deliberately narrow, and the Prebid FAQ on limited bid caching spells out its boundaries. Limited bid caching covers only the same AdUnit, on the same page view, for the same user, and only up to a per-adapter Time-to-Live or until the bid wins and the ad renders. The cache lives in the browser, so it covers a single page context: a page reload clears it. Each bid adapter defines how long its own bids stay eligible for reconsideration, which makes the TTL an adapter-level fact rather than a global setting.

The refresh scenario is where the mechanism pays. Auto-refresh reloads an AdUnit on a set interval, often 60 to 240 seconds, without reloading the page itself. Prebid can then reconsider previous bids for that AdUnit across subsequent refreshes, up to the TTL or until they win, and the auction may use a cached bid if its CPM beats the new bids. The cached bid competes head to head with fresh demand, at the exact price the buyer offered the first time.

One distinction decides the operational scope. An auto-refresh keeps the page context alive, so the cache survives slot refreshes, while a manual page reload destroys the context and the cache with it. Caching only has scope where the page view outlives the slot's auction cadence. Inventory your refresh architecture before you touch the flag, because architecture decides whether the mechanism exists at all.

Server-side header bidding moves the wrapper off the browser, and that architectural guardrail does not travel with it. A browser cache cannot outlive the page view, but a server-side cache holds whatever its operator configures, so scope and TTL become questions you ask in writing rather than properties you inherit. The 2018 controversy involved precisely this kind of server-side discretion running without buyer knowledge.

useBidCache: the switch and its history

Prebid exposes the behavior through setConfig, and useBidCache controls it. The option defaulted to true through version 1.39 and flipped to false by default as of Prebid.js 2.0. With the flag off, Prebid.js uses nothing but the latest bids for a given auction. The Prebid setConfig reference documents minBidCacheTTL as well, the companion setting that governs how long the cache holds each bid when caching runs.

Two consequences follow at scale. First, any publisher still on a 1.x bundle runs caching by default unless someone disabled it, so version drift quietly becomes a policy decision nobody recorded. Second, the flip itself carries information: the maintainers moved the practice from default to opt-in after the August 2018 reporting, and the default now encodes their judgment of the risk. When the project that maintains the reference implementation decides a feature should require explicit opt-in, that decision deserves weight in your own config review.

What happened in August 2018

In August 2018, AdExchanger and Digiday reported that a major exchange cached losing bids and applied them to later content without buyer knowledge. Trade press put the behavior at roughly 50 percent of the exchange's impressions. When reporters contacted DSPs about the practice, at least one said its contracts prohibited bid caching outright. The exchange paused the practice after buyers objected.

The objection was mechanical, not sentimental. A buyer offered a price for a specific slot, folding position and viewability assumptions into that price, and then watched the seller spend that price on inventory the buyer had never re-evaluated. From the buyer's seat, the exchange held a free option on every losing bid: keep the price alive, exercise it wherever it wins. Reconciliation made it worse, because a win that ties back to identifiers from an already closed request breaks the audit trail on both sides. The verdict came fast, and it amounted to disclosure or nothing.

The pros, stated precisely

Caching within Prebid's documented limits earns its keep in specific situations. Refresh inventory is the main one, and three mechanisms drive the gain.

• Demand density on refresh auctions. A slot presenting its third refresh offers different conditions from the initial load, and demand tends to thin as slots age. A cached bid adds a competitor to that auction, and it adds the competitor for free: no new request, no added latency, no extended timeout.
• Second chances for near misses. A bid that loses the initial auction by a small margin can win the first refresh at its own CPM. If the adapter fails to respond in time on a refresh call, its earlier bid may still compete, so a timeout on refresh does not zero out that demand.
• Zero technical cost. The bid already sits in the browser. Everything that normally makes header bidding expensive, extra requests and longer auctions, stays absent here. More competition at no latency cost forms the entire case for the mechanism.

All three pros share one weakness: the buyer priced the bid for the initial context, and treating that price as valid at refresh time is an assumption, not a fact. It is also the exact assumption buyers rejected in 2018 when it ran without their knowledge. A cached bid still enters the same ranking logic as any other bid: it clears the reserve or it does not, and it competes on CPM against the rest of the pool. We cover that surrounding machinery, from expected-value ranking to first-price with bid shading and reserve prices, in our guide to auction mechanics and bid shading.

The cons, priced honestly

The cons outweigh the pros at most shops, and they compound. Five of them decide most outcomes.

• Stale context. The cached price encodes the initial load: position, expected viewability, time on page so far. At refresh, those conditions have changed, and the buyer pays its old price for the new situation. When the mismatch runs against the buyer, the buyer has no path back to re-bid, which is the exact grievance from 2018.
• Buyer trust has a price. Buyers who detect recycled bids respond with shading, restrictions, or contract clauses. The 2018 precedent set the template: contractual prohibition on at least one DSP's side, and a pause on the exchange's. A modest lift on refresh auctions makes a bad trade against a buyer that narrows where it will bid.
• Reconciliation exposure. A cached win carries the identifiers of its original request. Your ad server logs one auction, the buyer's systems remember another, and month-end reporting inherits the difference.
• The default is evidence. Prebid.js 2.0 turned the flag off by default, which tells you how the project's maintainers priced the mechanism's risk after watching 2018 play out.
• Forward compliance. The IAB Tech Lab's best practices carry voluntary status for now. If they harden into required supply-path terms, cross-opportunity caching becomes a defect that needs remediation, while same-opportunity reuse within expiration stays defensible. Building to that standard now costs a config review; building to it later costs an architecture review.

What the IAB Tech Lab published in 2026

The Programmatic Best Practices release from the IAB Tech Lab, v1.0, landed September 16, 2026, with the comment window open to October 16, 2026. Two clauses bear on this topic directly. First, no party should store a bid beyond its expiration or apply it afterward, and OpenRTB carries that expiration at the impression level through imp.exp or at the bid level through bid.exp. Second, the document defines bid caching as retaining a bid response and applying it to a future auction for a different opportunity than the original request targeted. Both practices carry voluntary status for now.

The two clauses combine into a workable line. Expiration forms the hard limit: honor imp.exp and bid.exp wherever the bid travels. Opportunity forms the definitional limit: same-slot reconsideration within the bid's life sits inside the letter of the definition, while reuse against a different slot, a different page, or a different user fails it. Preserve both fields end to end, because a wrapper or seat that strips exp leaves you unable to prove compliance even when your behavior complies. For teams wiring seats directly, our API documentation for OpenRTB and VAST integration defines the request and response objects where these fields live.

What the policies say today

Three layers of policy govern the practice right now. One runs in code, one lives in standards, and one lives in contracts.

Prebid encodes its layer in versioned code that anyone can read. Adapter TTLs define cache lifetime per bidder, and useBidCache has defaulted to false since Prebid.js 2.0, so the open-source default says: do not reuse bids unless the publisher opts in. That transparency makes Prebid the most inspectable policy in the stack.

The IAB Tech Lab works through definitions and voluntary adoption. The best practices name the behavior, define it by opportunity scope, and bound it by expiration. Voluntary still binds you through your buyers: a DSP that adopts the practices, or that already prohibits caching in contract as at least one did in 2018, brings the rule to every deal it signs.

Google stays silent on the specifics. As of October 2026, no live Google policy page documents a specific Authorized Buyers rule on bid caching. Read the silence carefully: absence of a written rule offers neither permission nor a defense in a buyer dispute. The operative policy is whatever your buyers' contracts say, plus whatever you disclose.

Our own sell-side setup keeps the question structural. OnlyMedia integrates OpenRTB 2.6 seats and Prebid for header and server-side demand, and our SSP runs one unified auction per impression, with AdX via MCM, Prebid, and OpenRTB seats competing under managed floors. A cached bid in that setup faces the same reserves and the same competition a fresh bid faces, so the decision reduces to scope and TTL, not to auction integrity.

The operating checklist

Configuration beats ideology here, and the sequence below works for publishers above one million monthly pageviews and for the agencies advising them. We are an ad network, an SSP and an agency in one company, so the steps mix technical and contractual actions deliberately.

1. Pin the version, then read the flag. Prebid.js 1.39 and earlier cache by default; 2.0 and later hold the default off unless you enable useBidCache. Whichever state you run, record the decision and the date.
2. Map adapter TTLs against refresh intervals. Auto-refresh cadences commonly run 60 to 240 seconds. A bid whose TTL runs shorter than the interval never gets a second chance, and a bid with a longer TTL can ride several refreshes. Both facts live in the adapter specs, so read them per bidder.
3. Decide per AdUnit, not per site. A 60-second refresh slot and a 240-second slot have different overlap between TTL and cadence, and different exposure to stale pricing.
4. Test in auction-level units. Measure revenue per thousand refresh auctions with the cache on and off, and watch bidder participation for weeks in both states. A lift that coincides with a bidder pulling back counts as a loss, not a win.
5. Preserve imp.exp and bid.exp end to end, and log every application of a cached bid. If a dispute arrives, that log makes the difference between an explanation and a shrug.
6. Collect partner positions in writing. Ask every server-side partner whether it retains losing bids, for how long, and against which scope, and file the answer with the contract.

For agencies, the clause writes itself: a losing bid competes again only for the same opportunity, only within its stated expiration, and only with disclosure to the buyer. Anything wider repeats the 2018 behavior under a different name, and the market already answered that once.

Bid caching is smaller than the argument around it. A browser-side cache that covers one AdUnit, one page view, and one user, respects adapter TTLs, and stays off by default since Prebid.js 2.0, works as a revenue tool with a known risk profile. Cross-opportunity reuse without buyer knowledge is the behavior the market rejected in 2018 and the IAB Tech Lab defined in 2026, and confusing the two costs either money or trust. We work with thousands of publishers, each above one million monthly pageviews, through our curated programmatic demand network, and we pay Net 30, CPM based, with no chasing and no sliding terms. Refresh inventory is where this question earns or costs money, and it deserves the same contractual and technical precision as any other auction parameter.