Combining Auction Time Info with Private Creative Info in IFrame

Two major challenges in the PS system today include:

Getting publisher preferences into render time logic (think native, video player preferences, etc).
Getting "good" reporting out, where by good I mean something that hits enough of these spots:
- Granularity: event level, joinable to other events within the same auction
- Freshness: immediate
- Reliability: same as today, w/o noise

These challenges are of course intentional in the design of PS, but make our short-medium term (now till ~2026) adoption more challenging.

One flavor of this is the desire to get publisher side information into the rendering frame. This could include things like:

Tag ID and Auction ID for notifies.
Information on how a publisher wants a native ad rendered.
Video player preferences for the publisher.

To be clear this still does not include getting anything from the bidding/scoring process into the rendering frame or reporting functions. That would be useful but is a different issue.

This is challenging in PS because we cannot modify the renderURL that goes into the iframe (the auction framework won't even let it into scoredAd), and given that our client's TLD is not part of adnxs.com, we can't simply pass information from the top level page (pub space code) into the opaque iframe (render space code) due to the new partitioning rules.

Solutions

There are two solutions, involving different server and client side involvement, and also different levels of precision. Both solutions take advantage of the fact that our auction and render origins are the same, or at least both under our control.

Cookies set either via JS or server side by an initial call (say to SSP.pstone.com/auction) can make it through to the iframes call to the render endpoint (say SSP.pstone.com/creative) which can then inject those cookies into rendered JS for notifies, video player selection, etc.
Our code on the TLD can create an iframe per auction with some "auctionrunner" html with arbitrary query params, which will run the private auction and then create the opaque iframe which is the same origin, so the first iframe (the auction runner) can access those query params.

The first bullet has the nice property that it only requires server side interaction and requires fewer hoops. However, a challenge is what to do if there are, potentially, multiple auctions on the page vying for cookie space, as that data will not be scoped to the frame. This will be useful in some situations, but if precision matters...

The iframe approach will allow us to better encapsulate variables into a render frame. In other words, let's say in the future we run two private auctions, one with tag T1 and the other T2. Being able to inject the specific tag ID into the render frame allows us to reliably attach that data to notifies or render stylings/configurations.

NO RE ID

While this could be used for re-id, I would strongly argue it would be a violation of the attestation to do so, as it clearly involves using the output of the Fledge auction, which is one of the attested apis.

Using this to join otherwise non PII data may be OK on a case-by-case basis. For rendering, if no data leaks, it should be fine; for reporting more analysis will be needed.

IFrame Walkthrough

You can see this page's code, which creates the iframe, here.
The iframes code that grabs the data is here.
The server side code that generates the html is here.

The below live result is prepared as follows:

This page is https://www.privacy-sandbox-testing-two.com/igs/creatives-and-chips/test.html, so notably in pst-two, and in our ad tech analogy pst-two is the publisher selling ad space.
The page loads an "auction-runner" html document into an iframe from pst-one.com, so pst-one is our SSP.
The pst-two code loads the auction-runner.html with a query param indicating the tag ID.
We join a few IGs in the pst-one.com origin, so in this case pst-one is also the DSP, although that doesn't have to be the case.
Creatives are rendered out of the pst-one.com origin.
When one of the pst-one creatives wins it calls an endpoint that will create some JS that logs the creative ID as well as grabbing the location of the parent iframe, which it can grab b/c it is same-origin with the parent (note not TLD, the middle frame).
Though in this case we only do a console log, this could very well be a notify call, styling with something else injected, etc. You can see this in the console log or in the image below.

Live Result

Make sure you have the attestation over-rides in place.

See console log as well.