A bid response in OpenRTB carries a price, a creative, a TTL, and a timestamp. Bid caching takes that response, stores it after the auction that produced it, and reuses it in a later auction instead of calling the demand partner again. The mechanism saves money on request costs, reduces latency, and improves fill on refresh-driven inventory. It also introduces a set of problems that the OpenRTB specification itself flags: cached prices no longer reflect current market conditions, and a cached creative may render for a user whose context has changed since the bid was made. Publishers who run header bidding at scale need to understand both sides of this trade and put a written policy around it, because the decision to cache sits at the intersection of revenue, fairness, and compliance.
How bid caching works in OpenRTB
In a standard OpenRTB flow, the publisher's ad server or header bidding wrapper sends a bid request to a demand partner, the partner responds with a bid, and the auction resolves. Without caching, a bid that loses the auction, or a bid that wins but never renders because no impression fired, simply expires. With caching, the wrapper or SSP stores the bid response in memory or in a server-side store keyed by ad unit, size, and bidder, then consults it on subsequent auctions until the bid's TTL runs out.
The TTL is the central control. Under bid caching and TTL rules, each adapter declares how long a bid can be cached and reconsidered for refreshes, and the wrapper enforces that boundary. A display bid might carry a TTL measured in minutes, while some video and native bids allow longer windows. Once the TTL passes, the cached entry expires and the wrapper must request a fresh bid. Bidders also signal bid status, and a cached bid that was already consumed by an impression should not serve twice, so the cache layer tracks usage state alongside price and creative ID.
Caching happens at several points in the stack. A client-side wrapper can cache bids in the browser between refreshes of a single page session. A server-side component can cache bids across pages or sessions. An SSP can cache bids on the publisher's behalf inside its auction infrastructure. Each layer changes who controls the TTL logic and who sees the effects. When the cache sits inside your own wrapper, you set the policy. When it sits inside a partner's infrastructure, you depend on that partner's implementation, and you should ask direct questions about it.
There is a related but distinct concept worth separating: creative caching for video. Under video bid caching explained, video bids cache server-side and map to a cache ID that the video player retrieves at render time, so the VAST tag travels through a short identifier rather than the full creative payload. That form of caching solves a transport problem, an oversized bid response in a header, and it does not imply that the bid price itself gets reused across auctions. Publishers evaluating caching behavior in their stack should distinguish creative payload caching from bid price reuse, because the two carry different risks and different policy answers.
Where cached bids enter the auction path
To govern caching, a publisher first needs to know where in the auction path cached bids actually compete. The typical insertion points are refresh auctions, unfilled slots, and timeout fallbacks.
Refresh auctions are the most common case. When a page auto-refreshes an ad slot every 30 or 60 seconds, the wrapper can reuse a bid cached from the first auction for the second slot load, provided the TTL covers the interval. This produces an immediate bid without a round trip, which cuts request volume and protects the page from added latency. The cost is that the second impression sells at a price set before the second impression existed.
Unfilled slots form the second case. If an auction returns no bids for a size, some implementations store whatever partial demand arrived and retry it against a later opportunity. This raises fill rate on hard-to-monetize placements, especially long-tail geo traffic where request latency can exceed bid timeout windows.
Timeout fallbacks form the third. When a demand partner responds after the auction deadline, the wrapper can store that late bid and use it on the next auction instead of discarding it. Late bidders lose auctions by a few hundred milliseconds regularly, and caching converts that wasted latency into usable demand. The risk: the late bid reflects a request context that is now one or more auctions old.
The measurable benefits for publishers
The benefits of caching fall into four categories, and each one is measurable with the right instrumentation.
Request cost reduction comes first. Every OpenRTB request carries infrastructure cost for the publisher's wrapper, for the SSP, and for the demand partner, and partners that see excessive request volume with low win rates often shade their bids or deprioritize the inventory. Caching cuts request volume on refresh-heavy pages, which keeps demand partners willing to bid aggressively on your inventory.
Latency reduction comes second. A cache hit returns a bid in milliseconds instead of the 200 to 400 milliseconds a partner round trip can take. On refresh slots and interstitials, that difference shows up directly in viewability and in user engagement on the page.
Fill rate improvement comes third. Slots that would otherwise go unfilled during a partner's slow response window can serve cached demand instead. For publishers with traffic in regions where partner response times run long, this effect can move fill meaningfully. You can verify it by comparing fill rate by geo before and after enabling caching, or by segmenting in your analytics by cache hit versus fresh bid.
Price stability comes fourth, and it cuts both ways. A cached bid holds a price from an earlier, possibly stronger auction. If the first auction ran during a high-demand period and the refresh runs during a trough, the cached price can beat what a fresh auction would return. The reverse also holds, and we cover it below.
The risks: staleness, price distortion, and auction fairness
The core problem with a cached bid is that it prices a moment that has passed. OpenRTB bid responses represent a buyer's valuation of a specific impression opportunity, with its user, context, and time. When that bid serves against a different impression, the price no longer reflects the buyer's actual willingness to pay.
Staleness produces three concrete failure modes. First, price distortion: the publisher may report revenue based on cached prices that fresh auctions would not confirm, which inflates estimates and distorts yield analysis. Second, context mismatch: a bid priced against one page context may render on another, which harms advertiser performance and can depress future bidding on your inventory. Third, double-serving risk: without strict usage tracking, a cached bid can be consumed more than once, which creates discrepancies between what the wrapper reports and what the demand partner's impression log shows, and discrepancies become billing disputes.
Auction fairness is the second order problem. In a header bidding auction, cached bids compete against fresh bids. A cached bid priced five minutes ago may systematically beat fresh bids from partners that invested in fast responses. Over time this penalizes the fastest, most responsive demand and rewards slow partners whose bids get a second life through the cache. That dynamic can degrade the quality of demand your auctions attract, because responsive partners see lower win rates against stale competition and adjust their behavior.
Privacy adds a third layer of risk. A bid generated under one consent state may be cached and served under another. If a user withdraws consent between the original auction and the cached serve, the cached bid's targeting and reporting may no longer comply with the signals the user has provided. Under TCF and Global Privacy Control, publishers carry responsibility for how consent signals propagate through the supply chain, and a cache layer that ignores consent changes creates real exposure. The SupplyChain object and sellers.json entries describe the transaction path, but a cache that reuses a bid across contexts can break the accuracy of that description.
Policies a publisher should publish
Caching decisions belong in written policy, not in wrapper defaults. We recommend publishers adopt an explicit caching policy and share it with demand partners and internal ad ops teams. A workable policy covers five areas.
TTL enforcement comes first. The policy should state that the wrapper honors each bidder's declared TTL without extension, and that expired bids never serve. If your stack allows a global TTL override, the policy should define when that override applies and who authorizes it.
Refresh rules come second. Define which placements may use cached bids on refresh and at what refresh intervals. Short intervals inside the TTL window are the safest use case, because the context change between impressions stays minimal. Long refresh intervals with cached bids carry the highest staleness risk and deserve stricter limits.
Consent propagation comes third. The policy should require that a cached bid only serves when the consent state at serve time matches the consent state at request time. Any consent change, including a Global Privacy Control signal arriving mid-session, should invalidate cached entries for that session.
Discrepancy and usage tracking comes fourth. Each cached bid needs a consumed flag, and the policy should specify that a bid serves at most once. Pair the policy with a discrepancy monitoring routine that compares wrapper-level win and impression counts against demand partner reports weekly, so cache-related discrepancies surface quickly rather than at month-end reconciliation.
Disclosure comes fifth. Your header bidding policies page should describe your caching behavior in plain terms: which layers cache, what TTL rules apply, and how consent changes are handled. Demand partners price your inventory partly on trust in your auction mechanics, and disclosure reduces disputes before they start.
How we approach cached demand
At WireAds, we treat caching as a controlled optimization rather than a default behavior. Our SSP enforces bidder-declared TTLs, tracks bid consumption so a bid serves once, and invalidates cached entries when consent state changes. Because we combine Prebid, OpenRTB, Google MCM, Google AdX demand, and direct deals into a single auction, we need the auction to reflect current prices, and uncontrolled caching would distort exactly that. We pay Net 30 on confirmed revenue, which makes discrepancy prevention a shared interest: cached bids that inflate reported wins help no one when reconciliation arrives.
For publishers, the practical takeaway is a set of questions to ask any partner that caches on your behalf. Where does the cache live? What TTL rules apply? How does the cache handle consent changes? How are cached wins reconciled against demand partner impression logs? A partner that answers those questions clearly, with numbers, is a partner you can build a caching policy around. A partner that cannot answer them is telling you something too.
