Clarify the path that contextual bids take in the auction

[dialtone]

Currently the spec doesn't quite talk much about the path that contextual requests will take aside from being a separate request that happens server side.

For example:

• will those ads participate in the same auction as interest group ads?
• will those ads be rendered in a fenced frame too? (the spec says that winning ads are rendered in a fenced frame, but FLEDGE : Answering contextual requests with a generate_bid() function #116 maybe says they won't?)
• will contextual requests use the same reporting/attribution mechanisms as interest group ads?

Maybe I'm missing the bits in the spec where I could find answers to those.

[appascoe]

To add another question that could use some direct clarification:

• We've talked about contextual responses also being passed into a generateBid() function because some in-browser signals, notably frequency, can have a significant impact on what a bid should be. Would Google be open to a PR that adds this to the spec?
• It is possible that a given advertiser is running a contextual campaign where they want to explicitly prevent this campaign from advertising to users that have already been to their site. Obviously, we can't know this at contextual request time. We've also talked about in the meetings that generateBid() functions could have access to the other interest groups within the browser to modify their bids appropriately. Would Google be open to a PR that adds this to the spec?

[JensenPaul]

will those ads participate in the same auction as interest group ads?
will those ads be rendered in a fenced frame too?

I think your second question depends on the answer to the first, so I’ll answer them together. I think the first question can be answered no or yes, but I imagine the answer being no in practice:

• The contextual ad does not participate in the auction: Only the contextual bid price is passed into runAdAuction(). In this case the seller could ignore interest group bids that are less than the contextual bid. If no interest group bid beats the contextual bid, then the auction’s result is null, and the page knows to render the contextual ad, presumably in an iframe. This is how we expected contextual ads to work.

• The contextual ad does participate in the auction: The contextual bid price and ad could be passed into runAdAuction(), perhaps using something like the additionalBids argument which was recently removed (it was added for another purpose). If the contextual bid wins the auction, the contextual ad is rendered in a fenced frame like other FLEDGE auction winners. Reporting mechanisms in a fenced frame are more restricted/anonymized/aggregated than in an iframe, so there would have to be some other motivation I’m missing to go this unlikely route.

will contextual requests use the same reporting/attribution mechanisms as interest group ads?

This depends on the previous question. If the contextual ad is rendered in a fenced frame, then the answer is likely yes. If the contextual ad is rendered in an iframe, the answer is likely no.

We've talked about contextual responses also being passed into a generateBid() function because some in-browser signals, notably frequency, can have a significant impact on what a bid should be.

FLEDGE supports using some frequency information to adjust FLEDGE interest group bids. The contextual bid is calculated outside of FLEDGE and so things like Shared Storage make sense for frequency capping in this case.

It is possible that a given advertiser is running a contextual campaign where they want to explicitly prevent this campaign from advertising to users that have already been to their site. Obviously, we can't know this at contextual request time.

FLEDGE is designed to not expose information about a user’s activity on other sites, so cannot be used to block a contextual campaign. Shared Storage could be used to block such ads.

We've also talked about in the meetings that generateBid() functions could have access to the other interest groups within the browser to modify their bids appropriately.

There are downsides to giving generateBid() access to other interest groups. I talk about some here.

[appascoe]

So I can see how Shared Storage can be used to block ads or provide frequency capping. Honestly, I'm not sure of the status of that proposal as we haven't talked of it in some time, so I didn't want to presume such data would be available.

I do think it's a major problem that contextual bids happen only outside the browser. Frequency capping is one thing, but generally speaking, the value for an ad shown on repeated occasions drops. That doesn't mean you aren't willing to show the ad, just that you only want to pay less for it. The bid price can also be a function of the most recent time that you've shown the ad, e.g. there's a difference between showing the ad for the tenth time after you've done the previous nine in the last five minutes, versus the previous nine all happened yesterday. This could all be performed with data using Shared Storage, but only if the browser can perform additional computations.

This doesn't create any privacy concerns and it's pretty crucial to maintaining the overall market dynamics that we see today. This is why I'm offering to write a PR to support this functionality.

[michaelkleber]

If you want frequency or recency information to affect the pricing of the contextual bid, including affecting the decision of whether the contextual ad should beat out a FLEDGE ad, then this is exactly the motivation to justify Paul's "The contextual ad does participate in the auction" possibility.

But are you imagining that a contextual ad might hit a frequency cap and so refuse to serve at all? If so then we need a fallback ad, so multiple contextual ads are required, and we must render something. As Valentino mentioned, there is further discussion of this in #116. And indeed it goes along with requiring that the ad be rendered in a Fenced Frame, as Paul says.

[stguav]

Since frequency capping is being brought up, I'll mention this proposal: https://github.com/google/ads-privacy/tree/master/proposals/browser-frequency-capping.

[dialtone]

thanks for the responses but I'm not quite sure I see an answer to my question. I understand that there are different ways to get to a final result here, but I'm specifically asking which one we're picking: are you thinking of rendering the contextual ad in the fenced frame and having it be part of the browser auction or are you thinking of doing it differently?

[michaelkleber]

Sorry for the confusion. The answer to your question is in two parts:

1. In the design we have implemented so far, contextual ads do not feed into the FLEDGE auction and do not render in a Fenced Frame. Instead, the contextual clearing price can be used as a floor for the FLEDGE auction, and the contextual ad can be rendered in a regular iframe if the FLEDGE auction returns no results (i.e. no results that beat the floor). That's what to expect for the upcoming First FLEDGE Origin Trial.

2. There is an alternate design in which contextually-targeted ads participate in the FLEDGE auction. That design would offer some advantages — for example, the contextual ad's bid could vary based on cross-site recency information, including a hard frequency cap. But that design would have disadvantages as well — the contextual ad would need to render in a Fenced Frame, use only aggregate measurement, and so on. We haven't built this capability, but it seems like an entirely reasonable feature request that we could work on in the future, if there is demand despite the drawbacks.