We are currently investigating HTTP caching to save some requests to our buyer trusted server. Since there are often multiple ad slots on the same webpage which trigger independent Protected Auction API auctions over a small period of time (a few seconds), reusing the first trustedBiddingSignals of the first auction as an input for the subsequent auctions would allow to save significant infracost and latency, which we believe is a critical topic to make client-side auctions viable in the long term.

We are using the Cache-Control response header of the trusted server request from the first auction with value private, max-age=10 to activate caching. This strategy relies on the request url being common across successive auctions, in particular having the same values for the query parameters. This is easy to ensure for the hostname, keys and interestGroupNames parameters since there are enforced by Chrome. However there is no programmatic guarantee that the experimentGroupId parameter will have a constant value on the successive auctions. In addition

1. The strategy to choose the experimentGroupId value for a buyer may vary over time depending on the AB test setup (e.g. random over the successive auctions vs constant)
2. The seller chooses the value of the experimentGroupId for the buyer in case of a parallel auction since the contextual bid response has not been received yet when providing the auction configuration (this contextual bid response is currently used by the buyer to send its experimentGroupId to the seller for sequential auctions)

We see a global trend toward moving to parallel auctions due its obvious advantage with respect to end-to-end latency. It gives us less flexibility in adapting our strategy to select the experimentGroupId value, requiring coordination with every seller and perhaps in the future even wait for publishers to update their PAAPI related code. It directly impacts our ability to implement efficiently a client-side caching strategy.

We have tried to use the No-Vary-Search response header with value params=("experimentGroupId") to exclude experimentGroupId from the cache key but internal testing showed that caching was not happening over different values of experimentGroupId. Do you know if Chrome supports this feature, in particular in the context of requests to the buyer trusted server ?

In the long term, would it be possible for the buyer to dynamically opt-in and opt-out of using such query parameters whose values are directly taken from the auction configuration ? This could be performed through a dedicated property of Interest Group, similar to trustedBiddingSignalsSlotSizeMode. At auction time, the request to the buyer trusted server would be impacted by this Interest Group property and coalescing could only happen across Interest Groups with the same opt-in behavior. Using the Interest Group update mechanism, a buyer would be able to switch from one behavior to the other in at most 24 hours.