-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FF Ads Reporting + Ads Composed of Multiple Pieces #332
Comments
Thanks for the issue!
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? |
Yes, exactly
Actually, if the user clicks multiple times, that would also be nice to know. (I hope that doesn't complicate things too much) |
Hi, |
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. |
Can you elaborate a bit more on the focus and blur approach that you are using? Is the focus based on user's action? |
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. Thanks, |
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 More details |
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. |
Change FencedFrameURLMapping::MapInfo's ad component field from `absl::optional<std::vector<GURL>> ad_component_urls` to `absl::optional<std::vector<MapInfo>> ad_component_configs` The observable behavior should be identical after this CL, but it will enable future changes, e.g. supporting reportEvent in component ads (WICG/turtledove#332 (comment)). Bug: 1347953 Change-Id: I2775f047098e6878ea92e9bed31ac3f88fe5e74c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3914306 Commit-Queue: Garrett Tanzer <[email protected]> Reviewed-by: Shivani Sharma <[email protected]> Cr-Commit-Position: refs/heads/main@{#1050800}
Following up with the update that the solution mentioned in the above comment is being implemented. I will update here once that's complete. |
The solution here has been discussed here as part of the issue: WICG#332 (comment) The PR simply adds what was in the doc linked in the issue (https://docs.google.com/document/d/1nRkV8BEsU_JzGgq4-fXTVCeLWNxA_2Pdz2NCVpUD_W0/edit?usp=sharing) to the explainer.
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. 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! |
This change looks promising. FFAR spec is not clear about what happens upon navigation from FF (parent or component) which didn't call
|
Responses inline. Let me know if there are any questions on those.
Not really. I created a PR to add the behavior when setReportEventDataForAutomaticBeacons is not invoked.
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.
No, given (2)
No, given (2) |
Hi @shivanigithub |
Thanks! we are working on the implementation and update here once that's complete. |
fenced frames. For an ad component fenced frame, only `reserved.top_navigation` event beacon is allowed. This CL disallows invoking `window.fence.reportEvent` from ad component fenced frames. See GitHub issue: WICG/turtledove#332 (comment) To do this, this CL added a boolean field `is_ad_component_` to 1. FencedFrameConfig 2. FencedFrameProperties 3. RedactedFencedFrameProperties This flag is used in renderer to disallow window.fence.reportEvent invocation from ad component fenced frames. Bug: 1394499 Change-Id: I29fade60b7f7ca8730516bdf887fc5a7aeb74bb4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4350530 Reviewed-by: Garrett Tanzer <[email protected]> Commit-Queue: Xiaochen Zhou <[email protected]> Reviewed-by: Alex Moshchuk <[email protected]> Cr-Commit-Position: refs/heads/main@{#1126020}
The support for this landed in Chrome M115, so this can be closed now. |
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
andfocus
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
The text was updated successfully, but these errors were encountered: