Adding to this issue, publishers also need access to the information about clicks broken down by different dimensions, such as ad slots, page URL, PMP deal and others to assess the performance and accurately price their inventory, as well as for CPC payments from advertisers. In addition, clicks can be an important signal in detecting invalid and fraudulent traffic. Currently, SSPs/exchanges typically record, aggregate and report click events to publishers by recommending or requiring buyer partners (DSPs) to embed an exchange-specific click macro (example) into the creative code. Such macro expands into an SSP-specific click reporting URL requested by a creative when a click happens.

The FLEDGE flow does not seem to have a mechanism for a publisher or a seller network to receive click events for interest group-targeted ads: while buyers coudl in principle record clicks by embedding click trackers into the creative code rendered inside Fenced Frames, it is not clear how sellers can be notified of clicks that occur within a Fenced Frame, given that HTML code inside Fenced Frames cannot communicate with the containing publisher page.

Can a mechanism for reporting clicks to publishers / sellers be added to FLEDGE, for instance, by allowing the creative running inside a Fenced Frame to notify a seller of a click via a new JavaScript API (window.notifyInterestGroupAddClick), permitted to be used only while handling a user gesture? Can such reporting, at least temporarily, be event-level?

It seems entirely reasonable for both reporting functions (report_win() for the buyer, report_result() for the seller) to have ways to declare something that should happen upon click-based navigation. The problem is that we don't want it to be execution of arbitrary JS, since the page is going to be unloading, and we risk unpleasant race conditions if the navigation needs to wait for a bunch of asynchronous events in random different browsing contexts.

For event-level reporting, we could have each reporting function register a URL in advance, which we pass to navigator.sendBeacon(). For aggregate reporting we could do something similar.

Would those meet your needs? This wouldn't support the click notification containing information about what happened later on the device, e.g. how long between when the ad was rendered and when it was clicked, which would still be possible in the click navigation url.

It sounds like you're proposing something like:

navigator.registerAdBeacon({
 'click': {
   'url': url,
 },
});

Which can be called by report_result() or report_win()? One nice thing about this is that it could also handle other sorts of events you might want to report, such as the ad meeting the MRC viewability criteria.

While not executing arbitrary JS at click time makes a lot of sense, there are some pieces of information that are not known until the user interacts with the ad:

• How long between when the ad was rendered and when it was clicked?
• What was the total time the ad spent on screen before it was clicked?
• What % of pixels of the ad were in the viewport at the time of the click?
• Where on the ad did the user click?

This is a similar problem to AMP's situation, and they decided to handle it by allowing the URL to contain variables subject to macro substitution. Would that sort of approach work here? For example:

navigator.registerAdBeacon({
 'click': {'url': 'https://adtech.example/click?x={CLICK_X}&y={CLICK_Y}'},
});

The browser would have a list of variables that it could substitute, and would automatically evaluate the variable at click time, urlencode, and insert it into the URL.

There are also cases where the creative may want to communicate additional information on the click. The creative in the fenced frame could call:

navigator.populateAdBeaconVariables({
  'variables': [[key1, value1], [key2, value2]],
  'visibility': 'seller',  // or 'buyer' or '*'
};

The creative could call this at any point, including in a click handler, which would make the key available to url substitution in sending the click beacon.

If the visibility param contains buyer it's exposed to report_win's beacons, seller and it's exposed to report_result's beacons, and * to be exposed to both.

(Speaking from the buy side)
Our systems currently rely heavily on matching individual clicks to the impression that generated them: By seeing which impressions do or do not lead to clicks we can train ML models to bid more for an impression which is likely to generate a click.

Is there a way for FLEDGE to accommodate this use case? I.e. is there a way for us to know whether individual impressions were clicked or not?

@jeffkaufman: Yes, the macro substitution approach does seem like a good fit here. I think @shivanigithub has been thinking along similar lines.

@lcevans You can indeed know whether individual impression were clicked, but in a way that includes precise contextual information and only k-anonymous information about the on-device auction (e.g. the winning creative).

You can indeed know whether individual impression were clicked, but in a way that includes precise contextual information and only k-anonymous information about the on-device auction (e.g. the winning creative).

Will that be true even in the short term? IIUC in the short term version of FLEDGE we will have per_event logging via report_win for both contextual and on-device auction information. In which case might we also get per_won_impression information as to whether the impression clicked or not with all information as well?

That is, I think the matching of impressions to clicks is orthogonal to whether we are allowed to log per_event or only k-anonymous information about impressions? (In so far as I don't think matching impressions to clicks poses any additional privacy concerns?)

The restriction I mentioned is indeed for the short-term version of FLEDGE — check out the browser_signals available for reporting, which only provide k-anonymized information about the winning creative.

The related #93, also by @jonasz, has discussion of a custom_reporting_token, which seems related to what you're asking.

My macro example above probably should have been:

`https://adtech.example/click?x=${click_x}&y=${click_y}`

We would want to use Template Literals, since they're already part of the web platform.

This issue can probably be closed since the solution in https://github.com/WICG/turtledove/blob/main/Fenced_Frames_Ads_Reporting.md handles reporting clicks.

The issue's original use case is indeed covered. (If there are any follow ups from other participants of the thread, I guess it'd be best to create a dedicated issue.)

Thank you for solving this, Shivani!