Expose IG origins to the supplier

[mdavies-bidswitch]

Problem statement

The RTB traffic between SSPs and DSPs incurs hardware costs to all participants (networking and processing) as well as leads to extra CO2 footprint. Today many SSPs prefilter traffic to DSPs based on the user sync status – the knowledge of the 3P cookie ID presence for the given imp opportunity. 30%-60% traffic optimization depending on the DSP trading specifics.

With the cookie deprecation and in the current PAAPI setup such optimization doesn’t work. The SSP loses knowledge on whether the user has a DSP cookie and thus is potentially interesting for the DSP for bidding, and therefore the SSP is unable to effectively prefilter traffic for IG bidding. Unless somehow managed, this setup will result in about 30%-60% of redundant bid request and bid response traffic between the SSPs and DSPs.

Proposal

It is fair to say that the DSP is potentially interested in bidding for a given in-browser impression opportunity if there is at least one active Interest Group of theirs in the target browser. And in order for the SSP to make RTB traffic distribution decision they need to know which DSPs are potentially interested. To achieve that it's proposed to extend the bid opportunity data passed by the browser to the SSP with a list (an array) of unique origin domains of the active Interest Groups in the browser.

Privacy concerns

As no information about the actual Interest Groups is passed to the SSP (and as a result to other RTB players), there doesn’t seem to be any risks or concerns from the user privacy perspective. Yet for even a higher level of privacy we can afford to add a few ‘noise’ origins to the list, different on every request – even the salted list should be a huge help for the traffic shaping/optimization logic on the SSP side.

[itaysharfi]

Thank you for sharing your proposal. The privacy aspect is indeed a critical concern, particularly with the potential identifiability based on the set of DSPs with Interest Groups (IGs) on a device, even with the introduction of noise in the list. I'm cautious about the feasibility of providing robust privacy protection, especially when a high number of DSPs are involved in an auction and multiple calls happen over extended period of time, reducing any added noise.

I'd like to emphasize that contextual information is always available, enabling the selection of which DSPs should participate at auction definition time. While it might not encompass all the necessary details, it's a valuable resource to consider.

We are actively exploring alternative traffic shaping strategies that aim to reduce costs without compromising user privacy. Here are two potential approaches we are considering:

Clickiness Indicator:
We are evaluating the implementation of a "clickiness" or "valuable user" or another indicator at the SSP level. This indicator, shared across the entire SSP, mitigates the risk of leaking information per DSP. Utilizing this information, we may be able to implement traffic shaping strategies.

Pre-Auction Information:
Another avenue we are exploring involves providing more information pre-auction, such as the last bid for a particular DSP. This approach could offer additional insights for decision-making without exposing sensitive user-specific data. However, it's important to note that, due to privacy concerns, this information can only be provided at the remarketing call, not the contextual call.

Looking forward to your thoughts on these considerations.

[dmdabbs]

We are actively exploring alternative traffic shaping strategies that aim to reduce costs without compromising user privacy. Here are two potential approaches we are considering:

Is there an associated GH issue for these proposals?

[itaysharfi]

Hi David,

I don't recall any GitHub (GH) issues related to those suggestions. Generally, unless certain, we prefer users to open GH issues for new features.

There are other ways today to reduce traffic, such as utilizing existing contextual signals, moving data to the trusted path, implementing caching, or transferring filtering logic to the SSP.

If you are interested in discussing this topic further, I recommend bringing it up in one of the upcoming TurtleDove WICG meetings. If you believe there is an alternative feature that would suit your needs and has the potential to pass privacy review, please open a GitHub (GH) issue describing it.

Best,
Itay

[rdgordon-index]

IMO this is related to the fact that DSP on-browser auctions heavily rely on perBuyerSignals derived the contextual igbid object from the DSP's contextual bid response -- which, in turn, requires a contextual bid request -- and that's where the traffic shaping comes into play. SSPs don't know a priori if a given contextual request will be associated with a subsequent on-device PA auction where that DSP has IGs (by design) -- and hence deciding if a DSP should be sent a bid request merely to receive perBuyerSignals is complex.

[itaysharfi]

Understanding of the Problem Statement:

In the current digital advertising landscape, Supply-Side Platforms (SSPs) face challenges in effectively prefiltering traffic, primarily due to the phasing out of third-party cookies. This transition has led to an increase in unnecessary traffic, specifically in the generation of perBuyerSignals. The core issue here is the generation of these signals without clear indications of an Interest Group (IG) presence, which is crucial for determining the relevance of a user for Demand-Side Platforms (DSPs).

Concerns with the Proposed Solution:

The proposed solution, which involves using IGs as an indicator to prompt DSPs to bid on a user, raises privacy concerns. Even with the introduction of 'noise' to obfuscate the data, the solution may not adequately safeguard user privacy.

Alternate Solutions for Consideration:

1. Caching of PerBuyerSignals: This approach involves storing perBuyer signals information returned from DSPs, potentially reducing redundant data generation and network traffic.

2. Transition of Signal Generation: Moving the signal generation process from the contextual path to the key-value path could provide a more efficient way of handling these signals, aligning better with privacy concerns. Key-value is called only when an IG is present.

Can we bring this topic to our next TurtleDove WICG meeting (8am pacific time)? This use-case is not directly related to trusted servers.
@michaelkleber

[mdavies-bidswitch]

Hi is there a link to the presentation you shared at the last meeting?

[itaysharfi]

Four ways to traffic shape.pdf

Added the slides from the session. Please Let me know if you have further questions.

[dmdabbs]

Thank you , @itaysharfi .

[piwanczak]

We hold the view that, taking into account the constrained time frame, it would be advantageous if Chrome was to implement the method suggested by the original poster - enabling Sellers to know which interest group owners are present on a specific browser.
In the short term, this would serve to ensure equal opportunities for all DSPs, not just the larger ones with substantial buying power.
We are confident that at later time a good and private solution can be achieved

[EgorKozm]

@itaysharfi, I would like to second @piwanczak's comment and to stress the importance of letting the SSP having at least some signal from the browser about the bidding potential of the DSPs for this user opportunity. The list of applicable DSPs - ones that have at least one active Interest Group - would be really helpful here, so the question is whether there could anything be done to reduce the privacy concern to a satisfactory level. For example, what level of noise would be enough for us to make sure that the SSP were not able to use this signal for user tracking?

[itaysharfi]

Would you be able to share an analysis of why this feature is important compared to the alternatives? For example, would future passing of contextual data to KV that enables the fetching of additional contextual data mitigate any load concerns?

As mentioned, there are fingerprinting concerns as DSPs' IG presence data can be used as bits. I don't know of a way to mitigate those concerns to a satisfactory level but am open to input.

Regarding noise:

• Negative noise will drop DSPs from participation, so we can't have a lot of that.
• Positive noise may be problematic for smaller DSPs as it may dramatically increase their traffic.

[EgorKozm]

An important thing about traffic filtering/shaping is that it's most effective if applied as high upstream (as close to the beginning of the flow) as possible. If we look at the Bidding and Auction high level design picture as a good representation of the general PAAPI flow, we see that origin domain based prefiltering may be applied on the SSP (Seller Ad Service) side on step 2, while e.g. KVS-based optimization may only be applied on step 5 and thus cannot positively affect anything before it.

Regarding noise: I totally agree with the point about negative noise, but I don't see a problem with the positive one. Without the data that we're discussing here the SSP would have to presume that all their connected DSPs do have active IGs for this user, so the SSP would need to send the bid request to everybody, including the small ones. Having a whitelist from Chrome, even with a significant number of noise partners added, would still be a better pre-targeting solution for the SSP than not having any list at all.