Two points:

1. We should consider making event_attribution_window extensible enough that it could take a begin and end time. This satisfies the use-case of partitioning users/sources across a lookback window (e.g. some sources look at 1-7 days, some only at 7-14, some only at 14-30). I don't think it needs to be in this PR but we should consider this extension for the future (e.g. you can input either a scalar or a tuple here).
2. Don't we also want an aggregate_attribution_window?

Two points:

1. We should consider making event_attribution_window extensible enough that it could take a begin and end time. This satisfies the use-case of partitioning users/sources across a lookback window (e.g. some sources look at 1-7 days, some only at 7-14, some only at 14-30). I don't think it needs to be in this PR but we should consider this extension for the future (e.g. you can input either a scalar or a tuple here).
2. Don't we also want an aggregate_attribution_window?

I think that is reasonable, but I don't think using a single value will make swapping to a tuple or similar too difficult, so I would prefer to err on the side of YAGNI.

2. Good question, the issue in question seems to only request the capability for event level reports, which is why I only added an event window param. I think we could add one for aggregate to make this more flexible. That being said, do we have a use-case where you would want to stop generating aggregate reports and only generate event reports?

Please also update the header validator to remove the aggregatable_expiry field and add the new one.

Done, PT another look.

1. I think that is reasonable, but I don't think using a single value will make swapping to a tuple or similar too difficult, so I would prefer to err on the side of YAGNI.

That's fine with me.

2. Good question, the issue in question seems to only request the capability for event level reports, which is why I only added an event window param. I think we could add one for aggregate to make this more flexible. That being said, do we have a use-case where you would want to stop generating aggregate reports and only generate event reports?

I was thinking of use-cases that would use this capability and also want consistency with aggregatable reports. For instance, the use-case in #561 might take advantage of this for both reports, where we have privacy restrictions about small expiry values but no privacy restrictions for these windows because they take effect after attribution matching.

1. I think that is reasonable, but I don't think using a single value will make swapping to a tuple or similar too difficult, so I would prefer to err on the side of YAGNI.

That's fine with me.

2. Good question, the issue in question seems to only request the capability for event level reports, which is why I only added an event window param. I think we could add one for aggregate to make this more flexible. That being said, do we have a use-case where you would want to stop generating aggregate reports and only generate event reports?

I was thinking of use-cases that would use this capability and also want consistency with aggregatable reports. For instance, the use-case in #561 might take advantage of this for both reports, where we have privacy restrictions about small expiry values but no privacy restrictions for these windows because they take effect after attribution matching.

If they want consistency, they would be able to set expiry == event_report_window. Do we think a reporter would ever want to:

1. set aggregate_report_window < event_report_window
2. set both aggregate_report_window and event_report_window < expiry?

If they want consistency, they would be able to set expiry == event_report_window. Do we think a reporter would ever want to:

1. set aggregate_report_window < event_report_window
2. set both aggregate_report_window and event_report_window < expiry?

(2) is required to (partially) address #561 where we'd want consistency and the window < expiry.