Programmatic Advertising: What on Earth Is Bid Caching?! 💲🔨💾

By Max Legrand · GreyFox Ads · A French perspective on AdTech

What if an SSP could keep a DSP's bid after a lost auction and reuse it later? Welcome to bid caching — one of programmatic advertising's most intriguing controversies. 💾

Back to 2017: header bidding changes the game 🕐

Remember 2017? Despacito was everywhere, Star Wars dominated the box office and header bidding wrappers were becoming a fixture of the programmatic ecosystem.

For SSPs, it initially felt like liberation: less dependence on Google's historical priority in publishers' auction setups, fewer waterfall negotiations and a better opportunity to compete for each impression.

But there was a catch. Bid request volumes and infrastructure costs rose dramatically, while advertisers' budgets did not grow at the same pace. Competition between SSPs became fiercer — and every unsuccessful auction still consumed computing resources.

What is bid caching in programmatic advertising?

In a conventional real-time bidding process, an SSP sends a bid request to a DSP, receives a bid response and uses that response for the relevant auction. If the bid loses, that opportunity is gone.

Bid caching changes the sequence: the SSP stores a DSP's bid response after an unsuccessful auction, then attempts to reuse it for a later impression that it judges sufficiently similar (rather than asking the DSP to bid again).

The Index Exchange bid caching controversy

The historical case most often associated with bid caching involved Index Exchange. The practice attracted industry scrutiny when buyers learned that bids could be reused without the transparency they expected.

The original issue wasn't merely technical. An SSP making reuse decisions on behalf of a DSP, without clearly disclosing the mechanism, can change the rules of the auction and weaken confidence in the supply chain.

The episode became a subject of reporting in specialist publications including AdExchanger and Digiday. The approach was subsequently withdrawn amid industry pressure (the precise implementation and timeline should be distinguished from the general concept of caching).

Why can bid caching work against advertisers?

A bid response tells an SSP what the DSP is prepared to offer for a particular request. It does not necessarily expose every rule that caused the DSP to approve that request in the first place.

Those rules might include audience eligibility, frequency capping, pacing, campaign budget, contextual restrictions, device characteristics or brand suitability. Two impressions that look similar to an SSP may not be interchangeable to the buyer.

For example, a DSP might bid on a user who meets a campaign's audience criteria at 10:00. Reusing that bid later for another user or context could break the advertiser's intended targeting — even if the placement and creative appear identical.

That is why undisclosed caching raises both transparency and buyer-control concerns.

The idea wasn't entirely bad: fewer calls, lower costs, less waste

Here is the frustrating part: the underlying optimisation is worth discussing. Header bidding, repeated auctions and bid repeating can create substantial duplication across the supply chain.

Repeated server-to-server calls consume infrastructure resources, time and electricity. Reducing genuinely unnecessary requests could improve efficiency for DSPs and SSPs (the actual carbon benefit would need to be measured, not assumed).

Here in France, where the Open Web faces mounting pressure on margins, this is also a question of Supply Path Optimisation (SPO): can we make each transaction less wasteful without sacrificing advertiser control?

What could transparent, buyer-approved bid caching look like?

My proposal is to make caching an explicit, opt-in capability rather than a hidden SSP optimisation. In principle, an evolution of OpenRTB could let the DSP specify:

• Permission: whether this bid may be cached at all.
• Eligibility constraints: the exact placement, audience, contextual, device and other conditions that must remain true.
• Expiry: the maximum permitted time-to-live.
• Controls: revocation, budget/pacing protection, auditability and clear reporting of reused bids.

Such a design would require significant interoperability work, particularly where privacy signals, identity and auction conditions change between requests. It is a proposal, not a claim that today's OpenRTB already offers this complete mechanism.

Publishers could then potentially use a transparent implementation on their own SSP seats to reduce avoidable overhead while strengthening their direct supply paths.

Is buying through AdCP or MCP the same as bid caching?

Not quite. Agent-oriented workflows using AdCP and MCP may help plan, negotiate or book advertising without triggering a new real-time auction for every impression. That makes them interesting when we question whether every transaction needs the same RTB plumbing.

But booking inventory through an agent is not the same technical operation as reusing a DSP's earlier bid response. The similarity is conceptual: both invite the industry to rethink unnecessary repetitive requests. We explored this broader question in Will AI Save the Open Web?

Conclusion: bid caching deserves a second look — with transparency first

The Index Exchange controversy damaged trust because buyers were not adequately in control of how their bids were reused. That lesson still matters.

But should we discard every idea that might reduce redundant auction calls? I don't think so. Transparent permissions, strict eligibility rules and measurable efficiency gains could make a future version of bid caching worth exploring. 😉

Based on the original LinkedIn post by Max Legrand. Historical commentary and future protocol ideas reflect the author's analysis.