Loosening the requirement for a DSP to fire post-render tracking events on behalf of a creative ad server

[anthony-yam-mediaocean]

In the current design, post-render tracking can only be initiated from the Interest Group (IG) owner's domain. These provide direct-from-browser reporting on any user-triggered events, such as views, viewability, or clicks.

To track such events, a creative ad server would need to coordinate closely with each DSP to pre-register beacons ahead of the auction or develop a postMessage communication mechanism with the DSP. Both would be cumbersome and require currently non-PA-supported bespoke integrations.

It would be preferable to loosen the restriction and allow the creative ad server to track its own events. Could a list of allowed tracking domains be configurable?

[shivanigithub]

Thanks for the issue!

In the current design, post-render tracking can only be initiated from the Interest Group (IG) owner's domain. These provide direct-from-browser reporting on any user-triggered events, such as views, viewability, or clicks.

To clarify, with post-render tracking, we are assuming you mean the reportEvent(custom destination URL with substitution of preregistered macros) calls which are currently only allowed in the renderURL frame or any nested iframe which is same-origin to the renderURL frame. Is that correct?

It would be preferable to loosen the restriction and allow the creative ad server to track its own events. Could a list of allowed tracking domains be configurable?

And the feature request is to allow reportEvent(custom destination URL with substitution of preregistered macros) to be available in nested cross-origin iframes.
Additionally, note that the destination url in this reportEvent() variant is already restricted to be from an allow list of origins declared in the IG which are required to be enrolled.

[nbwray-work]

DV360 has use cases where reportEvent(custom destination URL with substitution of preregistered macros) is fired x-origin, so consider this a +1 to this feature request.

DV360 has some creative types where the assets are rendered in an iframe that is x-origin to the render URL, but we'll still use registerAdBeacon/reportEvent to fire the impression ping from the inner frame.

So we'd also like Chrome to remove the x-origin restriction for reportEvent using preregistered destination URL.

[anthony-yam-mediaocean]

@shivanigithub Yes, we are referring to reportEvent and the ability to call it from a nested cross-origin iframe. Thanks for your consideration.

[blu25]

We've discussed this internally and have a design that will work with your use case.

We're proposing adding a new response header, Allow-Cross-Origin-Event-Reporting=true, for the root ad frame to allow reporting metadata to be used if a nested cross-origin subframe calls reportEvent(). This will only need to be added to the response header of the document loaded into the root ad frame (i.e. the frame that was created as the result of an ad auction).

The cross-origin subframe will then call reportEvent() with a new optional boolean parameter: crossOriginExposed. Setting this parameter to true will opt the subframe's event into using cross-origin reporting metadata, and the beacon will be sent out.

Let us know if this works for your use case.