Publisher creating interest groups

[TheTamFamily]

In the FLEDGE MD - https://github.com/WICG/turtledove/blob/main/FLEDGE.md it says that the Publisher can also create interest groups:

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.

How does the auction work, more specifically how would the buyer bid for this audience?

My understanding is as follows:

1. When a user lands on the Publisher website, the Publisher executes joinInterestGroup.
2. Publisher / Seller somehow informs the buyers that there is this interest group that they could bid on. Not entirely sure how this piece works.
3. The Publisher / Seller initiates runAdAuction.
4. Authorised buyers will need to have added the interest group and keys to their KV server.

Questions:

1. Since the interest group contains information such as renderUrl etc ... that can only come from the buyer how would the Publisher create the interest group?
2. How does the buyer know what interest groups to add the KV server?

My question is unltimately how would a buyer bid on an interest group that is created by the publisher?

Thanks

[TheTamFamily]

Could someone provide a response to this issue. Thanks.

[TheTamFamily]

This is partly linked to #1191

The technical proposal is:

Buyer operates a KV service that is similar to the Seller. In the Seller auctionConfig object of the runAdAuction() function there is an attribute named “trustedScoringSignalsURL”, when a Key Value call is made by the scoreAd() function, the response is:

`{ "renderURLs": {
https://cdn.com/render_url_of_some_bid: arbitrary_json,
https://cdn.com/render_url_of_some_other_bid: arbitrary_json,
...},
"adComponentRenderURLs": {
https://cdn.com/ad_component_of_a_bid: arbitrary_json,
https://cdn.com/another_ad_component_of_a_bid: arbitrary_json,
...}
}

The Publisher creates the Interest Group (IG) and in this IG include a new attribute named for example “sellerDefined” with value “true” or “false”. This will inform the worklet to retrieve the relevant creative from the trustedAdSignalsURL. The request to trustedAdSignalsURL will include the combination of keys that are found in the attribute renderKey (renderKey replaces renderURL), trustedBiddingSignalsURL, biddingLogicURL and updateURL attributes. trustedBiddingSignalsURL, biddingLogicURL and updateURL would also need to be retrieved from the buyer’s KV service at auction time. In the IG object these are also keys.

`const myGroup = {
'owner': 'https://www.example-dsp.com/',
'name': 'womens-running-shoes',
'lifetimeMs': 30 * kMillisecsPerDay,
'sellerDefined': 'true',
'priority': 0.0,
'priorityVector': {
'signal1': 2,
'signal2': -3.5,
...
}
'prioritySignalsOverrides': {
'signal1': 4.5,
'signal2': 0,
...
}
'enableBiddingSignalsPrioritization' : true,
'biddingLogicURL': ...,
'biddingWasmHelperURL': ...,
'updateURL': ...,
'executionMode': ...,
'trustedBiddingSignalsURL': ...
'trustedAdSignalsURL': ...
'trustedBiddingSignalsKeys': ['key1', 'key2'],
'trustedBiddingSignalsSlotSizeMode' : 'slot-size',
'maxTrustedBiddingSignalsURLLength' : 10000,
'userBiddingSignals': {...},
'ads': [{renderKey: key1},
{renderKey: key2},
{renderKey: key3 }],
'adComponents': [{renderURL: runningShoes1, sizeGroup: 'group2', ...},
{renderURL: runningShoes2, sizeGroup: 'group2', ...},
{renderURL: gymShoes, sizeGroup; 'group2', ...},
{renderURL: gymTrainers1, sizeGroup: 'size4', ...},
{renderURL: gymTrainers2, sizeGroup: 'size4', ...}],
'adSizes': {'size1': {width: '100', height: '100'},
'size2': {width: '100', height: '200'},
'size3': {width: '75', height: '25'},
'size4': {width: '100', height: '25'}},
'sizeGroups:' {'group1': ['size1', 'size2', 'size3'],
'group2': ['size3', 'size4']},
'auctionServerRequestFlags': ['omit-ads'],
};
const joinPromise = navigator.joinAdInterestGroup(myGroup);

Since the renderURL is subject to k-anon having a key ought to enable the worklet to check the number of joins with the same key.

When an auction is initiated, the steps are:

1. Retrieve the buyer’s KV service for SDIG (renderURL, trustedBiddingSignalsURL, biddingLogicURL and updateURL).
2. Retrieve the buyer’s KV service for bidding data from trustedBiddingSignalsURL.
3. Buyer runs generateBid().
4. Seller runs scoreAd().

[TheTamFamily]

Another proposal would be for the seller to create a skeleton IG that is suggested in this ticket #1191 and the buyer to update all other attributes for the IG including the renderURL etc ...

[rdgordon-index]

This was discussed on today's WICG meeting as well -- one of the many challenges I see is that this isn't provisioning, this is delegation -- the publisher loses control over the IG as soon as it is created.

[dmdabbs]

Yep. If you are a publisher that has DSP capability, great, you can retain control. Otherwise, like today, you have to delegate and trust some vendor to report on and compensate you fairly for ads delivered on other sites to "your IGs" created on your property.

[michaelkleber]

Good discussion of the issues here in yesterday's call. Notes at https://github.com/WICG/turtledove/blob/main/meetings/2024-07-10-FLEDGE-call-minutes.md#david-tam-seek-feedback-on-proposal-for-how-seller-can-set-interest-groups-for-buyers-to-bid-on---httpsgithubcomwicgturtledoveissues1196

[TheTamFamily]

Asking another tech vendor such as a DSP to create IGs on behalf of publishers does not seem like a viable solution technically and commercially. The main reasons are:

1. Every DSP will be placing tags on the publishers' websites. Besides the numerous tags, this does seem to be contrary to the spirit of privacy and competition.
2. This would explode the number of IGs.
3. Advertisers would have to seek an agreement with each publisher.
4. If we buy seller defined IGs from Prime Audience (RTB House) who are a buyer then are we effectively creating a supply chain where a buyer buys from another buyer.

Unless I'm mistaken the key challenge is k-anon where certain attributes have to be k-anon at creation time. If we can address this, is there any reason why publishers (sellers) cannot create IGs and let buyers bid in an RTB PA auction.

[michaelkleber]

David, the problem isn't just the k-anon timing, it is the question of what logic produces the bids. An IG's fundamental job is to produce bids using the on-device JS bidding function generateBid().

It sounds like you are proposing that even the buyer's JS bidding logic is only provided at the moment of the auction — so the audience creator presumably runs some kind of internal auction to decide what buyer is going to get a chance to buy, then the browser learns about a whole new bidder, creates a new worklet, loads that bidder's JS, and so on. So this flow would probably double the duration of the auction; you would be kicking off a whole new auction flow only after the existing flow got to the bidding stage. (This is just one of a host of problems with your proposal — for another example, it would also remove the control that sellers have today over which buyers they allow to participate in their auctions.)

I still don't understand why you think that this collection of transactions (from publisher perhaps to a sell-side ad tech and then to a buy-side ad tech) should happen in the middle of the auction. I'm happy to explore the desire for audience creators to get some kind of additional reporting and maintain some kind of additional control over the use of the audience, as we discussed in the call this week. But everything about the creation of the bidders should definitely happen long before an auction begins.

[kzoltowski]

Glad to hear about additional efforts and discussions related to audience delegation. We (as Prime Audience) see there's significant interest and concern from various stakeholders that aren't being fully addressed. So far it seems like solutions around this concept are being dismissed without thorough exploration. We believe there is a way to satisfy this use case without sacrificing PAAPI privacy protections. We expect Google to collect more input from other market vendors to develop a reasonable solution together. We've already submitted a list of interested companies in such an undertaking to the Privacy Sandbox team. Additionally, there are numerous related issues, such as #898, #418, and #338, that have reached dead ends, showing that this is not an isolated concern.

Google, in their recent blog post regarding Privacy Sandbox, has stated:
"We’ve heard feedback from advertisers and agencies that they’ll be ready to run campaigns through Protected Audience once it’s supported by their key vendors. This includes measurement, verification, data management, and audience companies whose solutions play a critical role in enabling digital ads to be transacted on the web."
Despite this, the current PAAPI setup doesn’t sufficiently address the needs of data activation and audience vendors, ie. Publishers use CDP/DMP vendors like Permutive or 1plusX for audience creation, yet the current setup forces a shift of these capabilities to DSPs or expects CDP/DMP vendors to become DSPs themselves. This approach isn't feasible and negatively impacts the publisher's revenue by removing potential revenue sources through data monetization or activation. The same goes for advertisers activating their data on multiple platforms which requires them to create interest groups with the same definition, multiple times.

Based on what was written here, I would also like to clarify that Prime Audience is a separate entity, aiming to provide advertisers with the possibility to activate audiences across any DSP. The proposed buyer-to-buyer workflow isn't a viable solution for us either, and we would like to contribute to a solution that addresses these concerns.

Delegation shouldn't be seen as an insurmountable issue. The main challenge with one of the possible solutions seems to be latency, as Michael pointed out:
"So this flow would probably double the duration of the auction; you would be kicking off a whole new auction flow only after the existing flow got to the bidding stage."
This indicates that added latency is the issue, not the use case itself. To sum up, we recommend gathering input from all relevant vendors to refine and implement a solution that supports the diverse needs of the ecosystem with PAAPI privacy protections at its core.

[TheTamFamily]

Michael, can we dedicate some time to addressing this Use Case as there is considerable interest from both sell and buy side to make this work. It is in line with the original concept of TURTLEDOV, FLEDGE now PAAPI that Publishers can create Interest Groups and sell this in an open PA auction.

[anderagakura]

After reading this case, the meeting notes and a few issues, I have a naive question regarding the idea of allowing a publisher to identify every user's browser to the right audience and help a buyer to target it :

• Why not using a deal mechanism? (e. g. Change perBuyerSignals in generateBid() and reportWin() to JSON objects #1232 (comment) from @dmdabbs )

Pros :

• No extra JS in the pub page
• Can be limited in time and removed from auction logic

Cons :

• Less automatic than planned in this issue
• Publisher and SSP will have to talk with buyers to share info about deals

[michaelkleber]

Alexandre, are you reacting to the discussion from last Wednesday? I don't understand how you're thinking about using a deals-type infrastructure to help with either of the needs David Tam was asking for.

[anderagakura]

@michaelkleber I'm just wondering if adding process and JS for Publisher creating IG to inform buyers about the audience is close or far from using Deal pipes and add value as I think the buyer might not clearly know how the audience are categorized for example. I'm just thinking, trying to understand the full landscape

[michaelkleber]

@anderagakura I agree that these ideas are interrelated. My sense is that any time the "Audience Creator" and "Audience Buyer" are two different parties, the AC needs to package up and communicate to the AB some information about the audience in question, and "deal ID" is one industry-standard (or at least standard-ish) mechanism for doing that.

(I guess we could describe the potential flow that we discussed last week as the AC saying to a bunch of potential ABs "I have an opportunity to add a person to my deal-id-123 for you". Hmm: and from that POV, maybe some of the misalignment in our phone call was that the operation I suggested was essentially "add this particular person to my deal-id-123 audience for you" — which is perhaps a strange concept for people who are more used to "I want to show my ad to your entire deal-id-123 audience"?)

The Deal ID mechanism could well be useful for knowing, at reporting time, that a particular ad was indeed shown via the AC's deal-id-123 audience. And whether with or without Deal ID, audience use of this sort may require a new reporting channel so that the AC learns about the use directly, whether or not the AB chooses to tell them.

I think there is still a hard open question of how the AC can retain some control over the ways the AB uses the audience.

[TheTamFamily]

I thought it is best that I break this down into a number of discreet Use Cases without prescribing any technical solution:

1. The Seller (Publisher or SSP) creates and owns the IG.
2. The Seller shares a list of IGs to Buyers with some context on the IG prior to the auction.
3. When the user appears on the Seller's website the Seller runs the auction (inviting Buyers from the list in the interestGroupBuyers attribute).
4. The Buyer (Advertiser or DSP) bid for these Seller owned IGs. Since the creation of the IG contains no biddingLogicURL or ads --> renderURL as at the time of creation we do not know who will bid, therefore is it possible to insert bidding logic and ads at auction time.

If we can address the above Use Cases, then Seller can own their IGs and invite Buyers to bid in an open auction. While I do not speak on behalf of Publishers, this could be great for them as they can get the best price from an open auction, Buyers can reach more potential customers. It also means that Publishers do not need to rely on any identifiers (1P or 3P) like we would need today to target Publisher audiences. For some Publishers they may not have many 1P identifiers and 3P cookies do not have the same utility that it had.

[appascoe]

I don't know why you would need an IG to do what you just described. The seller can just maintain hashmap of 1pcs to associated segment names. When the user is on the seller's site, read the 1pc, grab the segments by doing the lookup in your hashmap, and package them into the contextual request and send it to the buyers you want.

[michaelkleber]

@TheTamFamily Now I'm confused. In the very first comment when you started this issue, you described the goal as:

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.

But in your last comment, you said

3. When the user appears on the Seller's website the Seller runs the auction

I think this gap is the reason for @appascoe's comment also. None of this work is necessary when a person is visiting the seller's own website, it's only when you want to create an audience of people visiting one website and then use that audience when those people are on a different site.

[rdgordon-index]

If in (1) it is the SSP, then in (3) user isn't visiting the seller's website, but rather the publisher's website.