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.

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.

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.

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.

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.

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.

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

Thank you all for the discussion so far. We have continued to spend a lot of time the last couple of months within Chrome and with a few of you continuing to think about how to support this critical personalization goal in a way that continues to achieve our privacy goals, specifically the same-site restriction such that decisions about what to bid and what ad to choose come from a single site from the user’s browsing history.

We have a proposal we are summarizing as the “Two Same-Site Interest Group (IG)” approach. This introduces the concept of two Interest Groups (IG) existing in Protected Audience: the Bidder IG - akin to the existing implementation - and the Selector IG, which would be the new part. Both IGs must be created on the same advertiser site, but can be created, owned, and managed by different ad tech entities.

How it would work:

Buyer IG: Continues to function as today, creating IGs when a user visits an advertiser's site. The buyer IG continues to determine when and how much to bid within Protected Audience auctions; however now there will be an option for the DSP to specify if the ad selection logic is to be executed by an Ad Selector by specifying an Ad Selector’s origin and Ad Selector-owned IG name

Ad Selector IG: Created by the Ad Selector (often a Creative Ad Server), its creation is also triggered by a user's visit to an advertiser's site. It specifies the ad selection logic URL and multiple ad candidate URLs applicable to this IG.

Auction: During the auction, the process begins as-is today: that is, the browser evaluates all DSP’s IGs and if so with what ad and bid price. Then once all bids have been placed, the SSP goes on to assess each bid for scoring. However we highlight in this proposal that at this point the SSP has access only to the DSP’s bid’s default render URL and likely the Ad Selector’s name, but no access to the final render URL that the Ad Selector will select after the SSP chooses the winning bid (see next step).

Ad Selection: After the winning bid has been selected, if the winning ad is from a buyer’s IG specifying an Ad Selector’s IG name, Chrome looks for a matching Ad Selector IG with this name that was created on the exact same advertiser site as the buyer IG. If found, the Ad Selector IG’s logic is executed to choose the final ad in its own secure environment which also considers buyer-provided metadata via the buyer’s bid invokation. If no suitable Ad Selector IG is found, the bid's default render URL is used.

Rendering and Reporting: The chosen ad is then rendered. What is noteworthy is that with our proposal the Ad Selector is the owner of the rendering URL, given it comes from an Ad Selector IG. So, the best course of action is for the Ad Selector to coordinate with the ecosystem to perform the right configurations to allow the buyer and sellers to continue to receive FFAR reports.

We welcome the ecosystem to comment on this flow so that we may develop it further and land on a workable design.

I am curious in this design at what point k-anonymity will be checked and enforced? I don't understand this can preserve privacy unless there is a second k-anon check after the ad selection is performed. Presumably when that second k-anon check fails we would expect the "default" renderUrl to be used?

I realize this is a tangential comment bc this issue began from a creative and non-DSP-but-buy side-focus, however calling attention to the fact that this proposal does not address the parallel requirement of sell-side entities, including but certainly not limited to SSPs, being able to Own IGs and then being able to delegate them to buyers/whoever.

Thanks for the write up on the “Two Same-Site Interest Group (IG)” approach, Alonso. The Flashtalking/Mediaocean team reviewed, and have the following feedback (CC @anthony-yam-mediaocean):

Flexibility and Limiting Buyer <> CAS Integration Work

1. It would be preferable to not require the DSP to know about the CAS or its Ad Selection Interest Group (IG).
2. From a privacy standpoint, it seems sufficient for the browser to maintain the winning bid's advertiser domain and ensure that only Ad Selection IGs from that exact domain are valid.

Buyer & Seller Metadata

1. It's great that the Ad Selection logic will have access to Buyer-provided metadata. Can Seller-provided metadata also be provided?
   • Buyer bidding logic has access to Seller-provided metadata within the bidding worklet.
   • This would allow Sellers to provide valuable signals for creative selection.

Shared Storage

1. Can the Ad Selection logic access Shared Storage (SS)?
   • This would be important for A/B testing and sequencing, key use cases for which SS is intended.
   • This would occur within the Ad Selection secure worklet so should not impact privacy.

Fenced Frames Ads Reporting (FFAR)

1. If the CAS is responsible for FFAR, what might the Buyer lose via this approach, including viewability, interaction and click measurement?
2. Is there a way to enable both parties to continue to report from within the Fenced Frame?

Then once all bids have been placed, the SSP goes on to assess each bid for scoring. However we highlight in this proposal that at this point the SSP has access only to the DSP’s bid’s default render URL and likely the Ad Selector’s name, but no access to the final render URL that the Ad Selector will select after the SSP chooses the winning bid (see next step).

When does the SSP get to "see" the final chosen ad's renderURL? After all, the KV metadata is intended to assist with providing scoring signals related to the actual renderURL being rendered -- if I've understood this proposal correctly, this is all being done 'post-scoring'? If so, that seems to be problematic.

Rendering and Reporting: The chosen ad is then rendered

Related to the above -- can you clarify what renderURL is being reported here, and to whom? Would the renderURL we see in scoreAd() no longer match the renderURL from reportResult()?

To minimize disruption to current workflows while protecting user privacy, we propose the following:

• DSPs continue to run bidding and ad selection in the auction worklet.
• SSPs can review each bid's DSP ad URL.
  • Visiting the DSP ad URL will ultimately lead to a Creative Ad Server (CAS) ad for review (as it does today).
• The DSP ad URL renders in the user's browser as a container for the Creative Ad server (CAS) ad (as it does today).
  • The DSP can record impressions and other activity (viewability, interaction, etc.).
  • The DSP can make requests to third party partners.
• The CAS ad code renders in the user's browser.
  • The CAS code can call a selectAdCreative function passing in the name of a CAS Interest Group (IG).
  • The browser runs a secure worklet that executes CAS IG logic to select an ad creative.
  • The worklet function returns a CAS IG ad creative URL.
  • The ad creative URL is rendered into an iframe or Fenced Frame.

This approach hopefully helps all ad tech partners to keep moving with Protected Audiences with reasonably limited effort and time while protecting user privacy.

In the longer term, perhaps in the timeframe of the Fenced Frame requirement, we can work together to develop Protected Audience APIs to more securely handle some of the DSP and CAS measurement and partner request use cases and also improve SSPs' ability to pre-review all possible ad creatives.