michaelkleber
commented
1 year ago You're absolutely right that a way to statically declare filtering rules could help by more efficiently letting some interest groups opt out of a particular auction.
If I understand correctly, though, all the things you're trying to achieve are already possible today, by writing your own filtering logic in generateBid(), right? The only benefit here is letting the browser execute some filtering rules instead of executing them yourself?
If that's right, then this is the kind of feature that we should probably wait and design later, once people actually start using the API and figuring out what types of filtering approaches are actually the most useful in practice. The priorityVector approach was our first attempt to build something that was flexible and offered this kind of functionality, so please do see how well it meets your goals. But let's hold off on designing another one without some real-world experience to draw from.
thegreatfatzby
JensenPaul
Background One way we're thinking of leveraging IGs is to put all of the targeting segments into a single IG (as discussed elsewhere), the creative URLs that are targetable by the segments listed for that user, and to have that list of creatives and maybe some other userBiddingInfo updated periodically by the dailyUpdateURL.
One concern we have is network due to Interest Group blobs going over the wire, both into our DCs, between our Seller Ad Service and the various B&A TEEs, and even to 3PDSPs, and the compute that will accompany it.
Additionally relevant parts of the spec I think I'm understanding correctly:
Filtering Matches Ask The ask, roughly, would be to support filtering based on the OpenRTB spec, which would allow substantial flexibility and extensibility based on current industry practice. It would also be a great nudge towards interoperability, both between current tech and Coming Sandbox Tech, as well as between Ad Techs when Sandbox Tech is out. I say "based on OpenRTB" because it would be fine to disallow certain things, or at least make it clear they won't be available (precise lat/lon for instance).
Sellers would have something like: auctionConfig.auctionSignals.openrtb.request = {...} auctionConfig.auctionSignals.openrtb.versioning = {some something that can be used to indicate compatibility}
And IG owners would specify a priorityVector that includes OpenRTB request elements to filter on. priorityVector.auctionSignals.openrtb.request = {size, mediatype, coarse geo, etc} priorityVector.auctionSignals.openrtb.versioning = {openrtb >= 2.4 etc}
I'd think this would allow for substantial filtering of Interest Groups on the client side, even in the case of B & A based auctions. I can try to get numbers but I believe the "fast path" of our bidder does a ton of filtering quickly using contextual and coarse things like that. Were this implemented in C++ in Chromium on the client I'd think it would be fast and eliminate a lot of targeting.
Ideally this wouldn't need to be flat, it could be the full object as used today, to accommodate this then being used in the auction (obvs if it needs flattening that can be handled, I would think it would be easier for debugging, but not the most important part).
How to do the filtering would probably need get a little trickier than the current "dot product" based formula, as you might want to support something like exact matches on width and height, but maybe "value in (list)" for media type, or >= openrtb2.4 (bad example). However, I'd think that's not too bad, some thing must exist for that somewhere.
IG Modification Changes The second piece of this would be allow the filtering function to not eliminate the IG but modify it strictly for that auction request by removing elements of userBiddingSignals, creatives, etc. The mutation could be limited to removal so you'd always get a subset of the IG, so I don't think there'd be any information leak vectors, at least direct ones (I don't know about indirect, will have to think more).
Conclusion Again I'm happy to try to get numbers but I think giving a bit more "ad tech level" filtering as a 1st'ish Class Filtering Citizen would reduce IG usage in an auction a lot, be fast, and then combined with the IG Modification (and others discussed around multiple bids from an IG) allow more flexibility in the use of the PaAPI Auctions.