Improvements to top-level auctionSignal propogation in multi-ssp

[patmmccann]

It is written in the explainer (not currently in the seller guide) that top-level auctionSignals, when component sellers exist, are not shared with any buyer. We've been told if the top-level auction runner wants to share a signal with each component buyer, they should re-write the component sellers' auctionSignals objects to include it. This feels awkward.

Why even have top-level level auctionSignals exist in the component workflow? There doesn't seem to be an obvious consumer of it.

Why not just have top-level auction signals do a json merge with component signal auctionSignals? Or perhaps, in component auctions, toplevelAuctionSignals and auctionSignals could both be exposed to buyers as different objects? Or perhaps, a third signals object (beyond auctionSignals and sellerSignals) could be added to the top level, that is explicitly for component buyers, eg componentAuctionSignals?

It seems any of these solutions is more elegant than the toplevel seller being responsible for awkward re-writes of contributed component seller config.

Use cases: (1) the ad server is running the top-level auction and has information to share with each component buyer, for example, the price of the contextual winner, a publisher-provided signal (aka seller-defined audience), visibility indicator, or a calculated floor.

(2) the publisher is running the top-level auction and wants to share their banned advertisers, categories, floors, or contextual signals with each buyer but is not running any component auction.

(3) the top level seller can take responsibility for propagating / validating the structure or contents of certain page level descriptions, eg referer, and forming them into a, for example, openrtb or openrtb like request object. This third use case would make it so component sellers aren't competing on things like page description standards adherence and should be good for all parties in the transaction.

[rdgordon-index]

It is written in the explainer (not currently in the seller guide) top-level auctionSignals when component sellers exist are not shared with any buyer

aside: not necessarily obvious, but the top-level seller can observe the complete auctionConfig, including all component seller auctionConfigs

[patmmccann]

Added use case 3 after a conversation with sandbox leadership

[michaelkleber]

Hey Pat, sorry for being slow to respond here.

Regarding the motivation for our old API design choices: We've generally tried to keep the APIs for sellers as similar as possible, to make it easy to handle the single-seller and multi-seller auctions with the same code.

At this point, now that the API has reached general availability, there's a very high bar for changing these sorts of details. Your proposed alternatives seem to have the same information available in the same places, and to also require some amount of coordination between top-level seller and component seller and buyer. Since the choices accomplish the same goal in pretty much the same way, we certainly wouldn't want to change things at this point.

As for the details of your suggestions, I would personally be terrified of our choosing to do a JSON merge, since it would mean every single key was in danger of one of the two values clobbering the other. My counter-suggestion would be for buyers and sellers to generally agree on a field name inside the component seller's sellerSignals object where the top-level seller could include some top-level signals.

This kind of industry-created standard is how we've consistently encouraged API users to move information around. It's a much more future-proof approach, rather than the browser standardizing an API change every time the ads industry agrees that some additional structure is warranted.

[patmmccann]

.My counter-suggestion would be for buyers and sellers to generally agree on a field name inside the component seller's sellerSignals object where the top-level seller could include some top-level signals.

That's a great suggestion and one we've taken up at Prebid, writing information to the auction config we receive before passing those config along to the top-level seller

However, The gam team has expressed an unwillingness to do this as they think rewriting others' auction config is exposing them to some sort of contractual risk; and since they have a publisher ad serving monopoly and PAAPI delivered direct from sellers signal API enabling them to prevent publisher choice in top level seller, your proposal doesn't solve for the use case where publishers and gam want to share the OB floor or other ad server calculated values with component buyers.

I think an explicit place to share top level signals with component buyers remains ideal, even if it takes us some time to realize due to the feature freeze you discuss.

[michaelkleber]

Oohhhhhh, thank you Pat, that is news to me. Then I guess it really is our problem to define a clear dedicated information channel for this purpose, and now we need to figure out what we can do that is backwards-compatible.

Thanks, we will try to come up with something.

[patmmccann]

@michaelkleber thank you; as additional information, this is the Prebid PR following your suggestion and your comments are welcome or just if you're curious prebid/Prebid.js#10649

[patmmccann]

@michaelkleber : another use case has arisen,

If the top level seller sets the timeout, how do the component sellers lower the timeout they communicate to buyers to be within that limit? It seems sometimes component auction config timeout is higher than top level timeout and we have a coordination problem.

[MattMenke2]

@patmmccann: Top-level sellers can't set timeouts for component auctions. Their timeouts only apply to the top-level auction. That having been said, buyers currently can't see the component auction timeouts, either (either cumulative or per-script-execution).

[patmmccann]

@MattMenke2 It seems we currently have the primary top level seller varying top level timeout widely without any way to tell component buyers. How do we solve this?

[MattMenke2]

The top-level seller's timeouts currently don't affect component buyers, only component seller timeouts do, so there's no actual need for them to know about the timeouts that don't affect them (or anyone else). We could change that, of course, though then we'd need to decide how it would interact with component seller timeouts (Do we take the minimum of the two? If one matches a buyer by name, and the other matches it with a "*" rules, do we prefer the exact match, or again, take the minimum of the two? Or something else?)

[MattMenke2]

Another fun question: If the top-level auction has a per-buyer cumulative timeout, do we apply it once to that buyer across all auctions (But waiting until all promises for all auctions are resolved), or independently to the buyer in each component auction?

[dmdabbs]

The latter, IMO.