Bid caching was in the news recently because of unfair practices being employed by some of the major ad tech players. But what exactly is it?

Bid caching is the practice of utilizing a lost bid from one auction to fill a subsequent auction for the same user. But why would someone do that?

Why Setup Bid Caching?

Publishers generally end up caching bids because it helps them achieve better CPMs. Imagine that we have a request for an impression and 4 header bidding partners bid $5, $4, $3 and $2 respectively. With no caching of bids involved here, the $5 bid would win and all the other advertisers would lose out an opportunity to serve the ad. With bid caching involved, however, all the lost bids from this auction will be able to compete in the next one, once there is a chance to serve an ad to the same user in the same context again.

This is a win-win situation. The advertiser gets to serve the ad for the intended user and the publisher ends up reaping the rewards of better CPM.

All of this sounds a little complex. But there is more. People often confuse bid caching with ad caching. These are two separate concepts.

Ad caching is when an auction is conducted in advance in order to reduce ad serving latency and improve the user experience. For example, a mobile game might conduct an auction during gameplay in order to fill an interstitial ad that renders between game levels. Ad caching is especially useful in environments with poor internet connection speeds and unreliable connection quality.

If we break this definition piece by piece, we’ll know why there is a right way and there is a wrong way to do this.

The right way

• The bid is cached for the URL declared on the original bid request
• The bid is cached for the same ad unit
• The bid is cached for a small period of time (a few seconds)

The wrong way

• The bid is cached for a URL not declared in the original bid request
• Bid cached for one ad unit being used for other units
• A bid is cached for longer periods (a few minutes)

The Index Exchange bid caching debacle raised many eyebrows because they were using sneaky ways to implement cached bids on more than one URL and for different ad units. So when a DSP placed a bid for impression ‘123’ on the site ‘xyz.com’ for user ‘ABC’ at a time ‘T’ and the DSP lost that auction, that bid was being used instead for some other impression entirely, perhaps on a different URL. As an advertiser of this DSP, you won’t feel particularly good about your bids being applied to anything but the exact impression that you bid on.

In accordance with the above fair practices, there are only certain scenarios where bid caching should be applied:

• Auto-refresh: Some pages will reload an ad unit on a set interval (often 60-240 seconds). Previous bids for that particular unit can be reconsidered for subsequent refreshes of that unit up to the TTL or until they win the unit.
• Infinite scroll: As the user scrolls, the same unit may be dynamically created over and over. The bid can be reconsidered for dynamically-created ad units with the same name. Again, the bid is only re-considered on that ad unit up to the bid TTL or until the impression is won.
• Ad-Galleries: Some pages feature carousel-style galleries that contain an ad unit that refreshes as the user cycles through the content in the gallery.

The Process

Here’s how the process of caching of bids unfolds:

1. Bid responses are stored in an ad unit-specific bid pool.
2. When the same ad unit is called, Prebid.js calls the bidder again regardless of whether there’s a bid in that unit’s bid pool.
3. When all the new bids are back or the timeout is reached, Prebid.js considers both the new bids on that ad unit and previous bids that haven’t reached their TTL.
4. The cached bid is only used if its CPM beats the new bid.
5. Bids that win are removed from the pool. 

Assuming you have a fair idea now of bid caching in Prebid, let’s find out as to how you can implement this on your website.

Caching Bids in Prebid

Prebid, the open-source and the most popular Header Bidding wrapper also offers an option to cache bids but this is done basis a TTL(Time to Live). TTL defines the amount of time until the bids of the partner bidder can be cached and reconsidered.

As mentioned above in the fair practices of implementing Prebid, there is only very limited scope where this bid cache applies to:

• for the same ad unit,
• on the same page views,
• for the same user, and
• up to a certain TTL

The effort you will have to put in to enable caching of bids varies by the version of the Prebid adaptor that you are using.

Prebid Version <2

Enabling bid caching here requires no additional effort. If you have header bidding configured correctly, this should work fine for you, as this functionality is enabled by default for up to Prebid version 2.0.

Prebid Version >2

For versions above 2, you’ll have to manually enable this in Prebid. It can be done in the config section just by enabling the following command:

pbjs.setConfig({ useBidCache: true })

Given it is that easy to implement bid caching on Prebid, publishers should not shy away from implementing this and benefitting from its use.

---