Reusing current DSP server side bidding funnel even for on device auctions

[nikhilrajpal]

Is it possible for DSPs to use their current sophisticated server side bidding funnel to evaluate and send the ad-candidates as part of perBuyerSignal to be used for on-device auctions? And finally, during on-device auctions, one can think about doing an intersection of the ads defined at the IG and ads candidate returned via perBuyerSignal to finally select an ad?

This approach can help DSPs to reuse their current server side filtering logic otherwise the DSPs will have to port a lot of their bidding logic on the client side.

[michaelkleber]

I expect the answer to your question is not the same for all DSP bidding funnels.

In particular, if the sophisticated logic depends on information about the user's behavior across multiple different sites, then the answer should generally be "no". Interest Groups only have access to a single-site amount of data.

But if data about behavior on a single site is sufficient, then bidding based on information loaded from the trusted Key/Value server may make it easy to reuse existing logic.

[nikhilrajpal]

Thanks @michaelkleber for your prompt response. Just to add the required context, I am talking about bidding funnel which is currently implemented on the server side which will continued to be used for the contextual bid request. While processing the contextual bid request, a DSP can possibly return certain ad candidates(without doing any form of user targeting on server side) for on device auction as well.

A DSP's current bidding funnel may be filtering the ads on the basis of following criterias :

1. contextual information like publisher site url etc.
2. requested ad format - display/video/naitve etc.
3. various targeting criterias like geo, device etc.
4. audience targeting on the basis of 3d party cookies segments

and many more.

A DSP can think about retaining the current server bidding funnel for implementing all of above mentioned filtering except 4 and return the candidates in the form of perBuyerSignal to be used during on device auction. This could save porting a lot of logic from current server side implementation to client side.

[michaelkleber]

I'm afraid I don't really understand the flow you're talking about. The relatively-recent work on Negative Targeting, https://github.com/WICG/turtledove/blob/main/FLEDGE.md#62-negative-targeting, is all about being able to filter out contextually-targeted ads based on presence of some cross-site interest information, and that seems like what you're asking in 4. But if this isn't a good match for what you want to do, then I'll need more help understanding the situation — what information you want to use, including what site or sites it came from, and when and where you want to use it.

[nikhilrajpal]

@michaelkleber if you can check this out https://developers.google.com/authorized-buyers/rtb/protected-audience-api#serving_flow_summary

Above document explains how a server side auction happens before on-device auction. DSPs can use server side auction (also reffered as contextual bid step) to send the perBuyerSignal, and those perBuyerSignal can contain ad candidates to be used in on-device auction. These ad-candidates as mentioned above, can be prepared by doing every sort of filtering except point 4.

This approach should be doable, but do we have any thoughts from your (Google) side on this?

[michaelkleber]

I don't believe the flow you are describing works quite that way. The perBuyerSignal is indeed passed from DSP through the contextual auction flow and into the Protected Audience auction. But these signals do not include ad candidates to use in the on-device auction. In PA, the ad candidates are already present in the browser, carried around in the ads field of an Interest Group.

As I said above, Negative Targeting does allow a bit of filtering, but I'm not sure whether it is a good fit for what you are trying to do.

[nikhilrajpal]

Some DSPs can decide to include ad-candidates in perBuyerSignal and send them to the client. These ad-candidates can be decided server side on the basis of criterias like 1,2 and 3 mentioned above.

Also, during the generateBid function, a DSP can implement the logic to intersect the ad candidates obtained from perBuyerSignal and the ads mapped to Interest groups and then decide the final ad. This approach allows DSP to reuse there existing server side filtering and only move audience targeting logic to the client.

This approach should be possible theoritically unless chrome filters/modify the perBuyerSignal before they enter into generateBid function.

[michaelkleber]

Ah, I get it now! Yes indeed, if you're looking at the ad candidates in perBuyerSignals being ones that are already present in the Interest Groups on the device, this all works.

[nikhilrajpal]

Thanks for confirming the same @michaelkleber