Closed dbemiller closed 6 years ago
Got an interesting suggestion today from someone trying to help simplify the "what to cache?" options.
It was: always cache the entire OpenRTB bid. Expose GET
endpoints on the cache
so that people can query a subset of the info.
So for example:
GET prebid-cache-url.com/cache?uuid=abc&keys=adm
: fetch just the ad markup
GET prebid-cache-url.com/cache?uuid=abc
: fetch the entire JSON bid
This would basically reduce the complexity of prebid-server
, at the expense of prebid-cache
.
Not saying it's a great idea... but it doesn't seem like a bad one, and it's creative enough I thought I'd mention it.
Interesting concept but doesn't that that assume JSON is the structure? Also we are storing a lot of stuff we probably won't ever need.
yeah... we talked about storing stuff we don't need, but the rest of the Bid is tiny compared to the creative markup.
I am concerned about the JSON structure requirement, though. In order to return a Content-Type: application/xml
page, either PBC would need to know about the adm
field specifically, or the GET
API would have to let clients tell PBC which format they expected for the response.
Another concern came to mind after thinking about it some more:
adm
isn't a required field. The bid's nurl
can also return VAST. So that API doesn't make a great workflow for a client who just wants the creative content--no questions asked.adm
is XML. If a bid is cached for an AdUnit which could be banner or video, then the caller might not even know for sure whether the adm
field is storing XML or html/js. This commits PBC to knowing an awful lot about OpenRTB and the data formats.Overall... I'm not too crazy with this idea. It seems to make things a tiny bit simpler for PBS, but much more complex for PBC.
I think I've got something reasonable which hits all the use-cases. Originally, we can add an option like this inside bidrequest.ext.prebid
:
{
"cache": {
"bids": {
"winners": true,
"deals": true
}
}
}
bids
is required, but winners
and deals
are optional. By default, we will only cache "winners".
Depending on which use-cases makes sense in the future, we can expand the API to something like this without introducing any breaking changes:
{
"cache": {
"vastxml": {
"winners": true,
"deals": true,
"all": true,
"cpmfloor": 0.01
},
"bids": {
"winners": true,
"deals": true,
"all": true,
"cpmfloor": 0.01
}
}
}
Whenever we introduce vastxml
, bids
will become optional and only one of bids
or vastxml
will be required. vastxml
would describes which bids will have just their adm
stored as XML strings.
Per the discussion in #199, cpmfloor
is not needed. Bids which round to $0.00 CPM should not be cached, even if they're "winners" or "deals".
per some more discussion with @mjacobsonny, I learned some things. Today, Prebid publishers expect:
hb_uuid
-- applies to the top overall bid for each Imp
hb_uuid_{bidder}
-- applies to the top bid from {bidder} for each Imp
There is a problem with this today. There is no good support for a Bidder who makes two bids on the same Imp for separate Deals. It was proposed to add a new key to support this:
hb_uuid_{dealId}
-- applies to every bid with a DealID
However, he also described a business use-case for hb_uuid_{bidder}
even if there aren't Deal IDs.
So... it's my opinion that improving Deal support should be a future improvement. Since we're not deprecating hb_uuid
or hb_uuid_bidder
, and the Deal support proposal wouldn't cause breaking changes to the API, there's absolutely no reason to worry about them now.
All that in mind... this is the behavior I implemented:
{
"cache": {
"bids": {
// This is an object, but no options exist yet. Some may be added in the future
}
}
}
This will apply hb_uuid
and hb_uuid_{bidder}
to the bids as described above.
One last-minute change to this before merge... we replaced hb_uuid
with hb_cache_id
.
Besides just being a better name, this will save existing Prebid Mobile publishers from having to update their DFP creatives when they switch to OpenRTB.
The
/openrtb2/auction
endpoint needs to support sending bids to the cache.Right now, I don't think we have a good enough sense of the cache's use-cases to build a quality feature here. This is the fundamental tradeoff:
If the cache behavior needs to be "chosen", because different behaviors have equal merit, then we have two options:
request.ext
However... I also want to note the following, which we should take very seriously:
To grow this project smoothly, our goal should be to identify the fewest "choices" necessary to encourage adoption on both sides.
These are things to consider:
The Prebid.JS philosophy is: "the publisher ultimately decides which bid wins." If PBS caches the bids, Prebid auctions will have overall better performance. However, it is possible for JS expose an API which caches only the bid which the publisher chooses.
The prebid-mobile philosophy is: "App code updates are expensive. It's better if the Server does everything, including picking the winning bid." As far as I can tell, there's no room for negotiation here.
@DucChau mentioned that Rubicon wanted an option to cache just the vast XML. Currently PBS caches a JSON blob with other info too.
There's some ongoing debate about the cache's usefulness for certain types of bids in #199.
These are some deficiencies in the
/auction
endpoint's cache behavior. Ideally, we can do it better inopenrtb2/auction
./auction
doesn't let you cache just the vast XML. It requires the JSON blob. If this is a valid use-case, then the/openrtb2/auction
API should to support this too.@bretg and @mjacobsonny might want to discuss this. At the moment, I don't think it's fleshed out well enough for much useful engineering work to be done.