FLEDGE: Bid timing and accompanying logic

[AramZS]

A big part of optimizing revenue for publishers involves establishing baseline requirements around the execution of bids from a timing perspective. The current state of FLEDGE does not seem to indicate controls that would allow sellers to set timeouts on execution or to manage timeouts against specific bidders. This is a big issue because if a bidder takes a long time to execute, overall impressions may go down as a result of less ad bid processes resolving per pageview. Is there a way to control timeouts within the bidding process or is this a function that only the browser decides on?

If it is a function only the browser decides on, how does it make that decision and what limits might it set?

[michaelkleber]

You're quite right that we will need to worry about per-bidder ad global resource usage. The initial FLEDGE design doesn't have a mechanism for controlling timeouts, but it seems likely we will need to include something like this later.

It's worth noting that when we get to all ads rendering from pre-downloaded bundles, the render-time latency might be very different from what you're used to today. The UX trade-offs could end up different enough from today that I'd be hesitant to predict the right sorts of limits or controls before we see the first prototype usage of the system.

[AramZS]

I agree, hard to see without demonstration, but we should keep an eye out for the ad render time, large overly heavy ads are a consistent problem.

But I was thinking more about timing out of the bidders once their bids are requested. Often bidding systems will fail to respond in a reasonable period of time, in that case, we'd want the ability to time them out instead of waiting for them to slowly return a bid and delay ad viewability.

[michaelkleber]

Yup, I understand. It's possible that this will be less of an issue once there's no slow network to contend with, but we may indeed need to limit CPU time and eventually give up on slow bidders.

[AramZS]

@michaelkleber more than that, I think most publishers would prefer to be able to set specific timeouts and timeouts specific to bidders based on their own logic and testing. A good example:

• Bidder X delivers 20% higher CPMs but required 100ms more time than the standard timeout.
• Publisher Y tests extending the timeout for all vs extending the timeout for Bidder X vs the number of ads that load
• Publisher Y determines that it can optimize CPMs by keeping timeouts consistent for Bidders A-D (bidders will run out any clock one gives them, but not always return better bids as a result) but extending it for Bidder X for an overall longer bid time.

This is a standard practice where Publishers balance the requirements to show ads as quickly as possible with higher bids. Sometimes more ads at lower bids are more profitable. Sometimes less ads but higher bids is more profitable.

Publishers will often attempt to determine that setting the timing for specific bidders will give better results vs the amount of ads that render.

We would want the ability to allow slow bidders where their bids are higher, or where there are other factors where we may wish to give a partner an additional buffer, which means being able to dictate per-bidder timing to the browser. Does this make it a little clearer? I want to emphasize that the main concern here is we do not want the browser to be the sole decision-maker for making a determination on timing out bidders (or not). It does not appear that there is currently support for publishers making that call?

[michaelkleber]

Thanks for expanding. We should certainly add a way for the seller to at least know how long each bid took, which would enable fine-grained after-the-fact control in the seller's JS. I'll add that to the plan.

Abandoning some bidders (i.e. not waiting for slow responses) seems reasonable as well, but as discussed in our call, we can punt that to a later version.

[TheMaskMaker]

Just commenting here that Aram is absolutely correct. Setting bid timing is currently standard practice and one of the first things a publisher will look to tweak on their ad stack (for better or worse, merely commenting that it is a common use case).

1,000 milliseconds is a common prebid default and we could start with that, but this should be controllable by the publisher, esp. given the possible page appearance impact (reflow issues, dynamic sizing) and granular per-bidder control would also be useful.

[TheMaskMaker]

Another important piece of the puzzle, many publisher's use third parties to maintain or interact with their bidding stack, so if this feature becomes publisher-locked then permission delegation would be required here as well.

[vineetkahlon]

While in the long run publisher controls are certainly worth exploring, for the FLEDGE original trials can we allow SSPs to set a bid computation timeout value that will be uniformly applicable to all bidders. This value can be sent in the contextual query response as part of the Auction Config. This will enable SSPs to both provide a guardrail against compute heavy bidding functions as well as allow them to empirically determine reasonable timeout values based on ads metrics.