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!

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.

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()?

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.

"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.

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

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.

@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

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?

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 :-).

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.