Trusted Bidding Signals response size constraints when requests are coalesced

[tylerdev0]

The Key Value API Explainer describes that there is a 2MB size constraint on responses from the Trusted Key Value server. This 2MB size limit is applied across all keys such that the total size of the response for all keys returned from the trusted server cannot exceed 2MB.

This seems like a reasonable size limit for a single interest group, however it becomes unclear how this constraint could be applied when Trusted Bidding Signals requests are coalesced across multiple interest groups with the same trustedBiddingSignalsUrl.

As the Fledge explainer describes "The [Trusted Bidding Signals] requests may be coalesced (for efficiency) across any number of interest groups that share a trustedBiddingSignalsUrl (which means they also share an owner)."

If the Trusted Bidding Signals requests were limited to a single interest group, then it would be easy for the Trusted Server owner to understand the size constraint for a single key's value: 2MB / number of keys per interest group.

Once an unknown number of IG's keys are coalesced into a single request we can no longer accurately assess a size constraint on a per-key basis to ensure that all of our key's values can fit within the 2MB limit. If we exceed the 2MB limit for a response keys are dropped at random which means we, the DSP, lose control over how we are participating in auctions.

Some possible solutions to this problem could be:

1. Prevent the browser from coalescing requests and make a single request per IG.
2. Apply the 2MB limit on a per Interest Group level rather than the total response size.

I'd be interested in hearing what could be done to address this problem in Fledge.

[peiwenhu]

we can no longer accurately assess a size constraint on a per-key basis to ensure that all of our key's values can fit within the 2MB limit

Could you clarify this a bit? Is your assessment an offline process where you need to make the decision out of the critical serving path, or an online process where you make the decision during serving?

I'm asking because I think a likely way forward is to still apply 2MB limit on the response but let the processing logic know how much their share of limit is per interest group: 2MB/number of IGs

[tylerdev0]

Hi Peiwen,

Yes, our assessment is an offline process. We want to be able to answer the question "How much data can be returned from the trusted server per interest group". More specifically we'd like to know how much data we can afford to store on a per-key basis in the trusted server. We know internally how many keys we'll include in an Interest Group so knowing the size limit per IG would give us that answer.

The problem is that we don't know how many Interest Groups will be participating in a single auction and therefore can't estimate what 2MB/number of IGs is.

[peiwenhu]

I see. Ultimately one of our major goals is to not overwhelm the resources on the device. The possible solutions that you suggested both challenge some constraints on the device. On the other hand, if the caller is the bidding & auction server, we may have more relaxed constraints. For the device-facing API, we'd have to take some time to evaluate this problem and potential directions.

[tylerdev0]

That makes sense. Thanks.
Perhaps a reasonable solution would be to allow Advertisers to specify a maximum number of interest groups that we are willing to have participate in an auction. Similar to a seller's perBuyerGroupLimits but set by the buyer.