Additional options for PA Deal Support

[rdgordon-index]

Deals (private marketplace) have been the focus of a number of issues -- #716, #682 #686 -- and I'd like to suggest some options for consideration.

buyerAndSellerReportingId and buyerReportingId are interest group attributes -- however, there's no a priori correlation between a dealID and a particular renderURL (aka creative) -- that is, in principle, a given dealID could accompany any creative for a given buyer. Furthermore, new deals can be created after a browser joins an IG, and having to update each IG with each potential dealID seems cumbersome.

Furthermore, as noted elsewhere, both scoreAd() and reportResult() need to receive the dealID (not to mention reportWin()) -- this signal must exfiltrate the device -- as it's fundamental both to revenue share calculations as well as reporting attribution.

The list of dealIDs for any given slot is also highly dynamic -- and each DSP will receive a different subset of those dealIDs for any given slot. Assuming we're talking about contextual-based deal activation (not publisher audience extension, which has been discussed elsewhere), in principle, an SSP would be able to return perBuyerSignals with a per-DSP list of potential dealIDs. Making this available to on-device bidding could follow existing API surfaces -- the challenge is how to get it 'back out' in a privacy-centric fashion.

Perhaps there's an opportunity to consider the notion of dealIDs handled like interest groups -- i.e. a "deal group" -- where the browser maintains such a list for k-anon purposes -- tied to a seller origin. Once thusly registered with the browser (i.e. via a joinDealGroup() call), the seller can return a list of dealIDs via the contextual response, linked to their buyer origins. In this model, existing IGs could be upgraded to include 'deal intent' -- a boolean indicating if a given IG ever intends to bid with a dealID -- and thus the brower would be able to deal with k-anon determination well before auction time, and for an defined set of (IG, renderURL, dealID) tuples. Once k-anon has been satisifed, exposing this to PAAPI functions shouldn't be a privacy concern anymore.

There's another potential alternative -- leveraging https://github.com/WICG/turtledove/blob/main/FLEDGE.md#6-additional-bids (#319) in order to be able to derive the creativeURL for a dealID via the contextual response. In this model, there would be some OpenRTB-powered mechanism to signal that dealID response would only be used for a PA auction (like in the additional bids workflow); but this, too, would allow for the dealID to be made visible to the PAAPI functions.

[leeronisrael]

Hi Roni,

We have received a significant amount of feedback that Deals are an important use case for the industry today. According to IAB TL: Deals, also referred to as Private Marketplace (PMP) offer curated or exclusive access, or preferred pricing for buyers on a subset of inventory. Also, referred to as “programmatic deals,” agreements for PMPs can be organized between publishers or SSPs and DSPs, agencies or advertisers. A notable, related use case is Publisher Audience Extension (issue #144). In this use case, sellers curate audience information for buyers, in some cases using Deals to package that information across sites. This latter area is currently under exploration by Chrome, but not addressed within this design.

We understand there are several components to Deals. Two of the most essential are the concept of a seat ID and deal ID. They are defined as:

• A seat ID is an identifier that represents a buyer’s customer (typically an advertiser or agency). A seat ID may have billing implications, for example, if a given seat has a discount with a given seller.
• A deal ID is an identifier that represents an agreement between a buyer (e.g., advertiser, agency) and seller (e.g., publisher). A deal ID may have many properties, such as a cost/price, volume commitment, audience information, exclusivity, and more
• A seat ID may also interact with a deal ID, for example, if a deal ID is limited to a set of seat IDs for a specific buyer

Based on the feedback so far, we have identified some requirements:

• The seat ID originates with buyers
• The deal ID may originate with either the buyer or seller. The eligible deals are typically the intersection of the deals pre-registered by buyers in interest groups and deals sent by sellers in the contextual bid request
• Both IDs need to be available for auction processing (i.e, generateBid and scoreAd)
• Both ID need to be reliably available via the relevant reporting mechanisms (i.e., reportWin and reportResult)

Our proposed solution is to make some modifications to an existing field, buyerAndSellerReportingId, to accommodate the use case:

1. Chrome modifies buyerAndSellerReporting ID to accept a string or an array. This field is located in each ads object within an interest group
   • Each element in the array is a string. For example, each string in the array may represent both a seat and deal ID
2. generateBid selects a value from buyerAndSellerReportingId. The buyerAndSellerReportingId array is made accessible to generateBid. In generateBid, the buyer identifies the specific ID from the buyerAndSellerReportingId array that should be reported on.
   • This can be used to represent the seat ID, deal ID, or both, for the generated bid
3. The selected value from generateBid is made accessible as an argument to scoreAd. The seller can consider the deal when selecting the winning bid.
4. Chrome recognizes a new, optional field in the output of generateBid that buyers can use to require the buyerAndSellerReportingId to appear in the relevant reporting functions
   • This is in contrast with the current behavior, where the ID may be dropped by the browser if the ad and the ID do not jointly meet the k-anonymity threshold. With the proposed new flag, if the combination of render URL and buyerAndSellerReportingId does not meet the k-anon threshold, then the bid will be withdrawn. This is designed to ensure reliable reporting (i.e., only win the auction if the ID will pass k-anon and be reported on)

The end to end flow may look like the following:

1. Before the auction
   1. The buyer pre-registers seat and deal IDs in the buyerAndSellerReportingId field in interest groups either when creating or updating the interest group
2. At contextual auction time
   2. The seller sends deal IDs in the contextual bid request
   3. The buyer identifies the relevant deal IDs in the perBuyerSignal field of the contextual bid response
3. At PA auction time
   4. The seller forwards this list of buyer-identified deal IDs into the auction via perBuyerSignals
   5. In generateBid, the buyer decides if they want to bid on a deal ID. If so, the buyer specifies an ad and a deal ID from the ad's buyerAndSellerReportingId array, indicating the bid was generated for that deal ID.
   6. The buyer optionally indicates if the selected buyerAndSellerReportingId is required to appear in the relevant reporting function.
   7. The selected deal ID is made accessible to scoreAd. The seller picks the winning bid, considering the deal ID and any special terms. (If the seller does not think the buyer-chosen deal ID applies, then the seller rejects the bid, by giving it a negative desirability in scoreAd).
4. At PA reporting time
   8. Depending on step 3.6 and if the render URL and buyerAndSellerReportingId meet the k-anon threshold, then the deal ID is reported on in reportResult and reportWin

There are a few design plans to highlight:

• K-anon incrementing behavior
  • We propose to use the same k-anon incrementing behavior in place for IG ads today:
    • In order for an ad associated with a given deal ID to be shown to users, it must exceed the threshold of 50 users over 30 days
    • The counter is incremented each time that the Render URL + string from buyerAndSellerReportingId would have won the auction, but was withdrawn by the browser due to not exceeding the k-anon threshold
• Incorrect identification of ID in buyerAndSellerReportingId array
  • If generateBid identifies an ID that does not exist in the buyerAndSellerReportingId array (step 3.5 in the list above), then the browser will withdraw the bid entirely

We welcome feedback on this proposal!

[rdgordon-index]

Thanks @leeronisrael for the detailed proposal. I'll highlight a few challenges:

The buyer pre-registers seat and deal IDs in the buyerAndSellerReportingId field in interest groups either when creating or updating the interest group

This requires a given IG to include all the seats and all the dealIDs -- and implies that the buyer is necessarily aware of these when creating or update the IG.

The seat is associated with the advertiser and campaign, outside of the bidding process -- and generally doesn't vary per seller -- so that seems feasible; furthermore, since this bid is associated with a single seat on a given buyer, the k-anon shouldn't be impacted.

However, on the deals side, this seems problematic -- this would require somehow bringing awareness of the dealIDs to the IG creation/update process -- rather this merely being an attribute of the bidding logic JS/WASM and TBS fetched from the buyer's KV.

This can be used to represent the seat ID, deal ID, or both, for the generated bid

How would a seller know what this would represent, consistently, across buyers, in order to make sense of this value? I would prefer that we didn't combine seat and dealID into a single attribute. Furthermore, from a k-anon perspective, this would explode the cardinality -- every dealID x every seat -- which would greatly diminish the ability of these deal bids to render and win impressions.

Furthermore, as highlighted in #792, there are other reasons why seller need to know the seat for a given renderURL -- so parsing it conditionally out of this field seems brittle at best given the above.

3. The buyer identifies the relevant deal IDs in the perBuyerSignal field of the contextual bid response

Can you elaborate further? (4) below suggests the seller should be forwarding the list, but this point seems to suggest a role for the buyer? Conceptually, the buyer might not even know in advance what dealIDs are relevant outside of the on-device auction. Of course, the buyers are welcome to pass any signals they want in buyerdata -- but I'm not sure I understand this requirement for the proposal to work.

4. The seller forwards this list of buyer-identified deal IDs into the auction via perBuyerSignals

The sequential auction setup results in preBuyerSignals being a pass-through mechanism for the buyer to pass their buyerdata associated with their origin directly to the auctionConfig via the igbid extension. This would require all buyers and sellers to have an agreed-upon data structure to include the dealID array in a pre-determined location within buyerdata -- which, today, is just 'JSON-serializable', and not manipulated by the seller -- for use this when building the contextual response (seller) and extracting this key/array from perBuyerSignals parameter in generateBid (buyer).

In order for an ad associated with a given deal ID to be shown to users, it must exceed the threshold of 50 users over 30 days
if the render URL and buyerAndSellerReportingId meet the k-anon threshold

Unlike seat, there's no a priori relationship between a renderURL and a dealID -- so this will have a significant impact, since each combination would need to meet k-anon, rather than the renderURL and the dealID independently.

6. The buyer optionally indicates if the selected buyerAndSellerReportingId is required to appear in the relevant reporting function.
7. Depending on step 3.6 and if the render URL and buyerAndSellerReportingId meet the k-anon threshold, then the deal ID is reported on in reportResult and reportWin

Would the seller be aware of this decision when the bid is received in scoreAd? In other words, how can a seller know if the dealID will be available in reportResult before scoring the bid with a non-negative desirability score? If the dealID affect the scoring logic in any way, this would be a requirement for the seller's reporting function.

[bretg]

It's been a month -- has there been progress outside of this issue on including seatId as a parameter that can be sent to the seller's reportResults()?

[zhuoli-fledge]

1. Chrome modifies buyerAndSellerReporting ID to accept a string or an array. This field is located in each ads object within an interest group

   • Each element in the array is a string. For example, each string in the array may represent both a seat and deal ID

2. generateBid selects a value from buyerAndSellerReportingId. The buyerAndSellerReportingId array is made accessible to generateBid. In generateBid, the buyer identifies the specific ID from the buyerAndSellerReportingId array that should be reported on.

   • This can be used to represent the seat ID, deal ID, or both, for the generated bid

In case of multi bid, multiple values should be selected from buyerAndSellerReportingId.

3. The selected value from generateBid is made accessible as an argument to scoreAd. The seller can consider the deal when selecting the winning bid.

adMetadata can be one option, but requires sync with ssp to understand the exact fields.

4. Chrome recognizes a new, optional field in the output of generateBid that buyers can use to require the buyerAndSellerReportingId to appear in the relevant reporting functions

This likely needs to be an array to adapt multibid's use case, which serves like an allowlist. A deal id can be reported only if it shows up in this array.

[pm-harshad-mane]

sequenceDiagram
    participant Buyer
    participant Seller

    Note over Buyer,Seller: Before the auction
    Buyer->>+Seller: Pre-register seat & deal IDs in buyerAndSellerReportingId

    Note over Buyer,Seller: At contextual auction time
    Seller->>Buyer: Send deal IDs in contextual bid request
    Buyer->>Seller: Identify deal IDs in perBuyerSignal of bid response

    Note over Buyer,Seller: At PA auction time
    Seller->>Seller: Forward list of deal IDs via perBuyerSignals
    Buyer->>Buyer: Decide to bid on deal ID and specify ad and deal ID
    Buyer->>Seller: Optionally indicate buyerAndSellerReportingId requirement in reporting
    Buyer->>Seller: Selected deal ID accessible to scoreAd
    Seller->>Buyer: Pick winning bid or reject bid

    Note over Buyer,Seller: At PA reporting time
    Seller->>Buyer: If k-anon threshold met, report deal ID in reportResult and reportWin

Loading

[pm-harshad-mane]

"buyerAndSellerReportingId" is a generic name , if we want to use this field only for deal-id then we can rename this field or create a new field with appropriate name and dedicated purpose. Otherwise it will be difficult to know at execution time whether this field is used for deal or some other purpose.

"The deal ID may originate with either the buyer or seller."
Is proposal only handling the seller originated deal IDs?

As per the nature of the deals, PA core logic can make it mandatory for buyers to pass seatId to make the deal work.

[rsachdev9191]

At a high level, Magnite is aligned with Google on this proposal for the basic deal use case (based on contextual targeting) but there a few caveats to this approach:

• The proposal does not work for deals targeting component seller owned audiences
• The proposal in contingent on generatebid being able to return multiple bids
• It's unclear if the interaction of buyerAndSellerReportingId and buyerReportingId could have a negative impact
• When doing it at scale, it's unclear if it impacts the k-anon requirement (more from a DSP's perspective)
• Unclear about the impact it has on the ig size in the browser
• General latency concerns when evaluating multiple bids in the browser for both generatebid and scoread

[leeronisrael]

Thanks @rsachdev9191 ! See our responses in-line below:

The proposal does not work for deals targeting component seller owned audiences

Yes, we acknowledge that use case is a priority, but it is out of scope for this solution.

The proposal in contingent on generatebid being able to return multiple bids

The ability for generateBid to return multiple bids has landed in Chrome 125 at 1% of traffic.

It's unclear if the interaction of buyerAndSellerReportingId and buyerReportingId could have a negative impact

We are aware that some buyers may have concurring use cases that require buyerAndSellerReportingId and buyerReportingId. Currently, the default behavior is that the former will overwrite the latter. We propose to make it possible to report on both fields, subject to a joint k-anon check. In other words, buyerAndSellerReportingId + buyerReportingId + renderURL will need to be jointly k-anonymous in order for all values to be reported on.

When doing it at scale, it's unclear if it impacts the k-anon requirement (more from a DSP's perspective)

We have received some directional feedback that k-anon will not have a material negative impact on the proposed solution's ability to support the use case. We welcome additional analysis from other DSPs on this.

Unclear about the impact it has on the ig size in the browser

We do expect this will increase the size of IGs in the browser. There is an overall size limit for all IGs. There is potential future opportunity to optimize IG size, but we do not see it as a blocker for this solution.

General latency concerns when evaluating multiple bids in the browser for both generatebid and scoread

We agree with this concern, but it is not specific to the Deals use case. That is, latency concerns may exist with multiple bids regardless of whether or not we move forward with this solution. Therefore, we do not intend to block this solution on this potential issue.

Some in the industry have expressed another concern we’d like to highlight:

There may be other use cases that utilize BuyerAndSellerReportingId, such as Seat ID.

We believe the best solution is for the industry to align on a standardized string format that can be represented in the buyerAndSellerReportingId array, and supports the various use cases. For example, this may look something like, “{d:123,s:456,o:789}”, where “d” represents deal IDs, “s” represents seat IDs and “o” represents some other ID.

[zhuoli-fledge]

@leeronisrael Would it be possible to also have sellerReportingId that fits the seller's use case. Take deals as an example, seat id is something that seller wants to know but not buyer. By moving seat id to sellerReportingId can help decrease the IG size for buyers.

The k-anon requirement would be buyerAndSellerReportingId + buyerReportingId + sellerReportingId + renderURL

[rdgordon-index]

We believe the best solution is for the industry to align on a standardized string format that can be represented in the buyerAndSellerReportingId array, and supports the various use cases. For example, this may look something like, “{d:123,s:456,o:789}”, where “d” represents deal IDs, “s” represents seat IDs and “o” represents some other ID.

question: is there any reason why this proposal can't include the introduction of new fields? Can you elaborate on why it's preferable and/or advantageous to re-purpose buyerAndSellerReportingId versus simply having a dedicated fields for seatID and dealID?

[michaelkleber]

In general, it's better for the browser to offer a pipe with the required privacy characteristics, and let the API user put what they want to put into the pipe. If we offer a pipe that is specific to one use case, then each time you figure out a new use case, you need to come back and ask the browser to build a new pipe for it.

I guess I would ask the opposite question: Why would you rather wait for us to add a field with a new name and new complexity, rather than reuse something we added a year ago? We could indeed add new fields if there were a functional reason to do so. Or we could change the name of an existing field if a different name turns out to be better — that's not discussing functionality, it's discussing spelling :-).

[rdgordon-index]

Why would you rather wait for us to add a field with a new name and new complexity, rather than reuse something we added a year ago

Well, there are a myriad of other changes required here -- it's not simply a matter of 'adopting' an existing field and using it for contextual deal targeting -- so if we're changing other things, that affords us the opportunity to revisit.

In general, it's better for the browser to offer a pipe with the required privacy characteristics, and let the API user put what they want to put into the pipe

Aligned that if we have a general-purpose 'pipe', API users can make the most of it, the naming/spelling indeed at that point is secondary.

[JensenPaul]

Since Leeron published the proposal listed above in his March 13th comment, we’ve explored a lot of alternatives, spoke to a lot of interested parties, and received a lot of feedback. We’ve decided this proposal satisfies most of the need for supporting deals in Protected Audience so we’ve decided to move forward with implementing it.

Noting that the proposal reuses the previously defined buyerAndSellerReportingId field, we’re including a couple tweaks to make it more ergonomic and to prevent breaking pre-existing use of this field and the buyerReportingId field. These tweaks should not break the existing functionality in Leeron's proposal.

Tweak 1: allow use of buyerReportingId and buyerAndSellerReportingId at the same time

The goal of this tweak is to allow someone adopting buyerAndSellerReportingId to support deals, to continue using buyerReportingId for pre-existing usage. Previously using buyerAndSellerReportingId took precedence over using buyerReportingId so only one field could be used at a time. To allow use of both fields (e.g. buyerAndSellerReportingId for deals and buyerReportingId for some pre-existing purpose) at the same time: when buyerAndSellerReportingId is specified as an array and buyerReportingId is specified, both buyerAndSellerReportingId and buyerReportingId will be passed to reportWin(), if they are jointly k-anonymous with the interest group owner, bidding script URL, and render URL. Leeron mentioned this tweak two weeks ago in response to Magnite’s comment.

Tweak 2: add a sellerReportingId string field that can be used with the other two reporting IDs

The goal of this tweak is to allow someone adopting buyerAndSellerReportingId to support deals, to continue having a field available to specify a field reported to sellers without having to duplicate it in each buyerAndSellerReportingId array element. This can support pre-existing use of buyerAndSellerReportingId without bloating the size of their interest group unnecessarily. If the same seat ID is always presented for bids on an ad, the seat ID could be stored in the sellerReportingId. Specified more formally: when buyerAndSellerReportingId is specified as an array and the sellerReportingId string field is specified, both buyerAndSellerReportingId and sellerReportingId will be passed to reportResult(), if they are jointly k-anonymous with the interest group owner, bidding script URL, and render URL.

To avoid a combinatorial explosion on the number of k-anonymity checks the browser must perform, when buyerAndSellerReportingId is specified as an array, the browser will do one k-anonymity check for each element in the buyerAndSellerReportingId array along with the buyerReportId (when present) and sellerReportingId (when present) and the interest group owner, bidding script URL, and render URL. This allows generateBid() to select which buyerAndSellerReportingId to report because the browser has already checked the k-anonymity of each. buyerReportingId and sellerReportingId are always passed to reportWin() and reportResult() respectively, when they’re present in the interest group and jointly k-anonymous. If a buyer wants to report the buyerReportingId and the sellerReportingId without a buyerAndSellerReportingId (e.g. if they’re not bidding on a deal) then they should include an empty string in the buyerAndSellerReportingId array, and select the empty string buyerAndSellerReportingId at generateBid() time.

As Leeron’s proposal indicates, the buyer optionally indicates at generateBid() time, with a new field, if the selected buyerAndSellerReportingId is required to appear in the relevant reporting functions. This field will now apply to all three IDs: If all three are not jointly k-anonymous, and buyerAndSellerReportingId is marked optional, then the bid can still be submitted, but the sellerReportingId, buyerAndSellerReportingId, and buyerReportingId will not appear in the relevant reporting functions. If all three are not jointly k-anonymous, and the buyerAndSellerReportingId is marked required, then the bid will be withdrawn.

[rdgordon-index]

If the same seat ID is always presented for bids on an ad, the seat ID could be stored in the sellerReportingId. Specified more formally: when buyerAndSellerReportingId is specified as an array and the sellerReportingId string field is specified, both buyerAndSellerReportingId and sellerReportingId will be passed to reportResult()

If all three are not jointly k-anonymous, and buyerAndSellerReportingId is marked optional, then the bid can still be submitted, but the sellerReportingId, buyerAndSellerReportingId, and buyerReportingId will not appear in the relevant reporting functions.

I'm trying to better understand the implications of the above two statements.

First question: will the sellerReportingId field also be visible to scoreAd as well as reportResult? In Leeron's original proposal, the buyerAndSellerReportingId was noted to be available, but I wanted to make sure that this applies to this new field as well.

Second question: if sellerReportingId is meant to store the seat ID, and buyers adopt this convention across the board, that implies that sellers will need to ensure that it's always available -- how would this work if it's marked optional? Do you expect an empty string to signify 'no seat', much like an empty string to signal 'no deal', in the general case? In other words, how can a seller determine if we're being subject to k-anon fields being dropped, or if they're simply omitted?

We’ve decided this proposal satisfies most of the need for supporting deals in Protected Audience so we’ve decided to move forward with implementing it.

There have been a number of tweaks / changes along the way -- is there a document with the complete revised proposal that we can review to confirm that it does indeed support deals before we proceed?

[JensenPaul]

First question: will the sellerReportingId field also be visible to scoreAd as well as reportResult? In Leeron's original proposal, the buyerAndSellerReportingId was noted to be available, but I wanted to make sure that this applies to this new field as well.

Yes, sellerReportingId will be available to scoreAd() as well as reportResult().

Second question: if sellerReportingId is meant to store the seat ID, and buyers adopt this convention across the board, that implies that sellers will need to ensure that it's always available -- how would this work if it's marked optional?

If the same seat ID is always presented for bids on an ad, the seat ID could be stored in the sellerReportingId. How these fields are used is up to auction participants. If sellers want to ensure it’s always available, they can require such in scoreAd() and reject any bids without it. If bids always pair a particular sellerReportingId with a particular render URL, then the render URL should reach the k-anonymity bound at roughly the same time as the pair of the render URL and sellerReportingId does.

Do you expect an empty string to signify 'no seat', much like an empty string to signal 'no deal', in the general case?

This is up to how auction participants want to use the fields. Could a seat ID be ignored by the seller if a deal ID is not present in the bid?

In other words, how can a seller determine if we're being subject to k-anon fields being dropped, or if they're simply omitted?

As proposed, a seller cannot determine if it’s omitted or dropped. If a buyer marks the buyerAndSellerReportingId as required, then the seller wouldn’t see cases where the sellerReportId is dropped. How does the seller’s response to omitted versus dropped differ?

There have been a number of tweaks / changes along the way -- is there a document with the complete revised proposal that we can review to confirm that it does indeed support deals before we proceed?

There is not yet a document that combines Leeron’s proposal and my two tweaks.