Updated list of what can be a promise

[patmmccann]

Several things that cannot be a promise seem to not have good reason to be excluded, eg

sellerExperimentGroupId
perBuyerExperimentGroupIds
perBuyerCurrencies

As async auctions become more popular, it would be useful to have as much as possible as a promise. Currently the fledge explainer lists these: "The values of some signals (those configured by fields auctionSignals, sellerSignals, perBuyerSignals, perBuyerTimeouts, deprecatedRenderURLReplacements, and directFromSellerSignals) can optionally be provided not as concrete values, but as Promises."

Is that a full list?

[patmmccann]

cc @mkendall @dgirardi

[morlovich]

perBuyerCurrencies can actually be a promise... but I just discovered a bug in handling of it this week that we may not correctly depend on it resolving for checking the currency of a component auction against top-level's perBuyerCurrencies. A good way of checking this is the IDL: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/ad_auction/auction_ad_config.idl;drc=8a1af0ea61be0130a549952082c59f717f1ab1a0;l=37

…

On Thu, Oct 10, 2024 at 10:55 AM Patrick McCann ***@***.***> wrote: Several things that cannot be a promise seem to not have good reason to be excluded, eg sellerExperimentGroupId perBuyerExperimentGroupIds perBuyerCurrencies As async auctions become more popular, it would be useful to have as much as possible as a promise. Currently the fledge explainer lists these: "The values of some signals (those configured by fields auctionSignals, sellerSignals, perBuyerSignals, perBuyerTimeouts, deprecatedRenderURLReplacements, and directFromSellerSignals) can optionally be provided not as concrete values, but as Promises <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise> ." Is that a full list? — Reply to this email directly, view it on GitHub <#1298>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4XKRGG2CH3IURSEO3BXG3Z22IOHAVCNFSM6AAAAABPW7RLLSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU3TSMJRGAZTCNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[patmmccann]

cc prebid/Prebid.js#12205

[patmmccann]

@morlovich that list is extremely helpful, it seems a Pr on the explainer with the full list is in order? Referencing that list isn't the most user friendly thing :) Works for me, but seems awkward if I point to it in documentation

[JacobGo]

+1, I'd also add perBuyerGroupLimits and perBuyerMultiBidLimits to the feature request list. There's certain fields that can't be deferred though, e.g.perBuyerExperimentGroupIds must be passed on the DSP lookup.

I do hope that as part of maturing Protected Audience / Ad Selection API, browsers will code-generate TypeScript interfaces from the IDLs like other web APIs.

[dmdabbs]

Also maybe perBuyerCumulativeTimeouts, if I correctly read latest published spec:

Promise<record<USVString, any>> perBuyerSignals;
Promise<record<USVString, unsigned long long>> perBuyerTimeouts;
Promise<record<USVString, unsigned long long>> perBuyerCumulativeTimeouts;

[MattMenke2]

perBuyerGroupLimits as a promise would mean we can't start loading buyer scripts, so it seems not too useful as a promise, since we effectively can't do anything, at least for any component auction without it set yet, though if we care about values like that, it would seems simpler to allow entire componentAuctions to be promises.

[rdgordon-index]

perBuyerGroupLimits as a promise would mean we can't start loading buyer scripts

Wouldn't there still be value here in limiting how many IGs to execute per component seller, even if they have been loaded?

It would seems simpler to allow entire componentAuctions to be promises.

That's an interesting option, since it avoids the all-or-nothing promise at the top-level seller level.

[MattMenke2]

Wouldn't there still be value here in limiting how many IGs to execute per component seller, even if they have been loaded?

What if an IG we had been asked to exclude had already won the auction?

[rdgordon-index]

What if an IG we had been asked to exclude had already won the auction?

Not sure I follow -- the auction wouldn't start until the rest of the promises had resolved (like auctionSignals, sellerSignals, and perBuyerGroupLimits), which are needed to make any sense of the bids...

[MattMenke2]

Not sure I follow -- the auction wouldn't start until the rest of the promises had resolved (like auctionSignals, sellerSignals, and perBuyerGroupLimits), which are needed to make any sense of the bids...

If we can't start the auction, there's not much point in using promises - which was why I was saying it was not useful.

[rdgordon-index]

Well, you can start the auction -- in the sense that script runners can be fired up, KV calls can be initiated etc. -- but you're talking about an auction winner above....

[MattMenke2]

So you're proposing a new stage to auctions, where we have bids (which may or may not be scored), but haven't applied the group limit filter on them, and then we can apply the group limit to the bids. It's doable, but it very much can't just be lumped into how we handle other promises, because of that new phase. I'm skeptical it's worth the complexity for just letting that one field be a promise, though not my call.

[rdgordon-index]

Also maybe perBuyerCumulativeTimeouts, if I correctly read latest published spec:

It's not entirely clear how some of these were chosen to be promises or not... for example, perBuyer* -- we did talk about limits above, but not about the others.

On the seller side, what about currency?

And perhaps there's a nuance from https://github.com/WICG/turtledove/blob/main/PA_implementation_overview.md#phase-2-bidding-and-scoring-phase that I've missed, but on the seller side, since the KV calls are not made until after generate bid, what's the requirement for the TSS being known in advance?

[patmmccann]

Just noting as well that the TSS can't be a promise concern of @rdgordon-index is particularly difficult to many implementors

I certainly understand things that delay the downloads of decisionLogicUrls are not good candidates

[rdgordon-index]

https://github.com/WICG/turtledove/blob/main/PA_implementation_overview.md#component-auctions mentions that:

In the case of top-level auction with multiple nested component auctions, the auctions are largely run independently, except that the interest group loading phases for all auctions must complete before any auction enters the generate bid phase

Can you clarify why this is the case? What would prevent starting the auction for seller A if its interestGroupOwners are loaded, even if seller B's IG owners aren't?

[MattMenke2]

https://github.com/WICG/turtledove/blob/main/PA_implementation_overview.md#component-auctions mentions that:

In the case of top-level auction with multiple nested component auctions, the auctions are largely run independently, except that the interest group loading phases for all auctions must complete before any auction enters the generate bid phase

Can you clarify why this is the case? What would prevent starting the auction for seller A if its interestGroupOwners are loaded, even if seller B's IG owners aren't?

Note that's the "implementation overview" - how it is implemented, as opposed to normative "this is how it must be implemented". That code predates the introduction of promises, and refactoring it would be a pretty significant undertaking, since tracking all the types of things we need to wait for to gauge auction progress is non-trivial. It's also tightly coupled to histogram collection.

[rdgordon-index]

As per the discussion on today's WICG call, I'll open a new issue regarding the possibility of a trustedScoringSignalsURL promise.

EDIT: #1314

[rdgordon-index]

From #1314 (comment) (emphasis added):

Our current architecture keys worklets on all URLs and everything that goes into the trusted signals query param that can't be merged (e.g., slot size, experiment ID)

unsigned short sellerExperimentGroupId;
record<USVString, unsigned short> perBuyerExperimentGroupIds;

Re: experiment ID -- as mentioned in other issues, if this cannot be a promise, this would mean that client-side logic would need some ability to manage, and persist, experiments -- yet another significant challenge to being able to adopt the parallel auction workflow. The bid adapters have very little business intelligence in them, and managing server-side seems like an obvious need.

Looking more closely, I now see that buyer experiment group ID also isn't a promise -- I can't speak for buyers, but I'd assume they are expecting contextual responses to power experiments as well -- since they don't have any code in page with which to manage such configuration (and neither would sellers on their behalf).