Open vishnu4fledge opened 1 year ago
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.
After reviewing all options, I found following
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 |
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.
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:
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.
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.
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.
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.
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!)
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:
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.
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)
@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
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.