This repository was archived by the owner on Nov 7, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 7, 2025. It is now read-only.
Loosening the requirement for a DSP to fire post-render tracking events on behalf of a creative ad server #1077
Description
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?
Activity
shivanigithub commentedon Mar 7, 2024
Thanks for the issue!
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?
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 commentedon Mar 8, 2024
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 commentedon Mar 12, 2024
@shivanigithub Yes, we are referring to reportEvent and the ability to call it from a nested cross-origin iframe. Thanks for your consideration.
blu25 commentedon Mar 27, 2024
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 callsreportEvent(). 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 totruewill 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.
blu25 commentedon Oct 14, 2024
It looks like updating this issue slipped through the cracks (apologies for that), but the change is in place as of Chrome M126. See: chromestatus entry
Let us know if you have any other questions.
JensenPaul commentedon Oct 21, 2024
Closing as it sounds like the issue is addressed. If you continue to have concerns, feel free to reopen or file another issue.