You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Attribution Reporting API repo has recently been updated with some details regarding aggregate reports.
While the linked document focuses on a specific use case of producing reports in a cross-domain setting (vide "attribution source context" and "trigger context"), the mechanism itself could also be used in FLEDGE for:
reporting impression-level data
technically: producing histogram_contributions from within generate_bid and triggering them in cases of a won bid
reporting click-level data
analogous to 1., but this would be a separate histogram_contributions object, triggered after a click
reporting conversion-level data
being able to dynamically produce the attributionsourcecontext parameter from within generate_bid
(optionally?) reporting lost-impression-level data
similar to 1. and 2., but triggered after a lost bid
This would address issue #93 (training of bidding models); and also potentially #164, #172.
I was wondering, is it indeed the intention to incorporate aggregate reports specification into FLEDGE?
If so, could FLEDGE work with insecure-single-server as an interim step? Or do we still need to look for another interim solution, like custom_reporting_token described in #93?
Best regards,
Jonasz
The text was updated successfully, but these errors were encountered:
Hi,
The Attribution Reporting API repo has recently been updated with some details regarding aggregate reports.
While the linked document focuses on a specific use case of producing reports in a cross-domain setting (vide "attribution source context" and "trigger context"), the mechanism itself could also be used in FLEDGE for:
histogram_contributions
from withingenerate_bid
and triggering them in cases of a won bidhistogram_contributions
object, triggered after a clickattributionsourcecontext
parameter from withingenerate_bid
This would address issue #93 (training of bidding models); and also potentially #164, #172.
I was wondering, is it indeed the intention to incorporate aggregate reports specification into FLEDGE?
If so, could FLEDGE work with insecure-single-server as an interim step? Or do we still need to look for another interim solution, like
custom_reporting_token
described in #93?Best regards,
Jonasz
The text was updated successfully, but these errors were encountered: