Add Seller Information on the Key/Value Server request

[TheTamFamily]

The buyer may have a deal in place to buy ad slots from a specific seller, the seller could be a Publisher or the component seller. Currently, the Key/Value request from the browser only contains the hostname of the Publisher website and we would like for the ability to send or not to send a response. At the moment we are having to send a response back to the browser and determine whether to bid or not to bid in the generateBid function. We would prefer to avoid the need to add this logic in the generateBid function when it can be easily dealt with at our KV server.

This Feature Request proposes to add seller's information to the request sent to a Key/Value server, the same way the publisher's hostname is being passed today:

• Current URL: https://kv-service.example/getvalues?hostname=publisher.example&keys=key1,key2
• Proposed URL: https://kv-service.example/getvalues?hostname=publisher.example&keys=key1,key2&componentSeller=ad.tech

Rationale: By appending the componentSeller=ad.tech parameter to the URL, we can ensure not to bid on SSPs for a publisher when we have a direct alternative available.

[michaelkleber]

Hmm, interesting idea, let's talk about this. We are certainly all in favor of letting you filter out IGs without running their generateBid functions whenever we can find ways to do so!

If some publisher has five component sellers, then we certainly want to make only one KV server request per buyer rather than five. So it seems like componentSeller would need to include a list of the sellers, not just a single one.

What kind of return value are you imagining in your response? Especially in a situation where an IG wants to bid in some component auctions and not others.

I wonder if there is a way for us to accomplish your goal using the Filtering and Prioritizing Interest Groups feature with the perInterestGroupData priorityVector mechanism. The "sparse dot product" doesn't currently have any information about the component seller, but that seems like an easy thing for us to add.

To be concrete, suppose the browser-provided prioritySignals object included a value called browserSignals.componentSeller=ad.tech with value 1 if ad.tech is the component seller. Then your KV server could return a priorityVector that's something like

priorityVector: {'browserSignals.one':1,
                 'browserSignals.componentSeller=foo.com':-2,
                 'browserSignals.componentSeller=bar.com':-2}

if you wanted to avoid buying in auctions run by foo.com or bar.com and buy in all the others, or conversely

priorityVector: {'browserSignals.one':-1,
                 'browserSignals.componentSeller=foo.com':2,
                 'browserSignals.componentSeller=bar.com':2}

if you wanted to only buy in foo.com and bar.com auctions and ignore all the others.

It seems like this could work either with or without the KV request being expanded to include the list of component sellers.

[TheTamFamily]

@michaelkleber : Your suggestion above would also address the Use Cases I had in mind. Just one clarification, if I want to buy from any componentSeller does this mean that I can simply omit priorityVector or would I still need to specify some sort of wildcard.

[michaelkleber]

Interest groups bid on all auctions by default, and don't bid if the priorityVector dot product is less than zero. So no wildcard is needed; if you ignore the priorityVector thing entirely, then your IG will bid in all component auctions.

Hey @MattMenke2, you've been inside the implementation of the sparse dot product mechanism, can you sanity-check my idea here? The question is whether we can let the prioritySignals values include a browser-generated key something like 'browserSignals.componentSeller=foo.com' : 1 when the IG is evaluating its priority of bidding in the component auction with seller foo.com.

[MattMenke2]

We generally represent sellers as origins, not domains (so it would actually be "componentSeller=https://foo.com"), but it sounds like a reasonable proposal to me. We could do the same for the top-level seller, if that would be useful (both if it's in a single-seller auction, or a multi-seller one).

We could additionally consider sending a list of component sellers, so the KV server only has to send us the most relevant prioritySignals, though we may only want to only do that for v2 of the KV API.