Publisher ad network control over ad eligibility and auction ranking

[sbelov]

Publisher ad networks need to rank ad candidates submitted by advertisers based on bid values expressed in publisher payout, net of fees or revshare. Sometimes ranking logic also needs to take into account special arrangements (deals, custom fees) specific to an advertiser, a publisher or an advertiser-publisher pair. In an auction for a single ad slot, ad candidates can be ranked one at a time.

In addition, publisher ad networks typically have to consider ad eligibility; some ads may be disallowed to serve in the given context due to the publisher’s brand safety or advertiser blocks, low ad quality and other factors.

The current TURTLEDOVE proposal does not explain how publisher ad networks or SSPs can control these ranking and eligibility decisions in an on-device auction (similar concerns were raised in PARRROT by @brodrigu). While publisher ad networks could augment or wrap bidding functions provided by advertiser ad networks (DSPs) so as to include publisher auction logic, that seems inconvenient and would require complex coordination to run a separate interest group request flow for each DSP-SSP pair.

Can you consider extending TURTLEDOVE with a native support for on-device interest group ad ranking and eligibility logic provided by a publisher or a publisher ad network / SSP?

The logic could be represented as a pure function that returns numerical ranking for a single interest group candidate that runs purely locally, without side effects in a browser-provided sandbox environment (e.g. with no access to the network or to the state of the current web page). The ad with the highest ranking would be “most preferred” to be shown from the publisher’s standpoint. A non-positive ranking value could signal that an ad should not serve.

function rankCandidate(interestGroupAd, contextualSignals) {
  // interestGroupAd may contain attributes of an interest group-based ad useful in determining
  // ranking and auction eligibility, for instance, ad category classification.
  // contextualSignals may, for instance, contain ad fees collected by an SSP for interest 
  // group ads.
  if (contextualSignals.disallowedCategories.includes(ad.category)) {
    return 0;
  }
  return ad.bid * (1 - contextualSignals.sspFees);
}

A ranking function to use could be specified when a publisher’s web page requests a browser to render interest group-targeted ads:

const metadata = {"network": "publisher-ad-network.example",
                  "ranking-function-url": "https://publisher-ad-network.example/rank.js",
                  "auction-signals": {"aboveTheFold": true, 
                                      "sspFees": 0.1,
                                      "disallowedCategories": ["travel"], …}, …};
const rendered = navigator.renderInterestGroupAd(contextualBid, metadata);

[JoelPM]

As I noted in #59, I believe the core tenet of TURTLE-DOV is to protect the user. It does so by allowing an SSP (for example) to access only either contextual information or IG information and in a way that can't be correlated. The consequence of this move is that an SSP can no longer make a single decision on the server side about what bid to respond with.

TURLTE-DOV proposes that a bid can have a sort of comparator function that can be used to determine the value in real time, with TURTLE-DOV performing the overall sort (still an open question whether it's a global sort over all bids or just a local sort over an SSPs bids - I heavily favor the latter as it keeps things much simpler [update: I opened #73 because I think this issue is so fundamental]). The question becomes what information is necessary for comparator functions to work successfully, and how it can be provided in a privacy maintaining manner.

I like the proposal that @sbelov is putting forward because I believe it is asking that an SSP (or other) be allowed to provide a single comparator that would have access to all bids it owns to assign value and order - this is a much simpler transition. On the other hand, I also really like the Augury proposal because it allows the SSP (or other) to assign value and order on the server side in the contextual request with a speculative list of IGs.

I think the challenge of #70 is that an SSP must push their decisioning logic to the client, and the challenge of Augury is that an SSP must predict what interest groups may be available (and there could be many).

In either case, though, both recognize the core decisioning challenge of TURTLE-DOV and provide solutions that move in the direction of addressing our core needs as an SSP.

[michaelkleber]

Yes, this approach seems like the generally correct way to address the DSP/SSP bidding/ranking split that was muddled together in the original explainer.

[JensenPaul]

Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into the Protected Audience (formerly known as FLEDGE) proposal's scoreAd function. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.