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.