Interest Group Deal Phase: Allow Deal Eligibility by IG, Require Deal ID K-Anonymity

[thegreatfatzby]

Initial Note
I think there are a few use cases here and doing something more abstract could be good, but let me start with one motivating case and solution, and then wave my hands at something broader.

Background
Ad Tech has a general concept of a "Deal", where a buyer and seller agree to some special parameters of buying on the sellers inventory, typically for things like preferential pricing, access, and ranking, and to also allow details to be hidden through a "package", i.e. the deal could be for "People Likely to Buy Tennis Stuff in the Next 10 Days on Sports Inventory", but without revealing the details of how that is determined, at least not programmatically. This is not an exchange/ssp/dsp specific concept as it is accounted for in the OpenRTB specs, although individual Ad Tech's may offer their own spin or value ad.

Some relevant details include:

• Typically between 1 seller and 1-or-more buyers.
• A deal is said to be "eligible" on a request if it's targeting parameters are met, which can include a combination of "contextual*" targeting (in particular inventory), user targeting, and capping (same as a creative).
• May, often I think, involve cross-contextual data.
• Can include more than two parties at auction time through "curation".

As currently stands we can determine some set of eligible deals in the Contextual Auction and pass them through in the auctionConfig.auctionSettings for buyers to target (preferably via OpenRTB structure as indicated elsewhere :) ).

The main Fledge doc seems to contemplate the multi-party example:

A publisher (or a third party working on the publisher's behalf) might create and own an interest group of people who have read a certain type of content on their site. Publishers can already use first-party data to let advertisers target their readers on the publisher site. A publisher-owned interest group could let publishers do the same even when those people are browsing other sites. Publishers would presumably charge for the ability to target this list.

however it's not clear to me from the docs how that would happen.

Challenge
As alluded, I believe deal eligibility will be limited to data available in the 1st Party Context. For inventory filtering this meets current functionality (pretty sure), but there is functionality loss on user targeting in cases where the eligibility would have been determined based on data not available in the 1st Party Context.

Proposal
There's a lot of details we'd need to figure out but I'll stick with a medium level of detail that I think can motivate the idea and discussion, and if we go in this direction we can flesh out more details.

The idea is to allow a way for IGs to target "deals" and pass that information on to other IGs in a way that takes advantage of existing deal interop but still with K-anonymity constraints.

1. Add a new optional function to the IG, generateDeals(), same arguments as to generateBid() which will return a list of deal objects containing an ID and list of buyers, in our case IG owner domains, that can target it. (I'll generally say have the format correspond to OpenRTB, something something).
2. Add a stage to the auction in between runAuction() and the calls to generateBids(), in which any IG with IG.generateDeals() is first filtered using the same mechanics as currently indicated for IGs, and if unfiltered runs.
3. Apply K-Anon counting and restrictions to any returned Deal IDs; any that fail get their counter increased but are ineligible for the current auction, any that pass also get the increased counter but are determined eligible.
4. The auction code routes any eligible deals into other IGs generateBid call via a new browserSignals.eligibleDeals, filtering the IG.owner against the deal's eligible buyer domains.
5. The generateBid function can include a targetedDeal element in the ad.
6. If the deal is targeted and won by an IG (via ad.deal_id), a reportResult call is made to the owner of the IG that produced the deal.

If need be we could require that an IG has either generateBid or generateDeals but not both. It could also make sense for there to be a specific reporting function that could be invoked, reportDealWin, but we might just be able to use existing functions. There might need to be a deal owner origin in returned deal object from generateDeal, need to dig on that more. Let's start here.

Callback to Initial Note
Going a bit wider with this, the ability for IGs to interact with each other more (although not infinitely) would be very powerful from an Ad Tech's perspective. Deals is one major existing case, 3rd party data is another, and depending on how far you went with IG Dependency Management, you could see buyers and sellers doing interesting matching. I don't want to couple this proposal to a broader "IG Dependency Management" system, I think there's enough to discuss with this one "little" case, but want to call it out as a thought.

[michaelkleber]

I admit I don't yet fully understand this use case. My initial reaction is the same answer that I gave you in #207 (comment):

We're still remaining as conservative as feasible when it comes to Protected Audience data sharing: the bidding for a particular ad is based only on (1) information about the user's activity on the site where they were added to the Interest Group, and (2) information from the site the ad is going to appear on. Combining IGs joined across different sites would change that model.

If you don't think that answer is a good match for this question, then my apologies, and we should probably discuss this in one of our Protected Audience phone calls so that we can boil down the flow to its essentials.

If you do think my answer matches your question, and what you're really proposing is a way to loosen the "only two sites" stance without giving away arbitrary web-wide profiles, then I'm interested in understanding more, but please know that this is not going to be a short-term priority — we expect to be focused on functionality within the privacy boundaries we've already established, rather than on expanding those boundaries.

[thegreatfatzby]

I think it might be all of the above, meaning in short:

• I think it's a good match in most ways.
• I think it's worth discussing at least a little because of the ways in which it doesn't match.
• But I suspect what I'm proposing would loosen the model as you say in a way I hadn't realized.

Privacy Model
Would definitely like to understand the core tenets of the privacy model better (is there a place that is stated? I could have sworn I saw one and now can't find it), but while it was not my intention to stretch the model, given your statement re 2 parties, then yes I would be. Is the "2 parties" boundary a core piece of the privacy model (in the same way that partitioning, k-anon, dp, etc are) or is that a second level boundary that has been chosen on top of the core model (to be clear in no way criticizing, jus trying to understand.

Mostly Good Match
I do want to make one important differentiation between this what was discussed in #207. I reviewed and was reminded that, initially, it seemed like I was asking to essentially co-mingle the userBiddingSignals between IGs in different contexts, when what I meant was co-mingling the userBiddingSignals between IGs in the same context. In this case there would not be co-mingling of userBiddingSignals or any other IG property, but it would bring in 3rd party and allow "co-mingling" in a more indirect way via the deal id. I believe with K-Anon applied to the deal ID it would still match what I understand to be the core privacy model, but as stated above I don't understand those perfectly yet so want to learn more there.

Further Discussion
I would really like to discuss further on a PATCG call if we can, but I suspect we'll wind up in the position you discussed.

[thegreatfatzby]

No need to respond, putting a note down for future reference after some internal discussion, I think we'd have to have a k-anon check of the combination of deal ID and then the creative URL.