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. Enhanced Logging for External Writes - If API header mode is on, and write comes without the API header, then log 1% of each referring URL and then a configurable percent, then log the body of the cache entry.
2. Add a timestamp to the body of the cache - this would allow the creation of a useful metrics: 1. On a read-hit, how much time was left in the cached entries TTL. May enable tuning of TTL scenarios.
3. Add a bid 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. Example 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-fc61a00a-786c-4e8f-b2be-8f9d4a96d9d5. We may want logic to constrain whether both bid id and auction id are present based on the lengths.
   2. PBS can check of the bidId and add randomness as needed.
4. 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.
5. 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.
6. 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.
7. Manage cached object sizes - there are some truly large VAST files that get placed into PBC. Host companies need to be able to monitor the distribution of sizes and place caps per-account on cache-object sizes.
8. 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. This is high priority.
9. Validate cache writes - host companies that must continue to support Prebid.js browser writes to cache might want a way to validate somehow instead of just blocking external writes.
   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 or app bundle XYZ.
   2. If this scenario is supported, PBC would probably need to write metrics about external write sizes, and perhaps be able to enforce sizes.
10. 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)