FLEDGE + event-level Attribution Reporting API

[jonasz]

Hi,

I was wondering, has there been any discussion on how event-level Attribution Reporting API and FLEDGE fit together?

More specifically, I was wondering how navigational attribution sources (i.e. clicks) should be registered in FLEDGE.

1. To register a click, ARA explainer mentions that an attributionsrc parameter may be added to the anchor tag (see link).
2. FLEDGE ads will be subject to k-anonimity thresholds, and will be displayed in isolated Fenced Frames.

One implication of 1. + 2. is that the click-side data (source_event_id in ARA naming) will have a rather limited utility.

In my view, a more useful souce_event_id could be derived from perBuyerSignals (a "contextual source_event_id"):

• That would naturally fit the current design of reportWin and Fenced Frames Ads Reporting, which allow us to create a 'contextual event', and decorate it with information whether there was a click.
• With such a contextual source_event_id, we would also be able to attach coarse conversion information to the contextual event.

It seems that the problem is technical - we are unable to create the "contextual source_event_id", because FLEDGE forbids injecting any contextual information into the ad. If there was a way to tell the browser: "this is the contextual source_event_id for the ad, but make sure not to reveal it within the Fenced Frame", that would solve the problem.

Please treat this as a discussion starter, I'd be really curious if you have any thoughts on this.

// There is also the question of how aggregate ARA fits into FLEDGE, but I guess it's better to discuss it in a separate issue? It seems in the aggregate case the source registration could be based on more signals than just contextual.

Best regards,
Jonasz

[shivanigithub]

/cc @johnivdel

[johnivdel]

This was discussed in the WICG/conversion-measurement-api call, minutes here: https://github.com/WICG/conversion-measurement-api/blob/main/meetings/2022-04-04-minutes.md

To summarize my understanding/some of that discussion:

The current design for Fenced Frames Ad Reporting makes it possible to associate an id generated inside the fenced frame with contextual information . Event-level reports generated inside the fenced frame will therefore be joinable to the same contextual information on the server (using 2 server-side joins instead of 1).

The ability to join with contextual info is only given to the buyer/seller. If there are other reporters present in the Fenced Frame using Attribution Reporting, they will not be able to access this info. Even if we were able to send some kind of contextual id in these cases, it would not be meaningful except to the party which generated it. Is this an issue here?

Note that with this approach, it will not be possible to generate other attribution inputs (priority / filters) based on contextual information (only information within the fenced frame).

// There is also the question of how aggregate ARA fits into FLEDGE, but I guess it's better to discuss it in a separate issue? It seems in the aggregate case the source registration could be based on more signals than just contextual.

Agreed this is better to discuss as a separate issue. The limitation noted above will be more problematic for aggregatable reports, as you may want to ability to set aggregation keys based on contextual info.

[jonasz]

Thanks for the summary, John. The proposed FF Ad Reporting-based approach solves my original use case.

At the moment I'm afraid I'm not in a position to give any useful input on the potential issues you mentioned (third party reporters / ARA inputs based on ctx information).

For now, perhaps it'd be good to keep these questions in mind while thinking about #289. If #289 results in a dedicated FLEDGE-ARA integration, perhaps there would also be a natural way to support event-level use-case in a way that avoids these issues?

[jonasz]

As we are preparing to test ARA+FLEDGE, we realized the proposed approach of generating an id within the fenced frame is not feasible when the click happens on a nested ("product") fenced frame (when working with Ads Composed of Multiple Pieces).

The difficulty stems from the fact that reportEvent can only be called from the parent FF, whereas attributionsrc is an anchor tag parameter within the nested FF. By design, these two fenced frames cannot communicate.

I was wondering, perhaps one of these approaches could work?

1. The browser generating and providing the same random id within the topmost FF and within the nested FFs? (~window.adImpressionId?).
2. Being able to register the attribution source via JS, from the parent FF, even if the click happens on the nested FF.

@johnivdel , please let me know if any of those sounds good to you, or if you see other approaches that I've missed (perhaps ones that do not require any changes in the browser implementation?).

[shivanigithub]

@jonasz the option (2) in your comment is dependent on the solution to #332 , is that understanding correct?

[jonasz]

Actually, both of them are. (In both (1) and (2) the toplevel frame needs to know that a click on the nested frame happened, so that it can call reportEvent.)

[shivanigithub]

Responded with a proposed fix in #332 (comment)

[maciejkowalczyk]

@shivanigithub we looked over the fix described in #391 again and and it seems there is a conflict between:

• FFAR's at most one reportEvent among all the component ads policy
• ARA's selecting source that was stored most recently

Effectively, when user clicks on more than one component ad, we won't be able to join the conversion with contextual information from any of them.

Perhaps the source registration could be somehow connected to fenced frame event reporting?
E.g. via an additional parameter to window.fence.reportEvent or like this:

window.fence.reportEvent({
  'eventType': 'click',
  'eventData': '{"eventid": 123, ...}',
  'destination': ['buyer'],
  'attributionsrc': "https://adtech.example/attribution_source?eventid=123"
})

This would ensure there is only one source registered among all component ads.

[shivanigithub]

• FFAR's at most one reportEvent among all the component ads policy
• ARA's selecting source that was stored most recently

@johnivdel , @csharrison for thoughts on this.

[csharrison]

Let me restate the problem to make sure that I am understanding correctly. With the design described in this issue:

• Each component ad will generate a random ID (source event ID)
• Each component ad will attempt to use reportEvent to tie this ID to the information in reportWin
• Each component ad will use this ID as the source event ID for ARA

This breaks down because:

• Only the first reportEvent will actually work
• But the last source registration will be (by default) the one selected during attribution

As @maciejkowalczyk suggests, integrating attribution reporting with the reportEvent infrastructure could fix this. This is very compelling in that it simplifies the somewhat clunky design in this issue, and removes a server-side join. I mentioned something like this in this comment about potentially responding to ad beacons with the attribution registration headers themselves. I wonder if that could be a framework for a solution here.

[maciejkowalczyk]

@csharrison, I've missed that aggregate ARA issue you are referring to.
Your idea should indeed fix this issue for us.

My version only adds the optional attributionsrc property to the reportEvent parameter.
It could work like the one in <a>, <img>, <script> or window.open of the event-level ARA spec, including support for the empty value.
This way Attribution-Reporting-Eligible header would not need to be implicitly added to reportEvent beacons.

[csharrison]

Yeah I could go either way with what sets the Attribution-Reporting-Eligible header. I don't actually have a problem with setting it automatically on ad beacons. The reason we have an "opt-in" mechanism for the default API is to allow some level of publisher control on what requests are eligible, but I feel like starting a FLEDGE auction is enough signal that the publisher is OK with ad measurement going on, especially considering most of FLEDGE doesn't really even work without it.