Using Interest groups as exclusion list

[rodolpheAV]

Hello,

I've been reading the explainer and compared it with the previous PIGIN proposal an I think there is a missing use case in the new proposal.

This proposal enables retargeting strategies in a privacy way, but today, for a lot of our ad campaigns, we are actually using third party cookies to avoid retargeting web users. This would not be possible with Turtledove.

I understand the move from PIGIN to TURTLEDOVE to ensure privacy concerns and groups correlations witch could lead to malicious identity analysis. As far as I undestands, this explainer ends with two separated worlds :

• Retargeting ad campaigns which can use multiple user groups to provide their bid
• contextual / segment targeting ad campaigns which can use contextual and FLOC data to provide their bids (but no access to user groups)

My question is : as an advertiser, what could I do to run contextual (or FLOC targeting) ad campaigns and ensure that I only provide my ads to new users ? This means that I would like to exclude bidding on any users with an interest group comming from my website.

This is particulary important for advertisers willing to focus their ad budgets on new customers, and also for web users who could end with more ad pressure from an advertiser if they get retargeting ads + contextual (or segement targeting) ads from the same advertiser at the same time.

The information "this user has already saw my website" should not be considered as a data leakage as hundreds of thousands users fall into the same large group. We would actualy not need to ad users to groups but only to flag users from the advertiser website and be able to use this generic information during the bidding process.

Any thoughts about this use case ?

Rodolphe

[michaelkleber]

Hi, thanks for describing that use case.

This proposal enables retargeting strategies in a privacy way, but today, for a lot of our ad campaigns, we are actually using third party cookies to avoid retargeting web users.

When I read this at first, I thought your goal was a way for the advertiser to ask a browser to leave an interest group (e.g. "stop showing me the ads for those shoes once I've bought them"). That seems entirely reasonable, with a JS API whose semantics are "I don't know whether or not this browser is in this interest group, but either way, please don't be on it."

But then I got to the crux of your question,

as an advertiser, what could I do to run contextual (or FLOC targeting) ad campaigns and ensure that I only provide my ads to new users ?

As you say, this isn't what TURTLEDOVE was designed for. I can think of two approaches that are somewhat related to what you're asking:

1. The publisher's site is able to know about stuff that happens on that site, including any outbound links that are clicked on. (This doesn't require any new capabilities, it's just the web as it works today.) So once a person clicks on one of your ads on a site, it would be fine for first-party-cookie-keyed data to exclude your ad from showing to that person on that site in the future.

2. Maybe one click isn't enough, you actually only want to stop targeting people who have bought something. In that case our Click Through Conversion Measurement Event-Level API could fit the bill: Once a person clicks on one of your ads on a particular site and that click converts, you could exclude your ad from showing to that person on that site in the future.

Both of these suggestion are very strongly tied to which site the ad is being shown on and was previously clicked on. I don't see a privacy-preserving way of lifting that constraint. As the Explainer says, one of the key privacy goals is

• Web sites cannot learn the interest groups of the people who visit them.

It seems like keeping your contextually-targeted ads from showing to everyone in your interest group would go against that.

[rodolpheAV]

Hello,

Thanks considering this use case, and sorry if my explanation has been unclear.

Limiting the exclusion to specific websites where an ad has already be clicked would have a really limited impact regarding the number of users & domains on the web and the current Click Through Rates. So I don't think this would fix in this use case.

After considering

Web sites cannot learn the interest groups of the people who visit them.

And digging a bit your on device auction mechanism, I think there is actually a way to handle this issue.

As far as I understand, the aim of TURTLEDOVE is to ensure that the web server will never get in the same bid requests user groups & contextual informations

• With the interest-group bid requests : interest groups are sent to the server, a partial bid response is generated by the server and the final decision/price is made in the browser based on contextual signals
• With the contextual bid requests : contextual data are sent to the server, a full bid response is is generated by the server

But we could change this behavior to provide a symmetrical treatment :

• In the contextual bid requests : contextual data are sent to the server, a partial bid response is generated by the server and the final decision/price is made in the browser based on interest-group signals

This is actually what you described in the explainer with :

As a possible extension to this idea, the contextual response might also contain a JS bidding function, rather than a fixed bid. This may be useful if there are any other user-specific signals that are available in the browser but not in the server, which could then be made available to the various on-device bidding functions without compromising privacy.

Enabling this feature would fix this issue : as an advertiser, I can run a campaign dedicated to target new customers only. I would generate a bid response based on contextual bid requests (without any user groups sent to my server). I would include a JS bidding function in my bid response. This function would be executed in the browser, receive the user groups for my domain and then ajust the bid price or avoid placing my final bid.

I can see these pros :

• the use case is fixed
• the outcomes of the original explainer are respected
• the bidding is much more symetrical this way. An advertiser would always be able to use contextual data and interest groups to generate a bid response. Based on his buying strategy, he can choose one of the two bid requests and therefore derfine whatat kind of data would be processed on the server and what kind would be processed on the browser

And this cons :

• It would be impossible to keep a server side auction strategy, even for contextual ads as the final prices are only knwown inside the browser. (But finally isn't it easier to manage a single auction in the browser instead of multiple layers of auctions ?)

[michaelkleber]

You're quite right that your use case would be helped by serving the contextual ad with a bidding function (rather than a fixed bid), which does seem feasible. The question of whether a person has previously visited your site is indeed the sort of "user-specific signals that are available in the browser but not in the server" that I was thinking about when I wrote that.

But if I understand correctly, your approach would also need the contextual auction to send multiple ads back to the browser with the hopes that at least one of them would be willing to be shown to this particular person. Then either the server sends lots of ads on each pageview, which is resource-expensive, or it sends few ads, and runs the risk of browser-side no-fill.

I guess you were imagining the "lots of ads" approach, and this is what you were getting at by saying "It would be impossible to keep a server side auction strategy". But forcing all of the auction into the browser would be a much larger and more difficult migration.

I'll keep thinking about other approaches for this use case. Maybe we could support a larger in-browser auction eventually, if a lot of the ads industry wants to move in that direction. But it seems to add a lot of cost, given the state of the world right now.

[michaelkleber]

Upon further reflection, the "few ads" approach is growing on me, as long as we can avoid the "no-fill" outcome.

How would you feel about a generalization in which:

• The interest-group request/response works as currently described;
• The contextual-and-first-party-data request/response requires one ad with a fixed positive bid value, as currently described;
• The contextual-and-first-party-data request/response also allows a small number of optional ads:
  • between zero and (say) 2 optional ads are allowed;
  • optional ads must come with a JS bidding function that get access to some TBD on-device signals;
  • optional ads must be able to render in the privacy-preserving way we're going to need anyway.

I'm not yet entirely sure this is safe — we might need to require the one fixed-bid ad to also support privacy-preserving rendering, to avoid leaking interest group memberships to the page. But something like this might be feasibly adoptable and meet your use case.

[michaelkleber]

In a remarkable bit of timing, @eriktaubeneck just posted a proposal for Private Exclusion Targeting Rendered Exclusively Locally ("PETREL"), which at first glance has very large overlap with my previous comment.

Erik is proposing a declarative way for ads to opt out of showing to someone, while the JS bidding function here is more general, and might re-order ads rather than just drop them. These approaches seem equally plausible to me, so a natural question is whether the additional generality and complexity of the bidding-function approach offers benefits.

Erik, I'm delighted that you're thinking about the same question and coming to similar conclusions. Please take a look at this issue, especially in case I'm missing any differences between your and @rodolpheAV's use cases?

[rodolpheAV]

I was actually thinking of a basic "lots of ads" approach, where all the bidding would have been transfered to the browser.

I agree this would cost more resources which is one of the challenge of the TURTLEDOVE pattern anyway (I may create a specific issue to discuss about performance concerns as it may be a challenge even in the current version of the explainer).
I also agree this may be a big challenge if the whole industry is forced to implement the js bidding function which complicates the bidding flow (even if it gives more flexibility).

I was thinking about the "few ad" approach before you posted your last message and I arrived at a slightly different option :

• The interest-group request/response works as currently described;
• The contextual-and-first-party-data request/response requires one ad with either :
  • a fixed positive bid value, and no js bidding function
  • a js bidding function able to access on device signals

This way the ad network would be able to run a server side auction between all the response containing a bid value and elect one of them and would then send it to the browser with all the responses including a js bidding function (as their bidding price would be unknown).
Then the browser would run its own auction including

• interest group responses (generating their final price with their js bidding function)
• the ad network elected ad with a known price
• the other contextual responses (generating their final price with their js bidding function)

This would reduce the migration complexity for actors who would prefer to generate their bid only on the server side and reduce the ressources needed. However if a lot of contextual responses comes with a js bidding function we get close to the "lots of ads approach".

Anyway let me just take a look at your proposal and the PETREL Proposal (Thanks for the pointer !)

[eriktaubeneck]

@michaelkleber this is quite the remarkable timing, and I'm disappointed I missed the issue in the first place! I generally agree with the points of how this might work. We were also attempting to lay out the simplest "base case" in our explainer, so we didn't even get into the idea of a "bid" but rather just an "ordered list", but this is a fairly trivial distinction and both could easily work.

@rodolpheAV would love to see what you think of the solution proposed in PETREL. In general, we were trying to keep the explainer simple, so instead of a js bidding function, we just did "pick the first ad that's not excluded, otherwise the fallback". This could definitely be extended, but the privacy complexity grows each time we make such an extension, hence our focus on starting simple.

[rodolpheAV]

@eriktaubeneck for sure your explainer is really close to the use case I was discussing here. Good to see that this is a global concern !

About the granularity :
The main limitation of your proposal applied to my use case is the granularity of the exclusion lists, but this is something you identified in your explainer. My concern was about creating an advertiser wide exclusion group, but your focus on products is interesting as most of the retargeting companies would be interested by the product level and it's good to provide them with an easy way to achieve it to get an industry adoption.

Adding at least a website granularity would be needful and the category granularity would also be nice for very large and diversified advertisers. A potential challenge about the website granularity would be if a specific advertiser runs its activity on multiple domains (but this could also be a concern for turtledove interests group globaly).

You also state :

When a conversion happens within a browser, the advertiser can store the relevant product_id privately in the browser as an "exclusion group"

My use case was about excluding a user from ads, not only based on their conversions but also on other signals (like a simple visit of a specific domain) I can imagine that the explainer could be adapted to match this granularity too.

About the sorted responses list
It is a really close concept to my last message proposal where the ad server returns a list of potential ads and the browser manage the auction (in your case a selection of the first matching ad). Your default ad is also really similar to the ad network elected ad from the responses defining a bid price I was speaking about.

The simple concept of an ordered list has some advantages I like :

• It's easier to declare an exclusion directly in the response rather than defining a Js functions (resulting on a larger adoption of the feature)
• It would be easier for ad network to optimize the responses weight sent to the browser as the bid price is known from the ad network, the ad network would only have to send the default ad + the ads containing a potential exclusion only if their price is higer than the default ad (saving ressources compared to my proposal where the ad network would need to send all the potentialy excluded bid responses)

On the other hand my Js bidding functions proposal's main advantages are the flexibility it gives (as you can provide advanced pricing strategies in the function, not only exclusion), and the symetry in the treatments of the two turtledove responses.

[eriktaubeneck]

My use case was about excluding a user from ads, not only based on their conversions but also on other signals (like a simple visit of a specific domain) I can imagine that the explainer could be adapted to match this granularity too.

We considered this, though admittedly on a final review, and concluded there's no reason why this wouldn't work for this use case. A "conversion" doesn't have to be a purchase, and the advertiser website is in full control of when they would invite a browser to join an exclusion group.

The use of product_id is probably a bit misleading, but we didn't have a good alternative, and, for the simplicity of the explainer, decided to keep it as is.

I opened an issue on the repo containing PETREL to discuss improving the naming.

[rodolpheAV]

You are right this is related to naming to express the granularity of the group.
I'll comment this issue.

What are your thoughts about the sorted response list vs the local bidding javascript function option ?

[JensenPaul]

Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into #319. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.