Optimize Sending DSP Buyer Signals in FLEDGE

[lukewithell]

Problem Statement
In FLEDGE, demand-side platforms (DSPs) transmit buyer data to select remarketing ads on device. This data is only necessary when a user has registered interest groups (IG). The transmission of buyer data incurs substantial cost for both supply-side platforms (SSPs) and DSPs, in addition to additional network bandwidth for Chrome users. In situations where there are no IGs enrolled in the browser, buyers do not require buyer data.

Proposal
Disclosing information of whether a DSP has IG registered or not raises privacy concerns, hence we propose a safer solution: specify whether a request is PA-API eligible i.e. whether there are any interest groups registered in the browser. One way to achieve this would be for Chrome/SSP to send ‘td=0’ in the ad request. This would let DSPs know whether to send buyer data, and instead trigger the standard contextual ad flow only.

[MattMenke2]

I'm a bit confused here. DSP buyer signals are requested while running an auction. The ad is only requested after the auction is completed. How would sending td=0 on the request for that ad at the end of an auction (an ad which had to come from a DSP in the first place) help with loading the signals at the start of the auction? I'm clearly misunderstanding.

[michaelkleber]

Hi @lukewithell: The one-bit signal that you're asking about, "are there any IGs on this device?", actually is something possible to learn today, if the browser is in the Bidding & Auction Services origin trial currently operating on 1% of Chrome stable traffic.

As @itaysharfi pointed out in his presentation on the topic early this year, the getInterestGroupAdAuctionData() API used by the Bidding & Auction server returns a blob of data whose size varies depending on the size of of Interest Group database. We've taken pains to make sure the size of the blob doesn't return much information, but it does let you tell the difference between a browser whose IG database size is zero vs nonzero.

Of course building the whole B&A blob is a lot more work for the browser than just checking whether or not there are any IGs around. So if this does turn out to be a valuable piece of information, even on pages where B&A is otherwise not being used, then we should consider a cheaper way to answer this question. But I hope this is enough for some investigation of whether there is real benefit here before we build a whole new API surface around it.

[rdgordon-index]

Indeed, getting the rough size of the blob (a proxy to IGs on device) available outside of B&A is something that I've long been interested in...

[dmdabbs]

Underscoring @rdgordon-index and expressing interest.

[lukewithell]

Thanks Michael, DV3 is very interested in implementing this optimization. We have also had significant interest from SSPs and other DSPs.

To aid with implementation, we had a few questions:

1. Can you please confirm this is the best function to determine whether there are interest groups registered in the browser?
2. Additionally, when checking the size returned by the function, what threshold should we use to determine there are no interest groups?
3. Are there any potential performance concerns using this function in the browser?
4. What percentage of FLEDGE requests do we expect to have this function available as part of the Bidding & Auction Services origin trial?