Add support for publisher controlled global auction timeout

[giancarlopetrini]

For many publishers GPT will be acting as the Top Level Seller, and for others, another SSP is likely to fill that role. A publisher should have direct control over how long an auction is allowed to run, particularly in the sequential seller, header-bidding workflow.

This does intersect closely with a recent issue discussing the lack of global timeout implementation, currently.

Consider the following sequence:

• header bid arrives
• header bid response used as floor for GAM/AdX auction/Ad Server
• Ad Server responds, runAdAuction called by GPT/Top Level Seller
• User leaves page, continues to scroll, etc. Header bid or GAM/AdX/Ad Server does not render, although it was available, as runAdAuction has not yet resolved, and cannot be prescriptively timeboxed.
• Publisher loses an impression that otherwise would have rendered.

Alternatively:

• publisher calls something akin to navigator.setAdAuctionGlobalTimeout(1000)
• sequential seller/auction flow proceeds as above
• publisher's timeout is enforced, runAdAuction resolves, potentially with null even if there were bids (implementation details would dictate)
• header bid or Ad Server bid renders within expected time frame

A heirarchical auction config could be relevant to other auction config values as well, but scoped specifically to timeouts, it'd be helpful if publishers could run something like navigator.setAdAuctionGlobalTimeout(1000). Alternatitely, navigator.setPublisherAuctionConfig(config) could be a robust interface to allow for publisher more control.

Challenges

Apart from the lack of an existing global timeout, enforcing who is able to call navigator.setAdAuctionGlobalTimeout() or navigator.setPublisherAuctionConfig() could be difficult. Preventing a GPT/TLS from invoking that on a publisher's page could prove difficult. Perhaps these functions could only be called once and the publisher would be expected/responsible for calling before loading gpt/other TLS code.

[michaelkleber]

It seems like this publisher goal is better met by the party who runs the top-level auction giving the publisher some kind of configuration option that affects timeout behavior, right?

Your proposal of a JS API that can be called by the publisher but not by top-level seller seems very hard to support, but the top-level seller seems like the party who should be most bound to do things that the page owner is asking them to do.

[MattMenke2]

Constraining who can call a method in Javascript is not a thing the web platform supports, nor is it something I think we can reasonably add. If you're running someone's script in the context of your page, you need to have a lot of trust in them. If the publisher (who has first crack at running Javascript) wants to hide Javascript methods from other code that runs in the context of their page, they can use Javascript to modify navigator themselves to remove the functions, I suppose, but it's not really something that's part of the web's security model - any 3P script already potentially has full control over your page.

Adding global timeouts is something we could reasonably do, though we'd probably want to add them as part of the auctionConfig, rather than an independent method. That provides more flexibility (may want a shorter timeout for ads higher up in the page or something). One problem with a global timeout in component auctions is that we load the top-level seller last, to avoid deadlock, since we limit the number of seller processes we have in memory at once. As a result, it's possible that we never even loaded the top-level seller's script, and thus there will be no partial auction results we can return. I don't think that means we shouldn't implement it, just pointing out that it could become an issue.

[rdgordon-index]

One problem with a global timeout in component auctions is that we load the top-level seller last

But the top-level auctionConfig, which includes the componentAuctions, is necessarily available if it were to include this kind of global timeout, correct?

[MattMenke2]

But the top-level auctionConfig, which includes the componentAuctions, is necessarily available if it were to include this kind of global timeout, correct?

Yes. The issue is just that we may not even have loaded the top-level seller by the time any time expires, which increases the chance of there being no winner.

[giancarlopetrini]

But the top-level auctionConfig, which includes the componentAuctions, is necessarily available if it were to include this kind of global timeout, correct?

Yes. The issue is just that we may not even have loaded the top-level seller by the time any time expires, which increases the chance of there being no winner.

For publishers, this a decision and trade off we'd be comfortable with making. It'd be expected that a global timeout would likely not return a winning bid, even if there were one available, if the auction were not able to fully resolve.

Re: call access, if there were a method that could only be called once, or a property that could be set once (globalTimeout) within the API, it'd just be the publisher's responsibility to call that before any other SSP/Ad Tech provider.