FLEDGE: how is publisher first party extension use case supported?

[jdelhommeau]

Hi all,

thank you for the proposal.

One thing I am not sure to understand is how will FLEDGE allow the use case desribed here (publisher audience extension):

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.

As the publisher will be the one creating the IG, it means he will be the one providing all the IG related information (bidding logic url, daily update, ads, etc.).
If so, it means the publisher will have to operate the campaign on behalf of the buyer, correct?
The use case of the publisher "selling" his first party audience to buyers over programmatic, where the buyer operates the campaign does not seem to be supported in that version of FLEDGE. That would require the ability to separate the Intest Group owner from the buying logic.

Can you confirm if my understanding above is correct, or if I am missing something and there is a possibility to support publisher audience extension with advertiser operating the campaign?

[MattMenke2]

That is correct.

In this case, either the publisher would need to be responsible for having its own bidder script (which could, e.g., run an auction itself in its generate_big method, with multiple buyers bidding, and then make make a single bid in the larger auction), or it would need to add an IG with one or more third party buyers as the IG owners (which would delegate permission to the owner to add their IGs through a .well-known file, per the explainer), and they'd make bids themselves directly and report results to the publisher.

[Aleksei-Gorbushin-at-Walmart]

@MattMenke2,
AFAIU creating an interested group (IG) by a publisher (or other user's behaviour data owner, e.g an advertiser) on behalf of a "buyer" (which is usually a DSP) has one tricky point - dailyUpdateUrl will point to the buyer domain as a IG owner.

If it is so how the user's behaviour data owner (e.g. the publisher) could "disjoin" a browser from the IG that browser was previously asked to join?

[MattMenke2]

The LeaveInterestGroup supports permissions delegation just as JoinInterestGroup does, though the buyer can deleate only join permissions, if it chooses to do so. There are no background requests to the publisher - it's not considered the owner of an IG it joins the user to in any way.

[Aleksei-Gorbushin-at-Walmart]

There are no background requests to the publisher - it's not considered the owner of an IG it joins the user to in any way.

It looks like that is the issue. Publishers in this case are the owners of the user's behaviour data.

leaveAdInterestGroup can be called ONLY when a browser visits the publisher (or advertiser) site again. The user's behaviour data owner could have a logic that is not related to site navigation (e.g. it could take into account a fact of sale events in physical stores). Being able to handle daily requests on dailyUpdateUrl enable better IG membership support for data owners.

BTW the more I dig into FLEDGE, the stronger my suspicions that this current protocol is too DSP-centric.

[MattMenke2]

These are basically modelled after cookies, and sites can't delete each other's cookies (admittedly, they can't delegate permissions to set cookies, either).

Worth noting that the publisher can set an expiration date in this scenario, and updates can't update expiration time, though that may not be sufficient for your needs.

[Aleksei-Gorbushin-at-Walmart]

Wait, you are right. dailyUpdateUrl can not update expiration time. As a result, dailyUpdateUrl cannot be used to "disjoin" browsers from interest groups "implicitly" setting joinDurationSec to 0.

Fortunately, as it was commented by @michaelkleber in #269, it can be effectively implemented with daily changes of userBiddingSignals.

There are 2 ways userBiddingSignals can be updated.

1. A browser might visit a published or an advertiser site and they have a chance to call joinAdInterestGroup with a new value for userBiddingSignals.
2. Publishers or advertisers have to share non-browsing events (iOS application activities or offline store sales) with the group owner, which is a DSP in most real cases. Data can be shared via s2s channel and the group owner could use it to redefine userBiddingSignals handling daily update requests.

IANAL but I'm afraid that the second option with such "data sharing" most probably would be defined as a "sale of data".

[MattMenke2]

An update can clear the dailyUpdateUrl and the biddingLogicUrl, which effectively disjoins the IG (Chrome still remembers until it expires, but the IG can't update or participate in auctions). The reason the expiration can't be updated on update is to prevent extending an IG's lifetime indefinitely. If there's a demand for reducing the expiration time, or just being able to leave the IG, I don't think allowing that would cause any problems.

I don't think there's an expectation that userBidderSignals would generally need to be updated by a third party. If information is gathered on the publisher's site, then they can just re-join the IG directly. If the need is to update it in response to behavior on site that's not the publisher, that would require joining user ID across sites, which FLEDGE specifically doesn't support.

[Aleksei-Gorbushin-at-Walmart]

It looks like my use case is slightly more generic than the original case where the publisher has only "online visitor's behaviour" to sell - events that require browsers anyway. Such visitors could stay anonymous.

My case is about a generic behaviour data owner. It can be an advertiser with an online store, mobile applications, and offline stores. Visitors are identifiable by the advertiser. They are customers. They have accounts. They are logged on the site and in apps and even store sales are also linked to online accounts.

Being able to update userBidderSignals only when customers "browse" the advertiser site seems too restrictive to me.

P.S. It looks like I need to describe our use case and ask for comments about a possible way to reimplement it with FLEDGE.

[MattMenke2]

It would be great if we could better understand your use case, so we could figure out if FLEDGE can support it.

Currently, the plan is even for FLEDGE daily update URLs to be k-anonymous (i.e., not per user, but per group of users), to prevent tracking. It's more intended for updating the properties of an advertising campaigns, rather than updating information associated with specific users.

More generally, we don't want updates to themselves provide any data about specific users (e.g., location, when their device is on, etc), so the current mechanisms to update are either by re-joining when they're on your site (so update doesn't depend on any information stored on their device by FLEDGE), or background updates (k-anonymous, currently only done when an auction the IG is included in is running).

[Aleksei-Gorbushin-at-Walmart]

I tried to explain our use case in #338.