FF Ads Reporting + Ads Composed of Multiple Pieces

[jonasz]

Hi,

One of the primary use cases for FF Ads Reporting (FFAR) is to notify the buyer in case of a click event.

When the ad is "Composed of Multiple Pieces", the FFAR API (window.fence.reportEvent) is only available in the parent Fenced Frame.

When the user clicks on a nested Fenced Frame, however, the JS click event is not propagated to the parent FF.

The result is that there seems to be no clean way of reporting clicks via FFAR, if they happen on a nested FF (which is the most common scenario, as the nested FFs represent the advertised products).

The solution we're currently using is for the parent FF to observe the blur and focus events on the nested FFs. This, however, sounds a bit like a hack, and may have unintended side effects.

I was wondering, what would be the recommended way of reporting such clicks in FFAR? Would it be feasible to actually propagate the JS click event to the parent FF?

To clarify, our intention is to detect that a click happened anywhere on the ad; not to include data derived from the nested FF in the click report.

Best regards, Jonasz

[shivanigithub]

Thanks for the issue!

To clarify, our intention is to detect that a click happened anywhere on the ad; not to include data derived from the nested FF in the click report.

Is your use case such that if there is a click on any nested component ad then it should be known to the parent fenced frame and that at most only one such event needs to be known?

[jonasz]

Is your use case such that if there is a click on any nested component ad then it should be known to the parent fenced frame

Yes, exactly

and that at most only one such event needs to be known?

Actually, if the user clicks multiple times, that would also be nice to know. (I hope that doesn't complicate things too much)

[michal-kalisz]

Hi, Please note, that currently our solution (based on focus and blur events) is only working for ShadowDOM implementation of Fenced Frame. For MPArch implementation these events are not reported. I was wondering if it is by design or maybe I should report issue in chromium? MPArch impl. is now default one in OT (as well as for Fledge enabled by flag/settings), so currently our solution/hack is not working for real users. Best regards, Michal

[shivanigithub]

I am currently working out the privacy implications of the various approaches we can use to fix this and will get back with an update.

[shivanigithub]

Hi, Please note, that currently our solution (based on focus and blur events) is only working for ShadowDOM implementation of Fenced Frame. For MPArch implementation these events are not reported. I was wondering if it is by design or maybe I should report issue in chromium? MPArch impl. is now default one in OT (as well as for Fledge enabled by flag/settings), so currently our solution/hack is not working for real users. Best regards, Michal

Can you elaborate a bit more on the focus and blur approach that you are using? Is the focus based on user's action?

[michal-kalisz]

In this main fenced frame we are listening for focus and blur events; when such event occurs it is checked if document's current activeElement is fenced frame - if so, we assume that it has been clicked and then we call reportEvent. Additionally we check in small intervals if active element changes and if fenced frame becomes new active element - that situation also is interpreted as a click.

To be honest - we treat it as a temporary hack, not a long term solution. So we are looking forward for any updates.

Thanks, Michal

[shivanigithub]

Here's a proposed solution to fix both this issue and attribution reporting issue from component ads keeping in mind the current privacy model.

Summary The proposed approach allows reportEvent from the component fenced frame but only if it receives a click/transient user activation. To further reduce the amount of information leaked the solution restricts it to at most one such reportEvent among all the component ads fenced frames for a given parent fenced frame.

More details The doc linked here discusses the proposed solution and the privacy-utility aspects as well as alternate approaches that were considered. PTAL, thanks!

[jonasz]

Hi Shivani, thank you for the detailed analysis and the technical proposal. This solves this issue, as well as #281.

Of course we'd prefer to be able to report on all clicks, but we acknowledge the difficulties outlined in the doc, and we accept that event-level reporting will have to be restricted in various ways.

As a side note, the FLEDGE - aggregate ARA issue (#289) remains open. In discussing it, it would be great to work out a solution without such restrictions - but I think it's better to treat it as a separate issue.

[shivanigithub]

Following up with the update that the solution mentioned in the above comment is being implemented. I will update here once that's complete.

[shivanigithub]

@jonasz

Considering an alternative solution here which is more private than the earlier approach and based on the reportEvent changes introduced for ARA support.

From the issue description, given that the the goal is "to detect that a click happened anywhere on the ad; not to include data derived from the nested FF in the click report.", the proposal is to allow only reserved.top_navigation event beacon from a component FF. reserved.top_navigation beacons are sent when the FF click results in a top-level navigation. It is detailed in this section. Furthermore, for privacy and since no extra data is needed to be transmitted from the component FF, there would not be any additional data allowed in this beacon.

Restricting the event type to reserved.top_navigation and event data to nothing, ensures that there is no arbitrary data that can be received at the server from the component ad.

Let me know your thoughts on this. Thanks!

[maciejkowalczyk]

@shivanigithub

This change looks promising. We would like to clarify what "no additional data allowed in the beacon" actually means, though.

FFAR spec is not clear about what happens upon navigation from FF (parent or component) which didn't call fence.setReportEventDataForAutomaticBeacons but has reserved.top_navigation beacon registered.

1. Does it work as if there was an implicit call to window.fence.setReportEventDataForAutomaticBeacons? Like:

   fence.setReportEventDataForAutomaticBeacons({
   'eventType': 'reserved.top_navigation',
   'eventData': '',
   'destination': ['buyer', 'seller', 'direct-seller']
   })

2. Should the component FF call window.fence.setReportEventDataForAutomaticBeacons itself, but without eventData field?
3. Is the call to window.fence.setReportEventDataForAutomaticBeacons needed in the parent FF anyway?
4. Are event data and destinations from the parent FF used in case of navigations from the component FF?

[shivanigithub]

Responses inline. Let me know if there are any questions on those.

1. Does it work as if there was an implicit call to window.fence.setReportEventDataForAutomaticBeacons? Like:

fence.setReportEventDataForAutomaticBeacons({
  'eventType': 'reserved.top_navigation',
  'eventData': '',
  'destination': ['buyer', 'seller', 'direct-seller']
})

Not really. I created a PR to add the behavior when setReportEventDataForAutomaticBeacons is not invoked. Summary: Since setReportEventDataForAutomaticBeacons specifies the destination as well, it needs to be invoked for the automatic beacon to be sent. If not invoked, destination will be empty and beacon will not be sent. This is to give the script in the creative (representing the buyer) the chance to decide who should get the beacon (similar to reportEvent).

2. Should the component FF call window.fence.setReportEventDataForAutomaticBeacons itself, but without eventData field?

Yes, aligning with the behavior mentioned above for the main FF, the component FF should invoke setReportEventDataForAutomaticBeacons to mark the correct destination. If it contains any eventData, it will be ignored. This also helps in case the same creative can sometimes be used as a main ad and other times as a component ad. The script itself doesn't need to change.

3. Is the call to window.fence.setReportEventDataForAutomaticBeacons needed in the parent FF anyway?

No, given (2)

4. Are event data and destinations from the parent FF used in case of navigations from the component FF?

No, given (2)

[maciejkowalczyk]

Hi @shivanigithub This design looks fine with regard to collecting click notifications from ad components. I hope registering them as attribution sources will also work (see #281). When can we expect this to be implemented in Chrome? AFAIK, currently window.fence is unavailable in ad components.

[shivanigithub]

Thanks! we are working on the implementation and update here once that's complete.

[shivanigithub]

The support for this landed in Chrome M115, so this can be closed now.