FF Ads Reporgin - iframe support in FOT?

[jonasz]

Hi,

As we are working on analyzing FLEDGE performance during the first Origin Trial, we are looking for a way to identify which ad impressions resulted in a click. (Effectively - "we've gotten a call from reportWin, was there a click event later on?".)

Longer term we are planning to rely on Fenced Frames Ads Reporting ("FFAR") to satisfy this use case.

In FOT1, however, ads are rendered in iframes, and it seems FFAR is not available there. I was wondering, would it be possible to enable it, temporarily, in iframes as well? (Despite the "FF" in the name :) )

Best regards,
Jonasz

[JensenPaul]

@shivanigithub might know if this is possible

[shivanigithub]

Yes, window.fence.reportEvent is only available inside opaque-ads mode fenced frames currently.
I think temporarily allowing it in an iframe that was created using a urn:uuid mapped url should be fine. Let me check with the team and update back here.

[gtanzer]

@jonasz Should be doable. We have a mostly done CL for it here: https://chromium-review.googlesource.com/c/chromium/src/+/3690741

For implementation convenience, window.fence.reportEvent would only work when invoked from the iframe that was actually navigated to a urn:uuid (the equivalent of the fenced frame root). I hope/imagine that should be fine as a temporary solution. There's some elaboration in the CL description.

The behavior is the same within fenced frames.

[jonasz]

Thank you all for the quick response!

For implementation convenience, window.fence.reportEvent would only work when invoked from the iframe that was actually navigated to a urn:uuid (the equivalent of the fenced frame root).

Note that as a buyer (DSP), we do not always control how the iframes are created on the publisher's site. I will confirm with our SSP partners if using an URN works for them, and will let you know as soon as I have an answer.

[jonasz]

Hi, just wanted to circle back to confirm that we will indeed work with URN-based iframes. I hope using deprecatedReplaceInURN doesn't break the functionality.

I was wondering, is there any chance this change will be deployed (cherry picked?) to the beta channel sometime soon?

[gtanzer]

It should be fine to use deprecateReplaceInURN; it looks like it just overwrites the relevant fields and copies the rest of the mapping over:
https://source.chromium.org/chromium/chromium/src/+/main:content/browser/fenced_frame/fenced_frame_url_mapping.cc;l=315

We're working on getting it into M104 Beta on June 23.
https://bugs.chromium.org/p/chromium/issues/detail?id=1337323

[gtanzer]

It got merged into the M104 (Beta) branch today. So it should be live in Beta in the next update (within a week), but I'm not sure of the exact release schedule.
https://chromium-review.googlesource.com/c/chromium/src/+/3721476

[jonasz]

Great to hear, thanks!

[fhoering]

@gtanzer @shivanigithub
Sorry to comment on the closed ticket. We made some tests and the FF reporting API doesn't seem to be available from inside an iframe rendering. It works well from inside a fenced frame but not from inside an iframe where the window.fence property is not set.

We tried injecting the adUrn from the auction result directly into the iframe or calling deprecatedURNToURL before. Both renders but the window.fence property is not set.

 let adFrame = document.createElement('iframe');
 adFrame.src = adUrn;

 let url = await navigator.deprecatedURNToURL(adUrn)
 let adFrame = document.createElement('iframe');
 adFrame.src = url;

Can you a have a look if there is anything we are missing ?

It seems important to support the FF report APIs for both iframe and fenced frames because the buyer doesn't have any control on how the ad is rendered and some sellers might start of with iframe rendering and only then move to ff rendering.

[gtanzer]

Which Chrome version are you running? (not that there should be a problem with any version; just curious)

Also, are you definitely calling window.fence.reportEvent from the "root iframe" (i.e. the iframe that you navigated to the urn?)

[fhoering]

I tested on the GAM test pages https://fledge-testing.uc.r.appspot.com/?nid=allow_all with latest Chrome 109.

Also, are you definitely calling window.fence.reportEvent from the "root iframe" (i.e. the iframe that you navigated to the urn?)

I don't call it from the root iframe because of the round trip to detect the ad size. So it is called in the child iframe. That is the reason then.
Is there something we can do about that ? I would expect this information to be propagated as it is done from inside the fenced frame.

[fhoering]

If there is an API to retrieve the URN and propagate it to the child frame I can also do that.

[gtanzer]

I'm not sure I understand why the round trip to detect ad size motivates calling it in the child frame. I think reportEvent should currently work in the "root iframe" after same-origin navigations, but never in subframes of that frame.

We would like to support the API in all contexts where it makes sense; it's just an implementation issue. (The notion of a "urn iframe root" doesn't exist right now in the same way as "fenced frame root", but that can be fixed.) And it's been lower priority to support it in iframes, because you can just talk to the embedder if you really want to.

Until the size API changes (#417) are live, (or alternately until we finish some refactors that tidy up availability of APIs like reportEvent, e.g. https://chromium-review.googlesource.com/c/chromium/src/+/4086285), would it solve your problem to do the following?

• Substitute the ad size into the urn using deprecatedReplaceInURN, so there is no need to wait to detect the ad size.

[fhoering]

I'm not sure I understand why the round trip to detect ad size motivates calling it in the child frame. I think reportEvent should currently work in the "root iframe" after same-origin navigations, but never in subframes of that frame.

In theory it is possible for the display yes but it doesn't work for the click. They main motivation for implementing this is to measure clicks as the displays can already be measured by reportWin.

because you can just talk to the embedder if you really want to.

It would require seller/buyer cooperation because the embedder is the seller and the creative is displayed by the buyer. Not sure this is the way to go even if it stays temporary.

Substitute the ad size into the urn using deprecatedReplaceInURN, so there is no need to wait to detect the ad size.

It would have to be done by the seller. @sbelov Any input ? If possible it could be a workaround.

[gtanzer]

We made changes that I believe should fix this, for M112 (i.e. you can test it on Canary right now, or Beta once it releases on March 9).

I'm not sure that we have test cases for this exact situation (an iframe nested inside a urn iframe), but we do have tests separately for urn iframes and iframes nested inside fenced frames. Could you take a look at your tests and see if it's working now?

One detail is that reportEvent will only work in contexts that are same-origin to the mapped url in the urn. The intent here is to prevent other origins from sending unauthorized reports. Please let us know if this is a problem.

[fhoering]

It looks fine in Chrome 112 Canary with urn iframes. Thanks for the fix.
The same origin restriction is not an issue as the events are registered on the same bidding and tagging origin.

[gtanzer]

Glad to hear that it's working for you.