Table of contents
In August 2018, Index Exchange found themselves in the middle of an ad tech controversy, following the revelation that they had been engaging in bid caching for more than a year. The company claimed to have believed that the feature was standard procedure in the industry, however, rival exchanges argued otherwise. In this post, we’ll cover what bid caching is, why it’s a problem and what it means for publishers.
What is bid caching?
Bid caching is the process of storing a bid when a buyer fails to win an impression and then applying that bid to a later ad-request. The usual aim of bid-caching is to reduce latency (and therefore faster ad-serving), but it can also push up CPMs. This has caused concern as it can result in buyers paying for an impression that doesn’t quite match what they thought they were getting. Whilst Index Exchange argued that bid caching is a smart innovation, others argued that the company were bending the rules for their own gain.
For example: A user visits the homepage of a publisher’s site and attracts bids from 5 partners. Bidder A wins the impression and the other bids are cached. The user then opens a second page and the cached bids are then applied to the resulting ad request. Bidder B wins, using the price they were willing to pay for the homepage impressions, but their ad is shown on a deeper page.
What’s the problem?
Initially, the main issue with bid caching was the lack of transparency; Index Exchange were implementing the feature through their header bidding wrapper without disclosing this to buyers. This is problematic because it means that buyers often overpaid for impressions that were being served deeper into the user session. If buyers aren’t getting what they think they are buying then this is bad for all parties, as it reduces trust in the system which will only send bids in one direction. Dan Wilson, CEO of London Media Exchange put it well:
“It’s like going to a supermarket and getting beans, and at checkout, they swap it out for something else.”
Bid caching poses a risk to advertisers around quality and brand safety – although the ad is served on the same domain, it is not served on the same page. This means that there is a possibility that the context of a webpage and targeting criteria for users will not be identical to that of the previous auction, thus buyers aren’t always getting what they paid for.
The quality of the page and ad placement may also differ from auction to auction. For example, the viewability of an ad placement may be better on the first auction, as opposed to the auction the buyer actually wins. Finally, there are also concerns around frequency capping, as there is no process to tell whether a user, who has been served an ad from bid caching, has not just been shown the same ad from a different auction.
How does bid caching affect publishers?
Ad exchanges that employ bid caching may offer improved latency to publishers, as a new ad request does not need to be made every time. This is beneficial to publishers as it can reduce page load time. Bid caching also holds potential for increased publisher yield as buyers are paying higher CPMs.
Index Exchange’s use of bid caching last year was limited to publishers utilising their proprietary header bidding wrapper – publishers integrating Index Exchange demand through another wrapper were not using cached bids. Whilst Index Exchange are an important partner for OKO providing an extensive pool of demand, we instead access it via a different client-side wrapper and Google’s server-to-server solution, Exchange Bidding. This means that OKO managed header bidding was not directly affected.
