Deals support in Fledge (PA API)

[vishnu4fledge]

A deal is an advertising inventory agreement between a buyer (advertiser or agency) and a seller (publisher or exchange). Depending on the type of deal, the terms, and implementation will vary.

Some deals are guaranteed with agreed up front terms between a buyer and sellers, buyers and sellers both need to know how a deal is doing to honor those terms.

Fledge API has limitation that restrict advertiser, buyers and seller to support following deals feature set.

Functional gap	Deal type(s) affected	Advertiser Problem(s)	Buyer Problem(s)	Seller Problem(s)
Auction/Winning deals	Preferred Deals		I am being invited to a private auction by  this SSP but not sure for which deal (of the multiple I have with them)	I can only invite buyers with pre negotiated deals for this auction, but I'm not sure how to know in advance for which deal or buyer I should invite
Auction/Winning deals	All	Advertisers want to use 3rd party to measure performance of deals they buy, but there is no way to let 3PE know about winning deals
Deal Permissions	All		A request can have multiple deals but a buyer may not be permissioned to all of them. Buyer is getting requests to buy impressions with multiple deals, but not sure if they have permission to all.	Sellers request bids for deals but they have no way to let buyers know which deal their advertisers are permissioned to.
Deal Auction/Winner Reporting	All		A request can have multiple deals and  a buyer may buy one of them. I am getting requests to buy impressions with multiple deals, but not sure which one wins on device.	I am getting bids from buyers  but not sure which one they want to bid on.A request can have multiple deals and  a buyer can buy one of the permissioned one Seller wanted to know which deal a buyer is buying before accepting the bid
Deal Pacing	Guaranteed Deals		Buyer want to prefer a deal behind its goal to submit bid, but not sure how a deal is pacing against its goal at seller end	Seller want to prefer a deal behind its goal, but have no way to let auction know how a is deal pacing
Debugging			Buyer want to know why a deal bid lost in auction

[michaelkleber]

I believe it's already possible to support the things you're trying to do. Please take a look particularly at these parts of the Protected Audience proposal:

(1) The buyerAndSellerReportingId property associated with each ad held by an Interest Group. If you include your deal information in this field, then it should be available in your reports, as long as it passes the usual k-anonymity check.

(2) The aggregate reporting capabilities, including the ability to declare aggregate contributions during generateBid() or scoreAd() which will only be sent if the given ad is the winner (with the reserved.win trigger).

Of course we are always happy to further discuss ways to better meet your goals, but first let's consider how good a fit the existing mechanisms are.

[vishnu4fledge]

After reviewing all options, I found following

1. buyerAndSellerReportingId is max one per ad while ad can have multiple deal targeted hence this will not work, or we have to create multiple copy of same ad, one per deal. That will create latency issues and increase size of IG
2. The aggregate reporting capabilities: I see this is recommended for click and win reporting, can it work for impressions too?

Solution to impression event with deal to buyers and sellers, and deal event notification to 3Ps are still open

I compiled a list of supported and not supported use case in the following table with respective Pa-API solution, please review and suggest a feasible solution in PA-API.

Supported and feasible use cases

Deal Feature Set	Comments	Solution For SSP	Solution For DSP
Deal offering: An exchange(SSP) can offer multiple deals with/without open auction in the same OpenRTB requests, and buyers can pick which deal they want to bid on or whether they want to bid on open auction(if offered).	Supported	SSP can use sellerSignals and contextual requests to specify a  list of deals and respective data .	DSP can use buyerSignals in  contextual response to specify list of deals they want to bid on
Deal Floor bids: SSP can specify a minimum floor to accept a bid on a deal.	Supported	SSP can use sellerSignals as well the contextual requests to specify list of deals and respective floor	DSP can use buyerSignals in  contextual response or sellerSignals to specify list of deals and floors
Permissions And Sharing: By default, Deals will be permissioned to the Customer sources:	Supported	SSP can use sellerSignals as well the contextual requests to specify list of deals and respective permissions	DSP can use buyerSignals in  contextual response or sellerSignals to specify list of deals and permissions
Deal Auction, SSP want to know which deal is the bid	Supported	SSP can use ‘adMetadata’’ provided by buyer’s generateBid()  in scoreAd() to consider the bid for the deal	generateBid() is an object which contains 'ad': adObject, adObject is a container that can hold arbitrary data of DSP choice.DSP can set a deal they want to submit a bid for in this object to SSP, as an output to their generateBid()

Not supported or suboptimal solution use cases(One render URL per ad per deal can work here but it will add lots of latency and increase size of IG) Deal Feature Set	Comments	SSP Problem	DSP Problem
Reporting win , impressions with deal id to seller and buyers	Not Supported	Current reportResult(), registerAdBeacon,reportEvent(), does not have visibility of adObject to wire deal id	Current reportWin(), registerAdBeacon,reportEvent(), does not have visibility of adObject to wire deal id.
3P notification for deal events	Not Supported		registerAdMacro does not have visibility of adObject to wire deal id

[michaelkleber]

It sounds like you're asking for a system in which the contextual part of the auction can specify a large list of possible deal IDs, and the IG can return both a winning ad and any one of the deal IDs, without any kind of k-anonymity constraint on the pair.

That doesn't seem feasible, from the privacy point of view. The k-anon part of Protected Audience is the thing which prevents an IG from carrying around an with a render URL that says exactly who I am: that ad cannot win the auction on my browser unless it is also winning on 50 other browsers.

But if you get to pass in 100 deal IDs, and your IG gets to pick the ad and a deal ID index from 1 to 100, then it would be trivial for your IG to identify me: Show this ad to 100 different people (to satisfy the k-anon check), and always return deal ID number 37 for me.

[vishnu4fledge]

Can Chrome enforce k-anonymity on deals the way it enforce it on IG and Ad, such that a deal can only win the auction on a browser if it is also winning on k other browsers?

Ads can either bid on deals or not, To enforce k-anonymity can Chrome do following:

• If an ad is not bidding on a deal, it can be allowed if it meets the k-anonymity requirements with or without deals.
• If an ad is bidding on a deal, it can be allowed if it meets the k-anonymity requirements for the deal.

One workaround is to create a separate copy of each ad for each deal. However, this would create MxN render URLs for M ads targeting N deals, which would increase the size of the Interest Group (IG) and require more processing in generateBid.

[michaelkleber]

Could the metadata associated with an ad include a list of its possible deals?

If so, then what you are proposing may be feasible, though the deal ID would have to somehow fight with the buyerAndSellerReportingId which also wants that behavior.

But if the set of possible deal IDs for an ad is determined as part of the contextual data, on an auction-by-auction basis, then it does not seem feasible.

[vishnu4fledge]

Could the metadata associated with an ad include a list of its possible deals?: Yes, we can include list of deals with an Ad while registering IG, we are also open to cap max deals per Ad.

Can we dynamically create thebuyerAndSellerReportingId in generateBid?, the deal is determined in generateBid hence to use buyerAndSellerReportingId we need functionality to dynamically create buyerAndSellerReportingId per bid.

[sbelov]

For the sake of a more generic API, what if buyerAndSellerReportingId / buyerReportingId were to be changed to be arrays, as opposed to single values specified for an ad in an interest group – such that a buyer were able to select one of reporting IDs to use during generateBid execution? That way, eligible deal IDs for a given ad could be potentially encoded into buyerAndSellerReportingId array, with generateBid selecting which one to bid on.

Ofcourse, any chosen buyerAndSellerReportingId would need to pass the K-anonymity threshold in combination with a render URL.

[michaelkleber]

I think the Stan approach (stored array of reporting IDs) seems viable, while the Vishnu approach (dynamically created) does not seem compatible with k-anonymity checking/filtering.

(@sbelov Oh hey Stan, can you please update your GitHub profile with your name and affiliation? Cannot imagine why I've never asked you to do this until now!)

[vishnu4fledge]

Stored array of buyerAndSellerReportingId and using it for deal reporting too, this is even better because it provides a generic list of ids that can be used for other use cases as well, works for us.

Just to confirm: While registering IG we can provide Stored array of buyerAndSellerReportingId In generateBid, buyer can decide a buyerAndSellerReportingId to use and wire that to seller as well as reporting events

With that, an open question:

• How can buyer set or wire a particular buyerAndSellerReportingId in events, current event reporting API does not allow any data decided at generateBid. Chrome may want to update event reporting API for this use case.

[michaelkleber]

Right, we would need to provide a place to store a list of reporting IDs (rather than a single one) and a way to pick an element of that list. So far we're just trying to check that this design would meet people's needs.

[rdgordon-index]

Stored array of buyerAndSellerReportingId and using it for deal reporting too, this is even better because it provides a generic list of ids that can be used for other use cases as well, works for us.

Question -- in this proposal, we're talking about a list of dealIDs that can original from the seller's contextual response, be passed into generateBid(), would then be exposed (somehow) in the IG data available to generateBid (much like one element of ads is visible/chosen), which would then be passed to scoreAd(), and made available to reportResult() as well?

(aside: FWIW, knowing that there actually are dealIDs, rather than a 'generic list of ids', would be useful IMHO -- but we're still validating the design)

[vishnu4fledge]

@rdgordon-index Yes. Wiring of deal to generateBid()->scoreAd() is already feasible in current API. Please see Supported and feasible use cases section in Sep 20 update.

Reporting events with deal is not feasible in current API, this proposal is to resolve visibility of selected deal in events reporting. That can be achieved by either array of buyerAndSellerReportingId while registering IG and picking one of the buyerAndSellerReportingId in generateBid() as the ID to use for reporting or any other mechanism