Interest Group Update URL Frequency and Statefulness

[thegreatfatzby]

Just a question for now, but as I think through more ways we at MSFT-Ads could put the puzzle pieces together with these APIs, one creative option (meaning not just forklifting what we do now into a different execution environment) would be to have our tech run an auction at t0 and return results that would be evaluated at t1...tN "ad display time" (where tN+1 >= tN, i.e. t1 could be the same as t0). There is something like this with "video ad podding" today, where an auction runs and an "ad pod" with multiple ads is returned, and ads display one-by-one at some point in the future (I think the cutoff is 6 hours).

One way I could see doing this would be trigger an auction for an advertisers interest group, store the results as indicated above, and then at ad render time (t1 > t0 in the above nomenclature) have the SSP code evaluate that along with any other results from first-party-context or "non pod" Fledge Auctions. The DSP code could also use them at auction time if it wants to re-evaluate somehow, maybe change order or something.

To do this we would probably need a couple of things different:

• Once a day for the IG update might not be enough for many cases. In particular being able to check in with updated campaign settings, budget and pacing, more frequently, would be needed I suspect.
• The bidding function would need to be able to store it's results for later.

So I wanted to get thoughts on a) higher update frequency (I'll throw out once an hour as a stake in the ground) and b) some statefulness, managed by the browser and/or the IG code itself.

[michaelkleber]

There was some discussion in #107 of a shorter and more configurable refresh period, like 4 hours. This seems entirely reasonable, though in that case we supported the motivating use case via real-time information channels, so we never implemented shorter refreshes. If this turns out to be important to you, let us know.

I don't think I understand the statefulness that you're asking about, though. An interest group already has access at bidding time to its list of previous wins, which maybe means we already support what you want?

[JensenPaul]

In terms of statefulness, if you're imagining the N ads displaying back-to-back, I could imagine generateBid() returning a single bid with N component ads, with a top-level ad that cycles through the N component ads over time, but it sounds like you're considering repeatedly re-evaluating the ad choice over time which could be done via the previous wins list as Michael describes.

[thegreatfatzby]

Digging through docs and code to try to understand better but a few comments off the bat:

• If I'm being fair I thiiiink that the update frequency isn't entirely related to the use case I've laid out, or at least not in a way that is different from other use cases. One of the big issues with the frequency is understanding what's happening when a campaign creation/edit goes live, to see if it is working at all, or needs changes...I'm not sure why I listed that here.
• As ever this gets tricky depending on specifics but...
• ...Yes I am thinking about "re-evaluating", but I was thinking about having the bidding functions not need to do their full matching logic again and instead just re-evaluate the main thing that changes in short periods of time...
• ...one of the things you'd likely want to be able to re-evaluate at "impression" time (so I guess t1 > t0 in my above nomenclature) would be budget and pacing, which I'd generally think we get from the KV server...
• ...Capping would matter too...
• So yes being able to do it for previous wins would be helpful and would work in some "productization" of what I'm thinking, probably even in the exact "video pod" case I described.
• That said it would be interesting for the losing IGs to be able to do something similar. At least with on client auctions, being able to "cache bids" from an auction, and then pair that with marginal updates on budget/pacing/capping, could save some cycles.

I will ponder more.

[michaelkleber]

I agree that some of the ideas you're chewing on might save compute cycles, but computation re-use is a constant source of privacy leaks — probably not the best place to invest our work, with an API puts a lot of work into limiting data flows.

My intuition here is that computation re-use within a single auction seems plausible; within a single page seems like an interesting idea but subject to risky race conditions; on a single site seems like suddenly we need to worry about lots of new questions; across different sites seems like too much risk to touch.

[thegreatfatzby]

Fair, and on the cross site thing I certainly take the point, I should just add/modify one thing, I'm less concerned about the compute for the sake of it, and more because of SLAs at various percentiles and with various oddities that will inevitably occur. So I should have said something like "compute cycles and 50/95/99/999%ile SLA preservation".