Ad Server Interest Group configuration and “selectAdCreative” function

[anthony-yam-mediaocean]

Today, most large advertisers leverage a buy-side ad server and/or DCO provider to manage creative rotation and personalization. This allows advertisers to deploy ad creative strategies consistently and efficiently across multiple DSPs and directly with multiple publishers.

For a typical RTB impression, after winning an auction, the DSP writes its DSP ad tag to the page, which subsequently loads an ad server ad tag that calls to the ad server to select an ad creative to render.

In the current Protected Audiences design, the DSP appears to be the only practical "owner" of an Interest Group (IG), and the Protected Audience requires an auction to function. The ad server is not able to interoperate with the Protected Audience API, limiting ad creative capabilities.

Flashtalking would like to propose the following capabilities to maintain key ad server functionality:

1. Allow specification of an ad server-owned IG configuration. This IG would not require bidding-related parameters, only the parameters needed for ad creative selection. Importantly, the ad server could manage ad creative updates and ad components, entities that DSPs do not typically manage today and should not exclusively manage going forward.

2. Specify the advertiser domain during IG creation for clarity and to allow for connections between DSP and ad server IG configurations. (As an aside, this might also help with the “DSP shouldn’t be able to share IGs across advertisers issue”).

3. Provide a navigator.selectAdCreative() capability that can execute ad server code within an “ad creative worklet.” Within the worklet, the code would have access to Protected Audience auction IG data, seller data, Shared Storage, and potentially external ad server key-values. Similar to runAdAuction, the output gate would be one of 8 render URLs specified during IG creation.

We’d also like to propose that the selectAdCreative() function be available in non-RTB contexts. There would be much more to explore here, but this could potentially provide ad server creative selection with privacy-safe access to Protected Audience Interest Groups in any context. We could also consider allowing publishers to share privacy-safe data signals to optimize ad creative selection.

Please see this diagram for clarification:
https://www.plectica.com/maps/8KB687YEO

This is an initial draft proposal, and we realize there would be still much to work through. We appreciate your consideration and look forward to your feedback.

We believe that ad server creative selection is as important as DSP bid management and should benefit from access to a similar level of privacy-safe data for creative optimization. Advertisers could maintain critical ad server functionality that is comparable to, or potentially even better than, that of today while ensuring user privacy.

Please see these related issues:

• Protected Audience API and Dynamic Creative Optimization privacysandbox/privacy-sandbox-dev-support#201
• Interest group ownership construct missing for Third Party Ad servers whitelisted by Advertiser #924

[michaelkleber]

Hi Anthony: I think it would help me understand your proposal better if you made it clear exactly what information you wish that the DCO provider could use to manage creative rotation and personalization.

Note that every bid that comes out of the Protected Audience auction, and every ad that is shown, is currently based on information from only two domains: the domain where a person was added to an interest group, and of course the domain where the ad is going to display.

Does your proposal respect this "only one other domain" property? If not, how many different sites worth of information about the user are you proposing you can draw on?

From one part of your proposal I thought the answer was "one additional site", but from another part I thought the answer was "I want to know all interest groups", which means "I want to know all the information about every site a person visits". Either answer would be a clear change from Protected Audience's "only one other domain" design today, but "only two domains" and "infinity domains" are still pretty far apart from each other.

[anthony-yam-mediaocean]

Hi Michael, thanks for responding. Our goal would also be only to use data from the advertiser's site where the Interest Group was created and the publisher's site where the ad is being served for creative personalization. For an ad auction, the proposed mechanics would be nearly identical to the existing buy/sell worklet, but there would be no buying logic, only creative selection logic. We're not looking for more domains than what a DSP has access to in the current design, certainly not for "infinity domains!"

Specifically, for creative personalization, ad servers would benefit from access to publisher-provided data (publisher audience data, page context, etc.) and advertiser data from Interest Groups created on their site. Our advertiser ad tags only serve one advertiser, so we could provide a single advertiser domain to access Interest Group data.

[michaelkleber]

Okay, that's comforting! But in that case I'd like to really understand the gap between your needs and the Shared Storage selectURL capability.

• Real-time access to data from a key-value server? (How "real time" does your data need to be?)
• Publisher-site data? (This could be accomplished now with some unpleasant gymnastics.)
• A clean way to hook up the PA auction result to selectURL? (Of course the DSP could today use a renderURL that loaded an ad server / DCO tag, kind of like today, which could then call selectURL itself.)

This does seem somewhat strange to me since we have been discussing the SSP's role as getting to decide which ad is the winner based on knowing what the ad is, e.g. getting to pre-scan creatives and apply the publisher's brand safety controls. I don't know how to think about that job, in the world you describe, where the DCO gets to change the creative after the SSP has already made the brand safety determination.

[anthony-yam-mediaocean]

Thanks for responding.

• Real-time access to data from a key-value server? We included this as "potentially." This could probably be deferred and revisited later. Advertisers do have timely data just as inventory, pricing, timed offers.
• Publisher-site data? We'd be curious to hear how this could be accomplished in the current design. Ideally of course, it would not be unpleasant. Things seem much more pleasant for DSPs in the current API design.
• A clean way to hook up the PA auction results to selectURL? Our understanding from our Privacy Sandbox partnership team is that DSPs will register renderURLs that point to ad pages hosted by the DSP. Those pages will load ad tags from the ad server.

Regarding the SSP's scanning, brand safety, etc., as we discussed in a recent PA meeting about creative scanning, this is how the ecosystem operates today. I agree that process could be improved, but transferring all creative control and responsibility (rotation, scheduling, personalization, optimization) to the DSP doesn't seem like the right solution.

[michaelkleber]

Okay, let me ask a different question.

You describe the "Ad Server Ad Tag" / selectAdCreative() operation as something that happens after the SSP has chosen the winning bid. Why does that need to be the case? I understand that it is the order in which things happen now, because of the waterfall nature of tags writing other tags to a page. But it does not seem like an essential, or even a desirable, thing for us to reproduce.

Instead, it seems to me that the goal you are describing would be well served by a "joint IG" that did two operations simultaneously: picked a bid value and picked a render URL, but perhaps using logic from two different parties to do those two tasks. (The "bid value" would be a DSP's job and the "render URL" the DCO's job.)

And of course that could be supported in an IG today! Because right now the IG can store data and pick bids and pick URLs. The IG would need to carry around a JS function that combined logic from the bid-chooser and the renderURL-chooser, and I understand your desire for a better separation between the two. But I'm trying to understand whether that "DSP and DCO cooperate" model could achieve the desired result, temporarily putting aside the fact that you want to achieve the result with a cleaner implementation.

[anthony-yam-mediaocean]

Thanks, Michael. A "joint IG" would be a great path to explore and could resolve many existing challenges. It would also help with video, as the ad server cannot access JS and Shared Storage in the VAST environment.

Regarding the current API, it seems feasible for it to technically support current DCO use cases. However, this would necessitate strong collaboration between the DSP and the ad server:

1. The DSP that owns the IG would need to delegate the specification of ads and ad components to the ad server. Same for updateURL.
2. The DSP and ad server would need to develop and deploy joint bidding and ad selection scripts to the biddingLogicURL.
3. The DSP and ad server would need to collaborate to track ad events.

While it might be plausible for a single DSP and ad server to develop such a solution collaboratively, provided they have an amicable relationship, it would be impractical for every ad server to independently integrate with each DSP. To illustrate, imagine if the current Protected Audience API required every DSP and SSP to develop a joint buying/selling logic without establishing a standardized interface between them.

We would be eager to contribute to evolving the API to support a "joint IG" solution that would allow for DSPs and ad servers to interoperate without requiring numerous bespoke integrations.

Additionally, we remain interested in exploring the possibility of granting ad server IG access in non-auction environments while maintaining strong privacy control.

[patmmccann]

ad servers would benefit from access to publisher-provided data (publisher audience data, page context, etc.)

Prebid is filling out these data into standard places in auctionSignals, eg prebid/Prebid.js#10393 and prebid/Prebid.js#10649. I wouldn't characterize it as "unpleasant gymnastics"

You can see what we're adding to auctionSignals by calling our utility function to gather the modified auction configs we get from SSPs

If you want Prebid to add more data, please post a request to our board