Handling user's ad preference between FLEDGE and non-FLEDGE

jyasukaw commented 1 year ago

Usecase

Providing a consistent user experience in handling "user's ad opt-out preference" across different serving(FLEDGE and non-FLEDGE)

(See more details in this attached slides.)

Context(slide 2-5)

We run an ad business in Japan and deliver both direct ads(non-FLEDGE) and remarketing ads(considering implementing in FLEDGE) to our website (yahoo.co.jp). We provide a consistent user experience between them for users who want to opt out from specific ads.

When you click the "i" icon on the top right corner, it will navigate to our feedback page, then you can opt-out the ad you saw. The opt-out setting will be applied to both direct ads and remarketing ads.

Although we are considering implementing in FLEDGE, it is not feasible with FLEDGE since we cannot use the data from users’ feedback in future FLEDGE bidding.

Currently, we have a leaveAdInterestGroup() for removing an interest group from a browser. However, we think leaveAdInterestGroup() has the following problems regarding an opt-out control.

Users can still rejoin the interest group they already have left by revisiting the same advertiser's website. leaveAdInterestGroup() is a solution for temporary removal from an interest group and not permanent.
leaveAdInterestGroup() can only opt out from an interest group. When you want to opt-out all ads from a specific advertiser, you have to execute leaveAdInterestGroup() API one by one.
- For example, let's say we have 2 interest groups, "Brand A - red shoes" or "Brand A - blue shoes". When you want to opt-out from all Brand A ads, but after opting out from "Brand A - red shoes", you will still see the ads with "Brand A - blue shoes"

Proposal(slide 6-13)

New browser storage that stores users’ ad opt-out preferences data, which can only be readable through browser worklet
New APIs for writing into the opt-out browser storage
- addOptoutAdInterestGroup: Add an opt-out data to the browser storage.
- deleteOptoutAdInterestGroup: Delete an opt-out data from the browser storage.

We believe that providing consistent user experience across different serving channels is critical, because users have no idea whether the ad they see is from FLEDGE or non-FLEDGE.

Any thoughts on this proposal?

dmdabbs commented 1 year ago

Hello @jyasukaw. In today's FLEDGE call @Svenmay kindly raised this issue on your behalf. You can find notes from the discussion in the Protected Audience (FLEDGE) WICG Calls agenda and notes doc.

michaelkleber commented 1 year ago

The notes from the call are now posted in this GitHub repository, at https://github.com/WICG/turtledove/blob/main/meetings/2023-05-10-FLEDGE-call-minutes.md

@jyasukaw As you may see in our notes, it seems like there are different approaches that we can consider if we are trying to solve the problem of controlling what ads you see on the same publisher or across publishers. In your slides, the ad appears on Yahoo! JAPAN, and the feedback page is also on yahoo.co.jp. So would you be satisfied with a solution that controls ad behavior just on that site, or do you need to change behavior on other sites too?

If single-site meets your needs, then perhaps you can get this result just storing a person's ad preferences associated with a first-party cookie on yahoo.co.jp yourself. For example, suppose a person clicks on your "i" icon and that lets the publisher page learn the ad campaign that the ad was from. Then in future page views, you could block those ad campaigns in contextual ads in whatever way you wish, and you could also pass the list of blocked ad campaigns into the FLEDGE auction and use scoreAd() to ensure that ads from that campaign cannot win.

Of course if you want blocking an ad on one sight to prevent its appearance on a different site, then things are much harder because there is a risk of cross-site information leakage. In that case, the discussion in the meeting notes seems very similar to what you proposed in your slides: ad tech annotations stored in the browser, and negative filtering during the auction. But since those negative filtering rules could only apply to auctions run by the browser, I think this still cannot solve your slide 2 problem 3, "opting out from FLEDGE IG will not be shared to non-FLEDGE serving".

lbdvt commented 1 year ago

A related use case is for an Ad Tech company to honor "Your Ad Choices" DAA program (https://youradchoices.com/).

Under that program, which many Ad Tech companies are part of, a user can express the choice, through "opt-out", of not receiving "behavioral advertising" from one or several Ad Tech companies any longer.

Once the user has opted-out for a given Ad Tech company, that company:

Must not show the user any ad based on his/her web visits (neither cross-site, nor single-site visits), on any site
Can still show the user "contextual" ads (purely based on the page the user is on, the time of the day...)

This is usually implemented today through a third-party "opt-out" cookie, signaling to the Ad Tech company the user intention.

jyasukaw commented 1 year ago

Hi, @michaelkleber! Thanks for your feedback and we've reviewed the notes from last meeting.

In your slides, the ad appears on Yahoo! JAPAN, and the feedback page is also on yahoo.co.jp. So would you be satisfied with a solution that controls ad behavior just on that site, or do you need to change behavior on other sites too?

If single-site meets your needs, then perhaps you can get this result just storing a person's ad preferences associated with a first-party cookie on yahoo.co.jp yourself. For example, suppose a person clicks on your "i" icon and that lets the publisher page learn the ad campaign that the ad was from. Then in future page views, you could block those ad campaigns in contextual ads in whatever way you wish, and you could also pass the list of blocked ad campaigns into the FLEDGE auction and use scoreAd() to ensure that ads from that campaign cannot win.

We are expecting this opt-out control to change behavior on other sites as well. In the attached slide, we only showed the ad on yahoo.co.jp as an example. However we serve Yahoo! Ads on not only yahoo.co.jp, but also other domains.

Of course if you want blocking an ad on one sight to prevent its appearance on a different site, then things are much harder because there is a risk of cross-site information leakage.

We understand that the current proposed design is harder to implement due to the information leakage risk, but we are hoping the opt-out control will be implemented in FLEDGE in some way.

But since those negative filtering rules could only apply to auctions run by the browser, I think this still cannot solve your slide 2 problem 3, "opting out from FLEDGE IG will not be shared to non-FLEDGE serving".

Our detailed propsed design for the "sharing opt-out data between FLEDGE and non-FLEDGE" are below.

For FLEDGE ads
- Since a user will control the opt-out settings on *.yahoo.co.jp, we store the opt-out info on our database and use this data for non-FLEDGE ads as well.
- But, in the case we can not use 3rd-party cookie, this behavior is limited to 1st party domains.
For non-FLEDGE ads
- Run the opt-out API(which we proposed in this issue) externally on *.yahoo.co.jp and store the opt-out data to a user's browser storage. In this way, we can share to FLEDGE ads.

This design can share the opt-out info partially between FLEDGE and non-FLEDGE.

(Note that we are considering this issue "sharing opt-out info between FLEDGE and non-FLEDGE" as a lower prioirty than other problems on the slide 4.)

WICG / turtledove