Consider having browser provided filters for lookback window

[johnivdel]

The current filtering mechanism in the API supports custom trigger-based lookback windows using the list intersection logic. For example, if you have conversion type = 0 with a 7 day lookback, and conversion_type = 1 with a 3 day lookback, you can encode this by doing:

source

{
...
  "filter_data": {"lookback": "day5"}
}

trigger

{
   ...
  "event_trigger_data": [
     {
     "trigger_data": 0
     "filters": {"lookback": ["day1", "day2", "day3", "day4", "day5", "day6", "day7"]}
     },
     {
     "trigger_data": 0
     "filters": {"lookback": ["day5", "day6", "day7"]}
     }
]
}

While this works, it is not a dense encoding, and supporting granularity beyond days would require a very large increase in size.

The browser could provide a custom filter which would have it's own behavior:

source -> no changes
trigger

{
   ...
  "event_trigger_data": [
     {
     "trigger_data": 0
     "lookback": 7 // days, but could support a finer unit
     },
     {
     "trigger_data": 0
     "lookback": 3 
     }
]
}

The browser would include the lookback field and perform it's own comparison using "trigger time - source time" when deciding if a filter matches.

This is more flexible, but introduces more complexity to the filtering logic / registration schema.

[i-bansal]

The above proposed solution would not work with OR support that was added for filters in issue as described in the example below without breaking the OR into individual event blocks.

Before lookback support -

{
 ...
  "event_trigger_data": [
    {
      "trigger_data": "2",
       "filters": [
           {"source_type": ["view"], "lookback": ["day1", "day2"]},  // OR
           {"source_type": ["navigation"], "lookback": ["day1", "day2", "day3", "day4", "day5"]}
        ]
    },
]}

After lookback support -

  {
   ...
  "event_trigger_data": [
     {
     "trigger_data": 2
     "lookback": 2
     "filters": [{"source_type": ["view"]]}]
     },
     {
     "trigger_data": 2
     "lookback": 5
     "filters": [{"source_type": ["navigation"]]}]
     },
]}

[apasel422]

I agree with the sentiment of this request, especially because it would reduce the amount of filter data transmitted and stored client-side, but I would rather pursue a general client-side filtering DSL in which a "source age" property could be exposed and used arbitrarily, instead of adding a dedicated lookback field that is limited in its ability to compose with other features.

That said, if we do implement lookback as a dedicated feature for expedience, in addition to the point raised by #769 (comment):

1. Should lookback take place as part of source matching or as part of filtering?
2. If it's the latter, should there be a corresponding verbose debug report?
3. What should the time delta granularity be?

[saxena-shobhit]

Lookback window is a standard and critical attribution feature for ad-techs. Natively supporting accurate lookback windows is really important. Attribution windows tend to be specified in hours and/or days, and are generally used accurate to the second. The current support mentioned above, however, relies on matching calendar dates - which can lead to under or over attribution of conversions. Eg: for a trigger which occurs in the first hour of today’s calendar date with an intended window of n days, it’s highly likely that a large number of sources earlier in time which were registered n days ago, but are not falling within calendar dates [today - (n-1), … today] will be filtered out by the attribution logic. Additionally, specifying the window with the current mechanism could end up bloating the size of the registration response payload, particularly when working with multiple event-level blocks and aggregate key pieces, which may hit response size limitations.

Lookback window is an attribution feature. So specifying the lookback at attribution level would make more sense. Extensibility to specify different lookback windows for event_trigger_data and aggregatable_data is highly desirable. In addition, we would like to have different lookback windows based on source filter_data & source_type. So supporting filters while selecting lookback would be really important.

A potential specification example could be the following:

{
  // First party attribution filters
  "lookback": [
	{
           "window" : 2592000, // 30 days
           "filters": [{ "source_type":["navigation"]}]  // OR filters
        },
       { 
          "window" : 604800, // 7days
          "filters": [{"source_type":["event"] }]  // OR filters
       },
  ],

... // existing fields, such as `filters`, `event_trigger_data`

}

[apasel422]

Extensibility to specify different lookback windows for event_trigger_data and aggregatable_data is highly desirable.

Could you provide an example of the JSON syntax for this?

[johnivdel]

In response to #769 (comment):

1. Should lookback take place as part of source matching or as part of filtering?

Lookback would need to take place as part of filtering as it is based on source + trigger time information. In our current model, it is fine to use information from both sides as part of filtering. Using it for matching allows for additional information to be encoded in a report through the "choice" of which source to use, so we should avoid this.

2. If it's the latter, should there be a corresponding verbose debug report?

Including a verbose debug report sounds reasonable as it allows the adtech to verify the system is working as expected within the browser.

3. What should the time delta granularity be?

Ideally we could match expiry and accept millisecond granularities, as recommended by https://w3ctag.github.io/design-principles/#milliseconds (given this isn't privacy sensitive).

[csharrison]

Ideally we could match expiry and accept millisecond granularities, as recommended by https://w3ctag.github.io/design-principles/#milliseconds (given this isn't privacy sensitive).

Nit: Expiry is in seconds granularity. https://wicg.github.io/attribution-reporting-api/#parse-an-expiry. See #132.