WICG/protected-auction-services-discussion

Filtering in buyer's Key/Value service

Opened this issue · 4 comments

yanushP commented

Hi

I found this feature in docs, it's look very helpful for us: Filtering in buyer's Key/Value service.

However, it's not very clear how to do use this filtering.

From B&A code it looks that we need to return null for each key in IG, if we want to filter it.

Is my understanding correct or there are other way to filter IG?

chatterjee-priyanka commented

Hi @yanushP

I found this feature in docs, it's look very helpful for us: Filtering in buyer's Key/Value service.

Thanks. This can indeed optimize latency by filtering some InterestGroups (IG) and further reduce number of irrelevant executions (isolated per IG) during bidding.

One of the ways, an adtech could filter InterestGroups (or other parameters), is by ingesting the device metadata that is forwarded to the Key/Value service. Refer here for more details.

Let us know if you have any questions. Happy to help.

~Priyanka

yanushP commented

Thanks for your answer @chatterjee-priyanka.

One of the ways, an adtech could filter InterestGroups (or other parameters), is by ingesting the device metadata that is forwarded to the Key/Value service. Refer here for more details.

Got it. However I also interested in logic on ByerFrontEnd side. What signal do we need to return from K/V to BuyerFrontEnd to inform BuyerFrontEnd that it need to filter this IG and won't send request to Bidding service.
Is the only way to do it, is to return empty response from Key/Value ?

jasarora-google commented

Hi Yanush,

Yes right now you can just choose to not return any signals for that IG and it will be filtered. Here's the relevant code that performs the filtering: https://github.com/privacysandbox/bidding-auction-servers/blob/main/services/bidding_service/generate_bids_reactor.cc#L76

thegreatfatzby commented

Hey @jasarora-google this is interesting, being able to reduce invocations is a good thing...we technically already have a way to do this with priorityVector and prioritySignals but having a cleaner way to do it could be good...but few questions/notes:

  1. In BA, is there a way for a bidding function to still bid even if it receives no values back for its keys? I ask b/c I don't think this is a safe assumption for a general purpose API. I can see many DSP setups where not getting values back would be likely to result in a no-bid for a given IG, but it's not a guarantee and in particular not a decision the framework should be making. Ad techs will think of many use cases and patterns here, hopefully including novel ones, and the API will evolve; for instance, we can now just about update these IGs in real time, so some things that are currently done through trusted bidding signals may move. Filtering is, in some ways, even more important server side as extra invocations add up more than browser side, so we definitely should support this, but I'd strongly suggest we make a clearer signal to allow flexibility, especially given...
  2. This is different than the documented current behavior in on device. You can see a demo here but the key piece from the documentation is:
    Values missing from the JSON object will be set to null. If the JSON download fails, or there are no trustedBiddingSignalsKeys or trustedBiddingSignalsURL in the interest group, then the trustedBiddingSignals argument to generateBid() will be null.
    This will result in compatibility issues between on device and BA, and in particular bugs that will be very hard to detect. While I understand that there will sticky issues we'll have to make choices on, and require "environment awareness", we should minimize those. (I've been assuming we want to make on-device and BA as compatible as possible...perhaps I'm wrong?)
  3. The on-device version already uses the perInterestGroupData returned to deal with IG specific instructions...can we leverage that? It already lets you specify a priorityVector that can be used in filtering, maybe we pursue something in that direction?
  4. I guess, possibly the most importantly, possibly worthy of it's own issue, how are you guys seeing the issue of compatibility with On Device? Are you guys coordinating with Chrome to ensure compatibility, or am I off base in that assumption?