Consider increasing trigger_data bit amount

[arielhal]

Hello,
Currently trigger_data size is limited to 3 bits (8 distinct values) when registering a trigger for event-level reports.
We would like to know what is the reason for such a strict limitation? and if it's possible to add few more bits to this value?
Many of our customers have more than 8 conversion types, and such limitation will prevent us from giving our customers a precise evaluation of their performance.

Thanks!

[csharrison]

Hello @arielhal , the reason the size is limited to 8 distinct values is to ensure that the amount of cross-site/context information about a user is limited. This is especially true for event-level reports, because they come associated with a high entropy identifier that links a report to the specific ad engagement.

I have two suggestions:

1. Look into the API's support for aggregatable reports. With these, you can make different tradeoffs about the amount of "conversion-side" information embedded in a report.
2. Consider taking a look and providing feedback on this issue: Feedback requested on utility with event-level reports' privacy params #694. In particular, I've linked a calculator into that issue which will also explain the amount of noise needed to satisfy (one of the) privacy bars we have in the API, based on varying parameters like the trigger_data cardinality.

[csharrison]

Hello @arielhal I also want to bring your attention to a document we recently published that allows you to trade off bits with other parameters in the event-level reports. Please take a look:
https://github.com/WICG/attribution-reporting-api/blob/main/flexible_event_config.md

I believe this should satisfy the feature request if we move forward with the proposal, can you confirm?

[arielhal]

Hey @csharrison !
Sorry for the late response, it looks good!
Can we define a trigger_data to be in the range of [0, .., 10] for example instead of the default [0,...,7]
What will be the impact? Where will other bits be reduced? Or will it just add more noise?
Also, where do we send the trigger_spec? in each trigger event to the browser?
Is there any estimation for when this feature will be available?

Thanks!

[csharrison]

Can we define a trigger_data to be in the range of [0, .., 10] for example instead of the default [0,...,7]

Yes this is possible

What will be the impact? Where will other bits be reduced? Or will it just add more noise?

There are impacts on noise, you can find a script here:
https://github.com/WICG/attribution-reporting-api/blob/main/flexible-event/flexible_event_privacy.py

To test your question, you can invoke this way python3 flexible_event_privacy.py -m 3 -b 3,3,3,3,3,3,3,3,3,3 -w 3,3,3,3,3,3,3,3,3,3 which essentially configures the API to have 3 conversions per click, with 10 possible trigger_data values, each with 3 maximum conversions and 3 reporting windows. Note that this increases the "information gain" total bits by ~1 so our simple mechanism described here would cause this to be a failure since it regresses one of the privacy metrics. If you reduced to a total of 2 maximum conversions it would be within limits for navigation / click sources.

Also, where do we send the trigger_spec? in each trigger event to the browser?

Yep, the proposal adds it to the source registration JSON.

Is there any estimation for when this feature will be available?

Not yet but stay tuned for information.

[apasel422]

Closing as this is being addressed with the Full Flex proposal.

[arielhal]

Hey @csharrison !
Is there an estimation for when Phase 2 (Full Flexible Event-Level) will be available?

Thanks!

[csharrison]

@arielhal we don't have a concrete timeline yet, but will update as the feature gets closer. We are in the process of specifying it right now.

[arielhal]

Hey @csharrison how are you? :)
Checking again about the ETA for Phase 2 (Full Flexible Event-Level)
Do you have any estimation?
Thanks!

[csharrison]

Thanks for the ping. We don't have a concrete timeline yet and are still in the process of designing and specifying the right behavior.

[pmainguet]

Hello @csharrison we are also interested to use the Phase 2 of Full Flexible Event-Level.
Any progress on that one since Jan 3rd ?

[csharrison]

Hey @pmainguet is your interest in Phase 2 for the use-case described in this issue or something else?

[apasel422]

Chromium expects custom trigger data (values and cardinality) to be available in M123.

[omriariav]

We appreciate the work, and we're excited to use the custom trigger data (fully flexible event-level).
Initial testing shows that we're missing two potential fields that are quite common in performance advertising and eCommerce:

• Currency - We currently can share only the value. A common case is where an advertiser (usually performance advertisers) sends different values in different currencies according to the user geo.

• orderID (Transaction ID) - advertisers report this parameter to ensure conversions and values are not double counted by mistake. They also use this data to analyze and optimize campaign performance, for example, by looking at average order value, most successful products, etc. Without having this parameter as another field, advertising budgets are at risk.

What is your thoughts and what information should we provide to propose adding these fields?

[pmainguet]

@csharrison we work in affiliate marketing where users clicks on links and are then redirected to merchant pages to make salesvia a redirect through our server to count clicks (without user interaction).

Currently, we are very limited by the amount of information we can pass to the API on the click/source side (1 bit of data in our case).

Moreover, to calculate the performance of our different source of traffic, we would need to somehow cross summary reports with event level reports to be able to compute a sales/clicks aggregate, which is highly impractical and will be awfully noised.

The fully flexible event-level feature is exciting for us as we would have more bits of data available and we won't need to use summary reports to do performance optimisation.

And like @omriariav from Taboola we would ideally also need additional info such as the orderid so that our partners trust our computation and reporting.

[danieldansker]

Hey @csharrison how are you?
Regarding the usage of Flexible Event-Level, with the parameter "trigger_data_matching": "exact".
Is it correct that in order to have a match we need to add to the source-event a list of integers that must have an exact match during the trigger-event.
Example:

Attribution-Reporting-Register-Source:

   {
        "source_event_id":"0000000",
        "destination":"https://test.com",
        "trigger_data_matching":"exact",
        "trigger_specs":[{
            "trigger_data":[111111,222,333]
        }]
}

Attribution-Reporting-Register-Trigger:

{
  "event_trigger_data": [
    {
      "trigger_data": 111111
    }
  ]
}

I am testing this on beta browser - Version 123.0.6312.22 (Official Build) beta (arm64), but all reports that are sent are still with a 3-bit limitation.
this is the source that is saved in attribution-internals: (as you can see the trigger data is limited)

{
   "aggregatable_report_window": 2592000,
   "debug_reporting": false,
   "destination": "https://round-table.co.il",
   "event_level_epsilon": 14.0,
   "expiry": 2592000,
   "max_event_level_reports": 3,
   "priority": "0",
   "source_event_id": "7172822603428505672",
   "trigger_data_matching": "exact",
   "trigger_specs": [ {
      "event_report_windows": {
         "end_times": [ 172800, 604800, 2592000 ],
         "start_time": 0
      },
      "trigger_data": [ 0, 1, 2, 3, 4, 5, 6, 7 ]
   } ]
}

[apasel422]

@danieldansker In your source registration, this is incorrect:

"trigger_specs":[{
  "trigger_data":[111111,222,333]
}]

Chromium doesn't yet support top-level trigger_specs: You should move the trigger_data field to the top-level of the source registration, i.e. as a sibling of trigger_data_matching per the explainer.

[apasel422]

Here is a header-validator link warning about the unknown trigger_specs field.

[omriariav]

Hi - we see that orderId is now supported in the 'flex event' (2nd bullet under 'goals' here)

We are going to test this in the coming weeks.

Do you happen to have any updates regarding the currency field?

(cc: @danieldansker )

[apasel422]

@omriariav Could you clarify what you mean by orderId and the currency field? Perhaps you mean the value field mentioned in the proposal? If so, it hasn’t been specified yet.

[taboola1dsg]

@apasel422 you can see clarification in Omri's previous reply .

When are you planning to add support to these parameters/values? thanks

[danieldansker]

Hey @apasel422 ,

1. I am trying to understand the exact noise mechanism for event-level reports and can't really find information.
2. Understand the trade-off between trigger-data list-size and max_event_level_reports. How can I check and test this?
   Thanks

[apasel422]

@danieldansker

I am trying to understand the exact noise mechanism for event-level reports and can't really find information.

An overview is available in the explainer. More details are available in the specification.

Understand the trade-off between trigger-data list-size and max_event_level_reports. How can I check and test this?

The simplest option is probably the header validator.

[jolynyao]

Hi @omriariav and @taboola1dsg - we don't have a planned timeline to add support for summary buckets ("value" field in trigger_data) or multiple trigger specs in Chrome, though these will be available in an upcoming Android ARA release for experimentation (see row 27 here)

We're very interested in results from testing these features out and feedback will help us determine launch plans, if you're able to test on Android first.

[danieldansker]

Hi @apasel422 ,
Can we change the 'event_level_epsilon' parameter value?
In addition can you please explain how the informatio_gain is calculated?
I couldn't find the documentation.
Thanks

[apasel422]

Can we change the 'event_level_epsilon' parameter value?

Yes. Here's an example.

In addition can you please explain how the informatio_gain is calculated?

Here is the specification definition.

You may find it easier, though, to look at an actual implementation: TypeScript, C++.