[Proposal] Seller Prefiltering Function

[IanAtGoogle]

One of the basic purposes of the seller’s scoreAd function is to ensure that PA-API candidates exceed the auction floor price. This check, in most cases, is a trivial function “if A < B then reject” and does not depend on any data from the seller's trusted keyval. However, in the current PA-API setup, even running this trivial check incurs meaningful network latency in order to fetch the seller’s trusted keyval.

We propose a new top-level function in the existing seller’s script called “prefilterAd()” which runs some filtering logic on buyers’ bids without data from the seller’s keyvals. Chrome would first evaluate all buyers' candidates against this lightweight function and only call the seller’s keyval with eligible bids (if at all).

This optimization would…
(1) Prevent the seller's trusted server call entirely in cases where no PA-API candidates beat the auction floor.
(2) Otherwise reduce the request and response payload sizes of the seller’s trusted keyval by removing candidates that could never win.

[michaelkleber]

My instinctive reaction is that this idea actually would not improve latency or efficiency, because in the flow you describe, the browser performs some JS execution both before and after the trusted server call. That's an inherently latency-bad situation: we wouldn't want to set up and destroy the execution context twice, but we also wouldn't want it to sit around using resources while waiting for network.

Is there any kind of SSP pre-filtering that you could imagine that is compatible with static declaration though? Anything which does not depend on SSP JS execution, which could be evaluated by the browser directly, would indeed offer the kind of benefits you point out.

(@MattMenke2 PTAL in case I am being too pessimistic here.)

[MattMenke2]

I agree that running yet another isolated Javascript function seems likely to have significant performance implications. Even if we allowed reusing seller contexts between bids, the cases where that would be a safe thing to do is pretty limited. I agree that static filters seem like a much more performant alternative.

We could extend something that works much like the buyer priorityVector dot product logic to sellers, and provide them the bid. We could include something like browserSignals.bid.: value in one of the vectors. Or could do something simpler.

[dmdabbs]

Would that the world was simple with One Floor To Rule Them All (apologies to Tolkien) amenable to a declarative approach, and that buyers always abided by floors. But each buyer may have multiple floor options depending on the selection of deals available to them for the opportunity.

[MattMenke2]

We could allow buyers to provide that in the vector as well...but of course, then then seller vector would have to list every single deal as well, to be multiplied by whatever specific deal field the buyer populated to indicate that field.

That having been said...This filter does not have to be exact, it just has not let through a significant subset of deals that would be rejected out of hand, so you could tell your buyers to put in some specific information in the vector to correctly account for their choice of deal. Of course, that requires a lot of coordination, which may be an unrealistic expectation, or require revealing information sellers would rather not share.

[dmdabbs]

Having said that, I suppose if PA conferred first-class status for Deals with a declarative seller-to-buyer channel (say a perBuyerDeals) then the trivial A> B could be possible sans JS. PA would grok floors and how to assess given the buyer's dealid declaration with the bid(s).

[MattMenke2]

Why would they need to be first class citizens here? Couldn't they be passed via perBuyerSignals or whatnot, and buyers could just indicate deals in some vector they provide to the seller, to be multiplied by a seller-provided per-buyer vector? Might not be the best option, just not seeing what makes it require special deal ID stuff. In general, we want to provide as general APIs as we can, to dictate as little as possible about how the advertising ecosystem works.

[dmdabbs]

Couldn't they be passed via perBuyerSignals or whatnot, and buyers could just indicate deals in some vector they provide to the seller, to be multiplied by a seller-provided per-buyer vector?

If I'm getting the sketch, sellers would provide deal metadata 2x, ORTB-compatible plumbed via perBuyerSignals paralleled by a declarative PA vector. And buyers likewise in two channels - deal id (as selectedBuyerAndSellerReportingId, assuming current offering) and also that string in some new bid response attribute. I say attribute versus vector since a placed bid has zero/one dealid. Or are you proposing that buyers reply with an array of bids (assuming multi-bid) and a vector that encompasses that collection of bid(s)?

to be multiplied by a seller-provided per-buyer vector

How would this determine whether a bid >= it's associated floor?

[sbelov]

we wouldn't want to set up and destroy the execution context twice, but we also wouldn't want it to sit around using resources while waiting for network.

What would be an issue with having the initialized JavaScript execution context be alive while waiting for network? Can we not assume that, unless there are zero bids remaining after such proposed pre-filtering, it is a very high likelihood that we would need to run scoreAd once the network call succeeds?

And, if on the other hand, the network call fails, we can surely destroy said JavaScript context – which we should be able to find out relatively soon.

[sbelov]

By the way, there can be other use cases where early seller scoring without the knowledge of trusted scoring signals can be beneficial, for example, filtering based on buyer bid declarations (in the adMetadata argument to scoreAd, as returned from generateBid), similar to how that's done in OpenRTB bid responses. These declarations could, for instance, include a seat ID, a deal ID, an advertiser domain or landing page. It seems complex to me to attempt to define filtering behavior on the basis of an arbitrary information about a bid (bid price and/or adMetadata) in a declarative way, without developing yet-another-language of some sort. It would be great if ad tech providers could encode such rules using simple algorithms in regular programming language constructs, which they can evolve over time as the industry and business cases evolve…

[MattMenke2]

we wouldn't want to set up and destroy the execution context twice, but we also wouldn't want it to sit around using resources while waiting for network.

What would be an issue with having the initialized JavaScript execution context be alive while waiting for network? Can we not assume that, unless there are zero bids remaining after such proposed pre-filtering, it is a very high likelihood that we would need to run scoreAd once the network call succeeds?

It's potentially slower than fetching the signals, and it's competing for system resources with everything else, including generating bids, and of course running the page itself. Creating and tearing down Javascript contexts is a heavy weight operation. We really don't want to add any more context creation operations that block auctions, particularly ones that we do for every bid (as opposed to just for, e.g., the winner post-auction).