Accessing Interest Groups from the Same Site in FLEDGE

[xxia2021]

Introduction

In the current FLEDGE proposal, the bidding function is triggered per interest group, and each interest group's bidding function does not have access to any other interest groups. This prevents targeting ads based on multi-site behavior.

However, from the privacy perspective, considering multiple interest groups joined while a person was visiting the same site should be allowed. An example use case of single-site tracking:
The user visits shoes.example/red_shoes.htm to look at red shoes, and is added to IG_visitors;
The user visits shoes.example/purchase.html to make an purchase, and is added to IG_purchasers;
The ad targets users in IG_visitors but not in IG_purchasers.

Proposal

We propose:

• The browser records the current site when joining an interest group.
• The bidding function be called per site+owner, with access to all interest groups belonging to the site+owner.

Benefits

• Easier to handle the case where the remarketing ads target more than 1 interest group. For example, an advertiser could set up ads targeting users in interest group 1 while excluding users interest group 2.
• Support the partial de-crowding so that ads from the same advertiser do not compete with each other.

Detailed Proposal

Joining Interest Group
On calling joinAdInterestGroup() API, we propose to pass an additional field in the interest group object, single_site, which indicates if the interest group should be grouped with other interest groups for this site. If the single_site field is set to true, the API will record the current site as an immutable interest group attribute. To understand what the term “site” means, please refer to this link.

Bidding Function
This would change the generate_bid() function prototype from:

generate_bid(interest_group, auction_signals, per_buyer_signals, trusted_bidding_signals, browser_signals) { }

to

generate_bid(interest_groups, auction_signals, per_buyer_signals)) { }

where interest_groups is a list of [interest_group, trusted_bidding_signals, browser_signals] tuples.

Any interest groups registered with the same_site parameter set to true will be presented to generate_bid() function together, while ones with it set to false will be presented in isolation.

[JensenPaul]

What happens when a user calls leaveAdInterstGroup for an interest group joined on another site? For example imagine site A places the user in many interest groups, then as the user browses various other sites they leave individual interest groups, then come auction time if the bidding function is called once for all groups added on site A minus the ones other sites removed, the set of remaining interest groups now represents information about the user’s activity on various sites. This is a significant change from FLEDGE as it stands now, where currently the information contained in an interest group, that is presented to a FLEDGE bidder, represents the user’s activity on only one site.

Breaking this direct correlation relationship, between one site’s information and one FLEDGE bid, may dampen a browser’s ability to protect users from ads they find disagreeable. For example, as FLEDGE is defined now, one rendered ad is the product of the user’s behavior on one site, so for the browser to prevent showing of similar ads they can prevent other interest groups added on the same site from bidding and showing ads. If however we break this one to one correspondence, the selection of an ad may be the result of the user’s activity on various sites, so potentially many or all interest groups would need to be prevented from bidding and showing ads when the user finds only a single ad disagreeable.

One potential solution would be to allow access to all interest groups with the same owner only as long as that owner has only added/removed interest groups from a single site; so calling leaveAdInterstGroup for an interest group joined on another site would result in all interest groups added on the other site to be removed. But this seems like a somewhat drastic step.

The natural alternative is for the interest group owner to instead do the work you're describing server-side. For example, have an interest group for "IG_visitors but not IG_purchasers". Just add people to it when they visit, and remove them from it when they purchase.

[thegreatfatzby]

Hey @JensenPaul sorry to resurrect this, I'm very late to this party. In trying to understand possible implementations for our SSP and DSP (Xandr), one of the things I've been zero'ing in on is the single IG per bid invocation (and also the "ad url" restrictions, but I will dig on that elsewhere). Especially given the amount of change in implementation and thinking that has gone into Fledge/PS since then, I'd be curious to hear your thoughts on what creative problem solving could be done here to allow for some kind of unification in at least some circumstances, to allow for improved performance and functionality while maintaining user expectations.

[michaelkleber]

Hi, I think you're asking this same question here and over in #207, so check out my answer there: #207 (comment)

[thegreatfatzby]

Ah yes, responded there, working on the other one, thanks.