Bid Caching has been the talk of the adtech town. But, what it means for you?
Every successful technique in ad tech has to go through an ‘obnoxious’ and ‘not-so-good’ phase before bouncing back as a standard.
Take ad refresh for an example. In the early days of ad refresh, advertisers and some ad exchanges (Google AdX, AppNexus, etc.) hated the technique by pointing out that publishers are rotating their ads automatically without considering viewability. And, it was true.
But, when premium and elite publishers started to adapt the technique and refreshed the ads only when ads are in-view for over a minute or so, the industry agreed to it. Now, all major exchanges and networks allow you to refresh ads. In fact, Google AdX offers its own ad refreshing triggers for publishers.
A 15-second engaged ad refresh ad strategy can improve viewable inventory by 69%.
So, are we saying bid caching and bid shading will be standardized in the future? We’ll get there in some time. Let’s just start with the basics.
Table of Content:
- What is Bid Caching?
- What is Bid Pooling?
- What’s in it for the Sell-Side?
- Wait, what about the buyers?
- Is Bid Caching Right or Wrong?
- Update: Prebid.js caches bids
- What can you do?
What is Bid Caching?
Bid caching is the process of using the bids received in one auction to fill up the impressions of subsequent auctions. So, bids from the advertisers are being held up (even if they didn’t win the impressions) so that the same can be used for the succeeding ad auctions.
“You’re paying for something else. It’s [Bid Caching] like going to supermarket and getting beans, and at checkout, they swap it out for something else.”
– Dan Wilson, CEO of London Media Exchange.
Typically, you use an ad exchange to fill up your ad inventory with the ads. So, when you send an ad request to the exchange, it will collect all the bids for the impression you just submitted. Now, as per second-price auction logic, the highest bidder will pay you 1 cent more than the second-highest bid and you’ll render the creative for the winning bid.
In usual cases, to serve ads for the next impression, ad exchange will follow the same process to receive bids from advertisers. But with bid caching, the exchange will use the second-highest bid (lost bid in the previous auction) to fill up the impression.
Sounds simple? But, it isn’t for buyers.
What is Bid Pooling?
Bid Pooling and bid caching are essentially the same.
What’s in it for the Sell-Side?
Let’s admit a fact. Publishers are willing to procure the best out of their ad inventories. In fact, premium and paywall publishers would like to deliver as many ads as possible. For instance, Wired.com, a paywall publishers runs anywhere from 7 to 9 ad units (including sponsored content) on a typical article page* and refreshes them as well.
However, they’re great at providing seamless user experience. All the ads are non-intrusive and don’t block the content in any way. But, there’s a problem, not just Wired, every publisher has to handle.
You were able to deliver the user experience, but how about latency? Every ad calls will further delay or at least interrupts the page load.
If the ad exchange employs bid caching, they don’t need to make requests every time. Because they can use the bids from the previous auctions. A win-win for both exchanges and publishers.
Wait, what about the buyers?
That’s where the real problem lies. Buyers were bidding for a specific impression [first impression], not for the subsequent impressions. Two important reasons put buyers against the caching practice.
- Targeting and Brand Safety – The context of a webpage and targeting criteria for a user will not be the same in subsequent auctions. For instance, a buyer would have sent the bids for the impression on the home page, but the bid may be used to serve the impression on any article page.
- Overvaluing impressions – The first impression possesses a higher value than the others. So, buyers might be bidding premium prices for the first impressions and using the same for the others will directly influence the ROI.
Is Bid Caching Right or Wrong?
Topix, a slideshow publisher implemented bid caching to improve the page loads. The average page views of Topix is a little over 70. As it is a slideshow, a user has to forward the slides to view the content.
Before caching bids, the publisher used to make 70 ad calls to render ads for a user. But now, with bid caching, it has to make fewer calls.
You might be wondering why Index Exchange was criticized for the practice, while there is a publisher doing the same. Because it is two-sided. Topix disclosed that they’re going to cache bids for 20 seconds to bidders and besides, brand safety isn’t at risk, as previous bids are used in the different slides (same slideshow). No major change in the context and URL remains the same in this case.
Update: Prebid.js caches bids
Recently, prebid said that prebid.js 1.x will cache and re-consider previous bids under certain circumstances. Similar to Topix, prebid does it in the right way.
The bids are re-considered only
- When the Ad unit remains the same
- When the user is on the same page view
- For the same user, and
- Up to a certain Time-to-Live (TTL) or until the bid wins and is displayed.
If the user reloads the page, bids will be lost. And, TTL is set by the bid adapters in milliseconds. A few instances where you can cache bids include auto-refresh, galleries, and infinite scroll.
The bid caching is automatic for display and native ad units. You can set the caching for video ads manually. Refer Prebid for more information.
What can you do?
Being aware solves half the problem. If buyers have known the practice, there won’t be an industry debate going around. And, we agree, ad tech vendors need to be transparent about their agreements and inner-workings. That’s why we always advise publishers to ask questions before partnering with any third-party vendor.
We believe the story will continue to persist in adtech for a while and you can even expect some interesting updates both from the consortiums and the sell-side. We’ll keep you posted as always!