Expanding PBC capabilities

[bretg]

Overview

Prebid Cache was built to be a thin layer on top of a NoSQL backend. For 8 years we have stayed true to that philosophy, keeping application logic in Prebid Server itself. But there a number of issues that have started showing as Prebid Cache becomes ever more important in the render and monetization of video and mobile ads.

1. Scaling and managing a multi-tenant environment is made more difficult by the paucity of detailed metrics available about the contents and usage of the cache. This is made particularly difficult by the circuitous path that a cache ID takes from time of write to time of read. It passes through Prebid.js, Prebid SDK, the ad server, the PUC, and or a video player.
2. The multi-source nature of writes with no knowledge or control on who's writing makes it difficult to provide a consistently stable environment.
3. Application expiration controls are not flexible.
   1. We can't define which clients are allowed to save which use cases for how long.
   2. There's no way for a client to say "ok, I'm done reading now, you can expire this cache entry now."

Potential Improvements

1. Add a timestamp to the cache ID - this would allow the creation of some metrics that could be useful:
   1. On a read-hit, how much time was left in the cached entries TTL. May enable tuning of TTL scenarios.
   2. On a read-miss, how long ago was the cache entry written? If it should still be there, perhaps evictions are happening. If it's very old, perhaps there's a client issue.
2. Add a bid ID and/or auction ID to the cache ID - this would enable analytics that supports user experience and finance reporting. e.g. on a read-miss, log to an analytics system so the read can be linked to the original auction event.
   1. Why both bid ID and auction ID? Based on Magnite's experience with trying to tie PBS win events back to the original auction event, just having a bid ID was not always sufficient. Theoretically this may be resolved with PBS-specific bid IDs, so we should allow for host companies to have the option of using 1-or-both of these IDs for linking analytics.
   2. Yes, the cache ID may basically need to contain everything present in an event. Lovely. Here's an example cache ID with everything discussed here: 12345-apac-1740174115-bid-fc61a00a-786c-4e8f-b2be-8f9d4a96d9d5-aid-67951636-083e-4182-aad8-9f004c7f8fc7. We may want logic to constrain whether both bid id and auction id are present based on the lengths.
3. Configuring the length of cache ID - all told, this cache ID could be much longer than a UUID, because bid ID itself could be a UUID. This may become a problem for some elements of the path between write and read.
4. Cache Read Analytics - PBC becomes capable of emitting an analytics "read" event using the contents of the cache ID.
   1. One way this could work is creating a new PBS /event?t=read and letting PBS analytics adapters handle it.
5. Account-level + channel ttl limits - once we learn about the cache read behaviors for various applications (e.g. account 123, channel app, app bundle ABC), we may want to tune the effective TTL. This may be a candidate for the rules engine.
6. Opt-in cache expire on read - we've been hesitant to support an automatic "delete-on-retrieval" behavior because we don't know about use cases like validation that might consider this a breaking change. But an explicit signal seems reasonable. e.g. /cache?uuid=11111&expireOnRead=true
7. Validate cache writes - host companies that must continue to support Prebid.js browser writes to cache might want a way to validate somehow.
   1. One way would be for the account and the referring URL go together. e.g. writes from account 123 must come from example.com.
8. Proxy to the right datacenter - to avoid requiring global cross-datacenter reads for a small percentage of mis-routed traffic, we could enhance PBC to have a configured list of datacenters and if it gets a read miss, it could check the datacenter field of the cache ID against that list, proxying as needed.
   1. We did something like this with the "ch" option, but it requires publisher line item updates, which can be difficult.

Next Steps

These challenges and proposed improvements will be discussed in upcoming meetings. The items we find worthwhile will have separate issues created and fleshed out.

Outside of Prebid Cache's control, we should continue investing in ways to decrease Prebid reliance on Prebid Cache.

• PBJS reliance on PBC is covered in Local cache module: use createObjectUrl for rendering cache Prebid.js#11393, but doesn't seem to be going anywhere.
• Prebid SDK is considering ways to avoid requiring banners to be stored in the webview -- Cache bids locally for Bidding Only API prebid-mobile-ios#1103
• PBS is looking to allow host companies to have more control over which bids get placed in cache -- Record a default core bid ranking prebid-server#4150 (comment)