Multi-SSP Support

[JoelPM]

Most publishers work with multiple SSPs, so it would be least disruptive if Fledge/TD continued to support this model. It is unclear from the FLEDGE explainer how this would work. Can we please fill in the gaps at a high level?

What does it mean to work with multiple SSPs?

At a high level, it means that every SSP gets to look at all the demand it represents and place its best bid. Today, Prebid.js allows each SSP to request bids and then orchestrates the final selection between SSPs according to the business rules defined in the publisher's Prebid.js config and then GAM makes the final decision.

In a Fledge world there are several changes that need to be accommodated

1. An SSP needs to be able to select a winning IG bid from all the IG demand it has access to; and
2. An SSP needs to be able to decide between its winning contextual bid and its winning IG bid.

1. What IG Bids does an SSP have access to?

DSPs have the ability to choose which SSPs they bid through and how they bid through those SSPs. They may choose to bid with $1.50 for Campaign A through SSP and bid with $1.30 on Campaign B through another SSP and not bid at all through SSP C. The manner in which they bid may vary based on the relationship they have with an SSP and/or the type of information the SSP provides them to help value the request. They also can choose to do supply chain optimization. I believe this functionality needs to be preserved in the Interest Bid world.

Ultimately, the DSP should decide which SSPs it allows to represent its bids. This decision will be based in part on which SSPs it has a relationship with. If no relationship exists between the SSP and DSP it is impossible to represent the bid as there's no way for the publisher to get paid.

To do this, the DSP needs to know which SSP(s) are eligible to represent the publisher in the auction.

2. How does an SSP decide between its winning contextual bid and its winning IG bid?

In general, this happens by passing the contextual bid information into the runAdAuction call. The question is whether each SSP gets its own runAdAuction call with Fledge providing a means for resolving multiple calls (discussed here), or if there's a single uber-auction call that must resolve all the SSPs and DSPs connections (this is explored more here).

I think it would be cleaner to have multiple runAdAuction calls with a resolution mechanism, but either is doable.

cc @brodrigu @fbastello @sbelov @appascoe @dialtone who I've talked to about this.

[appascoe]

I agree that greater clarification on these topics is needed in the spec. Here are some of my thoughts (some of which I already provided on the call a couple weeks ago).

An SSP needs to be able to select a winning IG bid from all the IG demand it has access to

I can understand that an SSP may want to evaluate the opportunities present in the browser and make preferred selections given their relationships with the DSPs present (just as a publisher may want to prioritize relationships with given SSPs). It's come up a few times during the calls, but may be worth documenting again here, that multiple layers of scoring and selection may be required over the single scoring function present in the spec.

I seem to recall that it may be resolvable by effectively having the scoring.js (as owned by the publisher) reference and incorporate some JS from the SSPs themselves. So I don't think FLEDGE precludes a mechanism such as this, but it's a bit messy and not super transparent: it would be enormously difficult to evaluate every publisher's scoring.js to make sure it's doing the "right" thing ("right" in the sense of agreed-upon business relationships).

From the DSP side, I'd say we would care most about this functionality in the case of a second price auction; first price would allow everything to find its way into one big auction, and the final price isn't dependent upon the demand. As it works today, though, we wouldn't want to be in a position where we could second price ourselves within a given SSP, or at all really.

This is why, on the call, I advocated for making some notion of SSP and DSP as first-class objects in the browser, rather than simply fields in a JSON blob. Given the opacity of what happens in the browser, it'd be nice to have some guarantees on SSPs and DSPs not second pricing themselves. The browser could somehow enforce that an SSP and a DSP are only represented once each in the input to the publisher scoring function. (I also think these first-class objects would be useful for reporting and ensuring publishers, DSPs, and SSPs would all be guaranteed to receive the same spend data.)

DSPs have the ability to choose which SSPs they bid through and how they bid through those SSPs.

This may be controversial, but I think it makes the most sense to only generate an IG bid if there's a response that comes back in the contextual request, even if it's effectively a no-op. In this way, DSPs and SSPs can work out when a DSP should even receive a contextual request from the given SSP. Of course, the DSP can always maintain some type of publisher blocklist for a given SSP, but it would benefit both the SSP and the DSP if the SSP were to maintain this to save on bandwidth costs.

I think as far as a DSP is concerned, though, I wouldn't say we're particularly concerned with producing multiple bids for the same inventory with the same IG in the browser. I think at that point we'd leave out any SSP selection logic and instead rely on the publisher scoring.js and take whichever scores higher. I'm of the mind that this would create a good incentive within the adtech market: the higher quality and quantity of data packed in by the SSP and sent to the DSP on the contextual request should lead to higher bids, and thus correlate with higher scores on the publisher side. Similarly, DSPs that leverage these data more effectively have a higher chance of winning as well, leading to more revenue for publishers and more effective ads for end users.

[JoelPM]

Adding a link to this slide deck that captures the two different ways I think you could include multi-ssp support:
https://docs.google.com/presentation/d/1q9bES3x5NrDqR1Qa-luQrPx3LZenx3TqWu6MPrB1gYE