Add to explainer: creative scanning via BYOS/V1 trusted scoring signals.

[orrb1]

As noted in #792, one of the
responsibilities of sellers is to make sure that the ad shown meets the
publisher's restrictions. Today, when a seller considers an ad for which
a buyer is bidding, they verify, for example, that the ad is not about
any of the subjects the publisher does not want shown on their site.
Determining the subject of an ad - a process called creative scanning -
can be slow, as it utilizes some combination of AI and human evaluation.
Sellers have historically relied on populating a creative scanning
pipeline through a combination of pre-registration and by discovering
ads through the bid stream. Sellers generally require creative scanning
to complete before allowing an ad to win an auction. This process proves
to be challenging in Protected Audience API because the auction runs in
isolation, and so it can't send ads out to have them evaluated, since
doing so would potentially leak information about the user's identity by
associating their activity on the publisher site with past activity on
advertiser sites. This change enables sellers to discover ads for
creative scanning by leveraging the stream of ads sent to their
bring-your-own-server (BYOS) real-time scoring signals key/value
service. It does so by making it possible for sellers to request that
the auction include some additional metadata alongside each ad's
renderURL on the request to the real-time scoring signals key/value
service. This includes some existing metadata — the buyer's origin, ad
size, and buyerAndSellerReportingId — as well as a new field titled
creativeScanningMetadata. This solution addresses the needs of creative
scanning until a future solution is implemented that's compatible with
the privacy-advancing requirement of Trusted Execution Environment
(TEE)-hosting for real-time scoring signals key/value service. This
solution does not regress the current privacy properties of Protected
Audience.

[rdgordon-index]

and need not be JSON-serializable

In practice, though, this will not likely be a scalar, and multiple key- values, like metadata will need to be captured here -- does this mean implementers will need to run JSON.parse()?

[orrb1]

It's up to the ecosystem to decide what belongs in creativeScanningMetadata. Because this will be sent as a URL query parameter to the seller's KV server, we chose a string to give developers the most flexibility to encode their data efficiently. As JSON-encoded data often contains spaces, curly braces, colons and commas that must be expanded during URL-encoding, a carefully delimited string can sometimes be more efficiently URL-encoded. If creativeScanningMetadata contains JSON, then, yes, implementers will need to run JSON.parse() to parse it in scoreAd().

[ccharnay67]

We think that us as buyer may need to pass different creative scanning data depending on the seller. SSPs may have different creative validation processes.

Would you consider having creativeScanningMetadata as a JSON-serializable object, where keys would be seller domains? Then, Chrome could maybe pass to a given seller's KV server only the creativeScanningMetadata relevant to them, i.e. the value corresponding to their domain as key.

There could be a case for this value also being a JSON-serializable object, but having it as a string will be fine for most of our usecases.