In FLEDGE, the rendering URL is required to pass k-anonymity checks. In some cases, however, an ad might be rendered far more times than k-anonymity would require. Could we send that excess entropy to the server to support experiment diversion?

Consider a rendering URL, https://ad.example/creative/1234. Say this is a really popular ad, one shown to millions of people daily. Its owners would like to experiment on it, tweaking it to be more performant, and they would like their experiment to be sticky. They could run a rendering-diverted experiment (#149) but that would only be sticky as long as the response remained in the browser cache, and could have bias if the arms were different sizes. They could manually shard their URL into https://ad.example/creative/1234/a and https://ad.example/creative/1234/b, randomly assigning users to one or the other, but this is awkward and they don't know how many shards will keep them above the k-anonymity bound.

If the browser knows this rendering URL is being shown to U users, where U = K * 2^N, that is, 2^N times as many people as K-anonymity requires, it can safely send N = floor(log(U/K)) bits of entropy on the request to the rendering URL. For example, at N>1 (U>2K) it could send an Experiment-Entropy request header:

GET https://ad.example/creative/1234
Experiment-Entropy: 0

Another user might send Experiment-Entropy: 1. At N>2 (U>4K) it could start sending another bit: Experiment-Entropy: 10.

Experiment entropy would internally be a stable integer per (URL, user) pair. The browser would only send the N most significant bits. This keeps users from shuffling between treatments when the available entropy changes, as long as there is still sufficient entropy.