VideoCacheKey override

[bretg]

Type of issue

Enhancement

Description

8 of 271 bidders set bidResponse.videoCacheKey, which means they cause notable headaches in setting up line items because they require separate GAM video creatives. It's time to talk about this.

• bluebillywigBidAdapter.js - @K-JBoon
• dailyhuntBidAdapter.js - @montu1996
• nobidBidAdapter.js - @redaguermas
• onetagBidAdapter.js - @OneTagDevOps
• rubiconBidAdapter.js - me
• spotxBidAdapter.js - @agdillon , @npeceniak
• synacormediaBidAdapter.js - @slaufer, @amuraco
• theAdxBidAdapter.js - @mustafakemal16

Basically, bid adapters that specify videoCacheKey are saying "you must use my VAST cache location, you may not use your own."

Here's the relevant pseudo-code in auction.js:

For each bidResponse
 If instream and setconfig({cache.url}) is specified     // see note below
   If videoCacheKey is specified
      If there’s no vastURL, error, don’t add bid to the auction yet
      else bid is totally ready, so add it to the auction.
   If videoCacheKey is **not** specified call prebid-cache
      The response from the cache triggers adding the bid and setting videoCacheKey

Note: the assumption from PR #3024 is that outstream renderers can support either VAST XML or IRL.

I can speak from the Rubicon Project perspective on this. We provide VAST caching on our servers for our customers because we believed it was The Right Thing To Do:

1. It's our business so it's our responsibility to store these big globs of VAST on servers we pay for. It didn't seem fair to make AppNexus be the global cache for the internet. These things aren't free and we should shoulder our share.
2. Hosting our VAST in our own cache gives us the ability to own the troubleshooting. Publishers pay us and we don't want to shrug our shoulders and point a finger at some other cache provider.
3. Client-side caching is inefficient. Schlepping VAST back and forth across the poor user's network connection is ugly if not kinda rude.

However, after experiencing the convolutions required to manage different video cache locations in GAM, Magnite (and therefore Rubicon Project) would be happy to allow publishers to use VAST wrappers around our VAST URLs to simplify line item setup.

Even if the other 7 bidders feel the same way, we can't just remove videoCacheKey logic because pubs may have special line items and creatives set up. Removing the logic from either auction.js or the bid adapter because that would cause a new hb_uuid to be generated that might not match up properly with the VAST URL in GAM.

Instead, the proposal here is that we implement a transition period:

• publishers can ignore the videoCacheKey once they've confirmed their line item setup
• in a major release (e.g. 5.0 or 6.0) we remove the videoCacheKey logic from either auction.js or the bid adapter.

Proposed config:

pbjs.setConfig({
        cache: {
            url: 'https://prebid.adnxs.com/pbc/v1/cache',
            ignoreBidderCacheKey: true
        }
});

Here's how the new option affects the algorithm in auction.js:

For each bidResponse
 If instream and setconfig({cache.url}) is specified     // see note below
   If videoCacheKey is specified and **ignoreBidderCacheKey** is undefined or false
      If there’s no vastURL, error, don’t add bid to the auction yet
      else bid is totally ready, so add it to the auction.
   If videoCacheKey is not specified or if **ignoreBidderCacheKey** is true, then call prebid-cache
      The response from the cache triggers adding the bid and setting (or overriding) the videoCacheKey

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bretg]

Released with 4.28