Priority vector re-prioritization proposal

[MattMenke2]

This PR introduces a way to dynamically set an interest group's priority and filter them by way of a sparse vector multiplication. The multiplication can either be between a vector in the interest group and a vector in the auctionConfig, or a vector fetched from trusted bidding server and a vector in the auctionConfig. This is aimed at addressing the issues raised in #302 and #305.

This proposal avoids using Javascript, trading off flexibility for performance, since setting up a Javascript environment is very heavy weight, and needs its own process - the process that generateBid() is called in could be used for any bidder-controller prioritization scripts, but in some multi-buyer cases, we're hoping filtering could avoid the need to create an extra process entirely.

This CL mentions setPriority() a couple times, which hasn't yet been added to the explainer.

[michaelkleber]

1. Age in msec seems like way more granularity than is warranted here.
2. I think we might need a better way to handle age, actually. The use case we've heard about is owners who want their IG priority to drop off over time. The linear nature of a dot product means that if your priority on the second day is half of what it was on the first day, then your priority on day 3 is 0 and on day 4 is negative. Maybe it would be more useful for us to offer multiple capped values, like browserSignals.ageInHoursMax24 and browserSignals.ageInDaysMax30?

[jonasz]

browserSignals.ageinHoursMax24, ageInDaysMax30 sound very useful. If possible, I'd also add ageInMinutesMax60. Adding browserSignals.logAge, as proposed by Matt in #305 could also be useful.

[MattMenke2]

I agree milliseconds is more granularity than people need, but I'm reluctant to declare only days are useful, or only hours are, or whatnot, though I think sub minute granulatity does seem very unlikely to ever be useful.

It wouldn't be hard to support [Log]AgeIn[Hours|Days|Minutes][Max#], though that might be making things too complicated?

[MattMenke2]

That would also mean it's no longer a simple vector multiplication - we'd have to check for certain patterns, which would make things a bit more complicated on implementers, I suppose.

[jonasz]

That would also mean it's no longer a simple vector multiplication - we'd have to check for certain patterns (...)

Not sure if I got that right, could you explain what patterns do you have in mind?

// In my mind, it seemed it would be sufficient if there's a couple new age-related variables supplied by the browser in browserSignals.

[MattMenke2]

[jonasz]: I was referring to my specific suggestion of adding more flexible options.

Wonder how useful the various resolutions are (minutes, hours, days), but I guess providing those three combined gets you a full clock, up to the expiration time.

So we're thinking: ageInMinutes, ageInMinutesMax60, ageInHoursMax24, ageInDaysMax30?

Sorry for the slow follow up. Been busy implementing the rest of this proposal, and only now getting back to figuring out what to do about age.

[MattMenke2]

I've updated the PR to include the requested fields. Feedback welcome!

[dialtone]

Experience from DSPs is that recency needs a lot more resolution than expected right after a signal has been given. For example of all users that add something to a shopping cart and click on an ad before completing the purchase, 80% of them will have done so within 3-4 days, and of those the majority within the first few hours and day.

So while milliseconds may seem too much, these pipelines are usually tuned to the second/minute.

[MattMenke2]

@michaelkleber, @jonasz: Thoughts? Note that the values here are not really accessible by scripts or auctions . You could theoretically keep on modifying the filter and running auctions to try and get the time an IG was added, but there are easier and less finicky ways to probe IGs by using large numbers of auctions, as long as we expose whether any IG won the auction and if so, how long it took. We could just always provide second/minute resolution, if folks find it useful, and I don't think there would be a significant loss in privacy.

[michaelkleber]

I agree, there's no significant privacy implications here, it's just about providing values that are useful for the dot-product mechanism. If ageInSecondsMax600 or whatever is also useful, then sure go for it, I'd say.

[MattMenke2]

Addessing comments on typos - I'll leave the design issue for when I'm back in the second half of next week.

[jonasz]

I was wondering, perhaps perBuyerPrioritySignals could be a field within perBuyerSignals['https://www.example-dsp.com']? That way, the protocol between the seller and the buyer wouldn't have to be updated to handle the priority signals. We'd also lose the natural support for the default (wildcard) priority signals (but currently, unless I'm missing something, I don't see a good use for them).

[MattMenke2]

I'm a bit concerned about overloading fields (field A is both data sent directly to buyer scripts, and data used to run these filters). Seems like there's a lot of room for unexpected behaviors there. If someone, for instance, is using a field we suddenly decide has another meaning, we'd be breaking consumers.

If we want to include with in perBuyerSignals, I'd be more comfortable structuring perBuyerSignals as:

{
  arbitraryJsonData: <...>
  prioritySignals: {...}
}

And dropping everything that's not in one of those two values, to minimize the chance of confusion. That would, of course, be a breaking change, but so would trying to extract priority signals from perBuyerSignals without the format change.

[jrmooring]

There was some related discussion on this here:
#266 (comment)

The direction discussed was leaving perBuyerSignals alone, letting it contain arbitrary buyer json, but introducing a new perBuyerConfigurations field that would contain the various buyer-specific fields that FLEDGE needs to handle, e.g. prioritySignal, experimentGroupId, perBuyerGroupLimits, and potentially interestGroupBuyers.

[MattMenke2]

That's a very different proposal - at least I assume jonasz's suggestion was so that the signals would be passed to worklets, as opposed to be a suggestion on how to better organize fields.

[jrmooring]

Ah, my read of

That way, the protocol between the seller and the buyer wouldn't have to be updated to handle the priority signals

was

"sellers can avoid redeploying code every time FLEDGE adds a new per-buyer field if the per-buyer fields are consolidated"

I don't see that a perBuyerConfigurations map clashes with making the signals available to worklets -- actually I'd think it desirable to make perBuyerConfigurations available to the worklet so that things like experimentGroupId and prioritySignals don't have to be redundantly passed through perBuyerSignals if they're needed by the worklet.

[jonasz]

That's a very different proposal - at least I assume jonasz's suggestion was so that the signals would be passed to worklets, as opposed to be a suggestion on how to better organize fields.

My proposal was actually purely technical, as @jrmooring summarized.

I agree that if there are other use cases where the buyer needs to pass some configuration to the auction, something like perBuyerConfigurations would be nice.

[MattMenke2]

I suspect we're going to switch to something along the lines of perBuyerConfigurations when we end the Fledge field trial and feel we can more safely break backwards compatibility. We could also switch to passing in the entire configuration to bidder worklets at the same time.

[MattMenke2]

Thanks, Maks!

[stguav]

This way of sending data loses the association between keys and Interest Group (IG) names. For example, we might have IG 1 with key 'key1' and IG2 with keys ['key2', 'key3'].

This may become awkward and limiting for usage on the trusted server in the future. For example, it may often be the case that computing the bidding signals corresponding to some key may overlap with computing the perInterestGroupData for the corresponding IG.

Can we have an API that preserves the relationship between keys and IG names? For example, we could require keys and to be in the same order as IG names, with keys from different IGs separated by semicolons instead of commas.

[MattMenke2]

The does potentially make requests bigger, since we need to duplicate keys from multiple IGs. It would also require significant changes to the trusted server code. Are you thinking in terms of things that might be useful down the line, or that would be useful now, with the single perInterestGroupData field?

I'd hope that if something depends on key, it would be something that could be applied to all IGs with the same key, though that may be wishful thinking.

[stguav]

At least with our usage, preserving the association means that we could make the request significantly smaller. If we cannot rely on the IG name->key association being available, the IG name potentially needs to be passed twice once as part of the key and once in the interestGroups field. There are ways one could imagine using the API where one would have many duplicate keys across IGs, but I am not sure if anyone uses the API in that way. (As far as I can tell those designs typically involve moving more computation onto the client, with corresponding latency and data integrity concerns.)

Another related issue, supposing we wish to filter out the IG with negative priority with this API, we would also prefer to return empty bidding signal responses for the corresponding key(s). This either involves looking up a key to IG mapping on the server, duplicating data in the key, or doing redundant computations on the trusted server.

Whether or not all of this will be possible likely depends on details of the trusted server model, but I think it is desirable to keep the options open by preserving the information.

[MattMenke2]

At least with our usage, preserving the association means that we could make the request significantly smaller. If we cannot rely on the IG name->key association being available, the IG name potentially needs to be passed twice once as part of the key and once in the interestGroups field. There are ways one could imagine using the API where one would have many duplicate keys across IGs, but I am not sure if anyone uses the API in that way. (As far as I can tell those designs typically involve moving more computation onto the client, with corresponding latency and data integrity concerns.)

Another related issue, supposing we wish to filter out the IG with negative priority with this API, we would also prefer to return empty bidding signal responses for the corresponding key(s). This either involves looking up a key to IG mapping on the server, duplicating data in the key, or doing redundant computations on the trusted server.

Whether or not all of this will be possible likely depends on details of the trusted server model, but I think it is desirable to keep the options open by preserving the information.

Seems like for your use case, it would make more sense to make unique keys for each IG, rather than shared keys between IGs. One of the reasons to use keys, instead of just IG name, is so that IGs can share data.

[stguav]

Seems like for your use case, it would make more sense to make unique keys for each IG, rather than shared keys between IGs. One of the reasons to use keys, instead of just IG name, is so that IGs can share data.

Yes, indeed that is how we are using the API. Please see my original concern about losing the association:

This may become awkward and limiting for usage on the trusted server in the future. For example, it may often be the case that computing the bidding signals corresponding to some key may overlap with computing the perInterestGroupData for the corresponding IG.

If we lose the association then this effectively limits the future ability of the trusted bidding server to use the interestGroupNames in computing the key response, or sharing computation between the two different outputs.