FLEDGE Serious downgraded performances for all acquisition campaigns due to multilevel auction incompatibility

[abdellah-lamrani-alaoui]

Hello,

We are trying to look at the FLEDGE implementation from an engineering perspective and shed some light on the “multi-level” auction known issue. Our assessment is that in the current implementation, wide-targeting campaigns (ie most acquisition campaigns) will face significant performance downgrade if multi-level auctions are not possible anymore (for header bidding at the SSP level, but also at the DSP level).

How it is working now (very simplified):

1. User visits myLocalNewspaper.com.
2. myLocalNewspaper.com notifies myAdnetwork.
3. myAdnetwork in turn notifies mySSP.
4. mySSP pre-filters some adrequests and notifies different DSPs (including myDSP).
5. myDSP, runs an internal auction for multiple campaigns and responds with the best bid computed from Interest Group Information AND Contextual information (for instance having a model as : bid= function(site, segment_variable) = 0.5 site = 123 + 0,3 user NOT in website visitors) for all its campaigns. (here we omit the “multiple bid auctions” use case where a DSP could return multiple bid in order to increase its winning chances)
6. mySSP runs in its turn an internal auction and returns to myAdnetwork the best bid among all its DSPs.

With FLEDGE, as the different actors never have the whole information to compute the full bid (interest based data + contextual data), the following steps won’t be able to be executed: _**4. mySSP pre-filter some adrequests and notifies different DSPs (including myDSP). (this issue was already pointed out: https://github.com/WICG/turtledove/issues/83).

5. myDSP, runs an internal auction for multiple campaigns and responds with the best bid (computed from Interest Group Information AND Contextual information) for all its campaigns.**_

Therefore:

• The DSP needs to send all the models (JS bidding functions) of the different campaigns.
• The SSP needs to send the models of all the DSPs.

Let’s talk numbers ! Imagine that we have:

• 5 DSPs
• 500 eligible campaigns per DSP (for a given request, most “acquisition campaigns” will actually be eligible, since user targeting will often be as wide as ‘campaign frequency < 5’ or ‘user NOT in website visitors’)
• models of the form of logistic regressions (5Ko).

Therefore, the amount of data to transit across the network would be: 5 x 500 x 5 = 12 500 ko = 12,5 Mo at each bid request (and these numbers are probably underestimated by one or two orders of magnitude in the context of DV360 or TTD for instance).

In case of no filtering, this will seriously impact the user experience ! (and thus campaign performance) In case of naive filtering (for instance each DSP randomly selects 0,1% of campaigns to answer each bid request) the scale of acquisition campaigns would be severely reduced which would translate in a need to bid much higher to deliver a given budget, and thus would drastically impact campaign performance as well. As running acquisitions campaigns will be less interesting from the buyers perspective, we could imagine a massive loss of revenue for the publishers.

I was wondering if you have given some thoughts about the subject. We would be happy @Scibids to have your current thoughts so we can help design a solution that takes into account this use case.

[michaelkleber]

Hi @abdellah-lamrani-alaoui ,

I think you're misunderstanding something about FLEDGE. The contextual response does not contain a big bundle of JS bidding functions for different ad campaigns. Instead, when a person's browser joins an interest group, the browser fetches that group's decision logic from the group's declared bidding_logic_url.

Does that improve the problem you're worried about? Or maybe I misunderstand your concern.

[abdellah-lamrani-alaoui]

Hello @michaelkleber,

Thanks for your answer, let me try to clarify and give more detail on the use-cases. To provide a little more context: Scibids is an AI company building the optimization engine for the world's largest agencies and advertisers in the “acquisition” world which represents the largest part of the global programmatic investments in the open web. Since buy-side feedback has been largely carried by leading retargeting companies (probably because they concentrate some of the smartest people in this industry!) we want to make sure the proposed solutions also allow for precise optimization of acquisition campaigns [else for instance the very large branding budgets of CPG spenders might be lost for the industry].

Our high-level concern is that it seems the original thought behind Fledge/Turtledove might have been: (i) acquisition campaigns (typically campaigns targeting 100% of users in a given country) will use the contextual bid response whereas (ii) retargeting campaigns (typically campaigns targeting << 100% of users in a given country) will use the interest-based bid response.

We identified three important use-cases which are, from what we understand, not covered by the current proposal. We present them below but let us know if you think we should open separate issues.

Our understanding is that the following use-cases are not allowed right now using only the contextual bid request:

• Use case 1: being able to use campaign frequency/recency in the bidding function, the most simplistic use-case (but not sufficient to ensure good performance) being frequency capping . (Ads from the same advertiser should not be displayed numerous times to the user in the same day).
• Use case 2: being able to use interest groups as exclusion in the targeting. (Acquisitions Campaigns should be able to target “USER NOT in website visitors”).
• Use case 3: being able to use “belonging to a FLOC” (or any interest group susceptible to be targeted by several hundreds acquisition campaigns) as an optimization variable.

However, we don’t really see how it could be done efficiently via the interest-group bid request (see details below). Again, please correct us is our understanding of FLEDGE is wrong:

Use case 1:

From my understanding, bidding according to frequency/recency would only be possible for campaigns that target a specific interest group, as the frequency data is linked to the interest group:

browser_signals: an object constructed by the browser, containing information that the browser knows, and which the buyer's auction script might want to use or verify. This can include information about both the context (e.g. the true hostname of the current page, which the seller could otherwise lie about) and about the interest group itself (e.g. times when it previously won the auction, to allow on-device frequency capping). (https://github.com/WICG/turtledove/blob/master/FLEDGE.md, 3.2)

How would an acquisition campaign with a wide target audience leverage these variables, or in the most simplistic case put a frequency capping ? (For instance not targeting the same user more that 10 times)

The only solution that comes to my mind is the following, but it doesn’t quite work. Assuming the DSP could create an interest group “users that have been shown an ad of campaign x” (I am not totally clear on whether it is possible or not), it could::

• bid an amount “b_0” in the contextual ad request. Thus, the campaign would bid b_0 on users who were never targeted (frequency = 0) and consequently don’t belong to a “frequency” interest group..
• bid an amount b_[x] on the interest-group ad request for users who were already targeted x times. However, by definition of the contextual ad request, DSP would also bid b_0 on these users via the contextual ad request.

In cases where b_[x] > b0 it would work as intended, but if b[x] < b_0 we would end up bidding b0 instead of b[x] for users with a campaign frequency of x. It would for instance prevent the DSP to perform frequency capping (equivalent to setting b_[x] at 0 when x > frequency_cap).

Use case 2:

Similarly, it does not seem possible to “negatively target” an interest group (“website visitors” for instance) since defining a bidding function (fetched in the bidding_logic_url) in which the acquisition campaign would bid 0 for this specific interest group would not really help:

• either the DSP does not participate to the contextual ad request meaning that the campaign doesn’t bid at all
• or the DSP bid b>0 on the contextual ad request, which would be the bid for users of the interest group as well.

Use case 3:

Finally, even in the “simple case” of a campaign targeting a single but frequently used interest group (FLOC or “cat lover” segment) our understanding is that several hundreds of acquisition campaigns would need to provide a JS bidding function through the interest group bidding_logic_url (as opposed to the bidding_logic_url of a “website visitors” interest group which will probably contains only the model of one retargeting campaign). Is the proposed system dimensioned to have dozens/hundreds of MB of data transiting across the network?

[michaelkleber]

The FLEDGE proposal gets some of its privacy protections from rendering the interest-group-targeted ads inside a Fenced Frame and only allowing aggregate reporting. This is an unpleasant requirement, but unfortunately it's necessary to prevent lots of cross-site data leakage.

Your use cases 1 and 2 seem like they have the same problem: They could only be supported for ads that were going to use privacy-preserving rendering (inside a Fenced Frame, only aggregate reporting). With frequency capping, for example, it would be easy to encode a unique ID based on the set of ads that were already at cap. And for negative targeting, it would be easy to encode a unique ID based on the set of interest groups.

We could certainly consider a new type of on-device ad auction, one which always used privacy-preserving rendering. There are still some difficulties, like the one you mentioned of wanting to send too many candidate ads back to the browser, but it seems plausible.

But that would mean that the auction had to exclude any ads that were not willing to do privacy-preserving rendering. I don't know how much of the ads world would be willing to make that trade-off.

(I'm afraid I still don't understand your use case 3 about FLoC.)

[abdellah-lamrani-alaoui]

Hello @michaelkleber,

Thanks for your answer. In fact, I believe that the issues mentioned above deserve separate issues. I will close this one and will open new issues with more specific titles where we could continue the discussion.