Contextual Bid

[appascoe]

This is mentioned in the TURTLEDOVE doc, but I'd like to advocate for its official inclusion.

const contextualBid = 107;

As a possible extension to this idea, the contextual response might also contain a JS bidding function, rather than a fixed bid.

The reason for this is because it is very likely that first-ad-network.com may have written interest groups into the browser, but may also be running fully contextual campaigns for other advertisers. However, at contextual request time, first-ad-network.com is not aware if any interest groups have been added to the browser.

If no interest groups are present, a fixed bid makes sense.

If there are interest groups present, then we'd almost always want to fall back to using function(adSignals, contextualSignals) simply because it contains more data. For example, there may be a positive interaction between interest groups and the topic of the publisher. This would encourage us to submit a fixed bid of -1 to force the fallback, but this isn't possible without the knowledge.

We feel that using something more dynamic such as a contextual bidding.js file would allow us to implement logic to achieve this coordination in-browser.

[michaelkleber]

Yup, I understand why this would be desirable! But there's a trade-off here.

If the contextual bid is a fixed price, based only on information known in the publisher domain, then it's fine for that bid price to be available after the ad wins — for real-time, event-level reporting when the ad renders. That bid doesn't convey any new information, except for the one bit that we already acknowledged we're leaking: the fact that the contextual ad beat all of the interest-group-targeted ads.

BUT if the contextual bid can be affected by third-party-derived interest-group information about this user, then the bid value becomes sensitive. We can't let it become known on an event level, because doing so would make easy to use the altered bid to learn all the interest groups the user is in, and tie them to the publisher-domain identity.

So letting the contextual bid change based on interest groups means that we'd need to impose all of the aggregate-reporting overhead on contextual ads also.

(There's another problem: The contextual ad is no longer a fallback if it, like the interest-group-targeted ads, can decide it doesn't want to appear. But I can imagine ways to handle that; the trade-off with aggregate reporting is what makes this a sticky problem.)

[appascoe]

To be honest, this doesn't seem like much of a tradeoff here.

For the first part, backing out what interest groups a user is in based on the bid, while possible, seems relatively intractable for the way bidding mechanisms work today. If you're using something even as simple as a generalized linear model, backing out the weights that contributed is essentially a knapsack problem, which is NP-hard across millions of weights, and may not even have a unique solution. I suppose one could make an exceedingly simple bidding algorithm algorithm, but no one would do that because it wouldn't be competitive.

But even this is a bit of a digression. I'm a bit surprised it's under consideration that these values would not be subjected to the aggregate-reporting mechanism. Sure, 100% accuracy is better than something aggregated with added noise, but if it's substantially better, then I'd argue the aggregate-reporting mechanism is insufficient for non-contextual use cases. That is, either aggregate-reporting works well or it doesn't.

Personally, I'd rather work toward making the aggregate-reporting functionality useful and robust enough that we can apply it equally across contextual and interest-based ads.

[michaelkleber]

We will definitely work to make the aggregate-reporting functionality useful and robust enough! But of course it will require change, which is inherently harder than keeping on doing what has worked in the past.

That's why we need to allow contextually-targeted ads that retain event-level reporting. We should keep supporting buyers that don't want to get into the interest-group aggregate-reporting game at all, and let TURTLEDOVE-served ads compete against ads that never need to think about this new mechanism.

So I'll count this as a vote in favor of supporting those ads and also a new type of contextually-targeted, aggregated-reporting ads whose bids can change based on interest group info.

[appascoe]

How would requiring a contextual bidding.js function not support buyers who don't want to get into the interest-group game? Trivially, such a buyer could have the bidding.js just return a constant. Perhaps a better engineered mechanism would be to pass the desired bid in the contextualSignals object, which the bidding.js would take as input, and do with as it pleases.

I'd recommend any bifurcation of the bid submission flow. Present auction mechanisms are already difficult to reason about. Keeping everything in the same flow makes it easier to adjudicate and determine winners with greater clarity.

[michaelkleber]

A buyer who uses bidding.js would need to also migrate to aggregate reporting. I think we must still support legacy buyers who want contextual-only bidding and event-level reporting.

I'd recommend any bifurcation of the bid submission flow.

Did you mean to say "I'd recommend against any bifurcation..."? I don't see how to avoid it. TURTLEDOVE adds a genuinely new type of buying, one where you get more targeting power in exchange for some bidding and rendering limitations. I don't see how to avoid this two-types-of-bids problem, since some people will inherently not want to make that trade-off.

[appascoe]

Yeah, missed the word "against" there. Sorry.

I'm open to a transitional period where things are mixed and maybe a bit confusing. If that's the intent, ok. I'm more trying to make a comment on the final state after transitions are complete. These things could coexist, but maybe the constant bid field gets flagged for deprecation and eventual removal?

[JensenPaul]

Closing this issue as it represents past design discussion that predates more recent proposals. I believe some of this feedback was incorporated into the Protected Audience (formerly known as FLEDGE) proposal. If you feel further discussion is needed, please feel free to reopen this issue or file a new issue.