Background
From the main doc, K Anon for URL Rendering is enforced not just on the creative but on the Tuple of (owner, biddingScriptUrl, creative), where I'm going to guess "creative" would resolve to the renderURL (so first question if someone can confirm that, although even if it was ad_render_id the issue I'm thinking on would still apply).

It's hard to say how frequently DSPs will want to deploy their bidding logic, as the frequency will likely be related to how much logic they decide to put into the bidding and reporting functions. One possibility we're exploring would be to try to keep the bidding function itself pretty "dumb", but I'm not sure we'll succeed in that; at this point I haven't thought of much logic to put into the buyer reporting function, seller reporting I think there may be some price resolution, but that doesn't impact frequency of change of the biddingLogicUrl.

But, however frequently they do deploy, it's possible, likely even, they will want to do some versioning with multiple versions in prod, or prod/staging/whatever, to ensure compatibility things like:

• A change to IG.userBiddingSignals structure is compatible with a new version of generateBid.
• A contextual auction signal is compatible with the particular version.
• In the case of an SSP and DSP using some protocol (either internally or through something like OpenRTB) getting the IG to the version it needs.
• There's also A/B testing, which I know there are other levers for that I haven't fully grokked yet so I'll hold off on that for now.

Deployment setups could include something where the version doesn't change often, is part of an app config, and so is not changing on every DSP Contextual Bidder deployment; but it could also be that you want to have your "Contextual Bidder App" line up with your "PaAPI Bidding App" and so desire that there be new version on every deploy. That isn't necessary, but I can see reasons teams might want to do that, in which case unrelated deploys would result in changes to the tuple.

Also let's say a deployment can be anywhere from minutes to hours.

Challenge
The challenge I'm seeing here is that a deployment that resulted in a new biddingLogicUrl would result in a reset of K for all creatives coming from that DSP, including ones with no change, meaning each Creative now has to get back to K again. With K currently at 50, this means the first 49 winning bids for that creative will be bypassed.

Trying to get a sense of the impact of that I took a simple/imperfect proxy, looking at the number of distinct creatives vs number of imps in an hour, and also the creative count * 49 since that is the number of wins that creative would have to go through to start displaying again. The numbers vary between 2.7% and 3.7% (see query below with some numbers "redacted" that I can share if need be).

Again, this isn't precise but is just meant to be directionally indicative of the issue.

Finally, I can imagine a fun theoretical that is unlikely in practice: if a biddingLogicUrl version was to be instantly deployed across all Interest Groups (i.e. dsp.com/bidding-1.0 --> dsp.com/bidding-1.1) then nothing would serve as nothing would hit K for a while. (In this case you could just deploy to the same URL, but might not want to, or be able to b/c maybe there's a prod and staging version).

"Proposal"
I'm not sure exactly what to do here. I was initially going to say have the K-Anon process allow a version parameter in the biddingLogicUrl and constrain that parameter to be an integer less than something, but I can certainly see how that opens up attacks. I don't know if we could allow for k-anon to be done on the biddingLogicUrl itself and then have that combined with an (owner, renderUrl) tuple, so the two both have to be k-anon but independently.

So, I've been thinking about this way too long, maybe I'm missing something obvious and I'll face palm, but for now I'll just say "I'd like to see a way for deployments of bidding logic to be less disruptive to creative K measurement" and for now I'll say "let's just add a small'ish integer query param that will be ignored for the creative K tuple.

Data

select ymdh as Hour, (count(distinct creative_id) * 49) / sum(imps) as PercentImpsBelowKOnDeploy from SOMETABLE where ymdh >= sysdate() - interval '30 hours' group by 1 order by 1 desc;
        Hour         | PercentImpsBelowKOnDeploy 
---------------------+---------------------------
 2023-06-28 12:00:00 |      0.030325694428750557
 2023-06-28 11:00:00 |      0.032238033710425202
 2023-06-28 10:00:00 |      0.034657536625179512
 2023-06-28 09:00:00 |      0.036066384842779339
 2023-06-28 08:00:00 |      0.034605923239306866
 2023-06-28 07:00:00 |      0.032344153791927879
 2023-06-28 06:00:00 |      0.033789860221664039
 2023-06-28 05:00:00 |      0.035021230571789399
 2023-06-28 04:00:00 |      0.034278940798184122
 2023-06-28 03:00:00 |      0.036455398260428181
 2023-06-28 02:00:00 |      0.036733613036232399
 2023-06-28 01:00:00 |      0.035984223304680108
 2023-06-28 00:00:00 |      0.037938807373984773
 2023-06-27 23:00:00 |      0.038521965067499511
 2023-06-27 22:00:00 |      0.037405716138151708
 2023-06-27 21:00:00 |      0.032852726986401520
 2023-06-27 20:00:00 |      0.028944437098990982
 2023-06-27 19:00:00 |      0.028187273766684694
 2023-06-27 18:00:00 |      0.028512300908509566
 2023-06-27 17:00:00 |      0.028858935464712514
 2023-06-27 16:00:00 |      0.028110001272252524
 2023-06-27 15:00:00 |      0.027841584374986311
 2023-06-27 14:00:00 |      0.027565488743761911
 2023-06-27 13:00:00 |      0.028340132613049315
 2023-06-27 12:00:00 |      0.029739302711551697
 2023-06-27 11:00:00 |      0.031927725961592038
 2023-06-27 10:00:00 |      0.033653095688971993
(27 rows)