Propose a simple trigger prioritization algo for flex event by csharrison · Pull Request #1112 · WICG/attribution-reporting-api

csharrison · 2023-11-15T21:24:37Z

Fixes #900

yanzhangnyc · 2023-11-15T21:56:26Z

flexible_event_config.md

+
+Given that triggering attribution can affect a source's state without producing a report, we will need a new algorithm for doing trigger prioritization. Here is a sketch of how it could work:
+
+1. Always maintain a sorted list of triggers, sorted in order of priority (descending) and trigger time (ascending)


Always maintain a sorted list of triggers that are not fully consumed in sent report , sorted in order of priority (descending), then trigger time (ascending).

What does "fully consumed" mean here?

Trigger value was fully applied in the creation of a report whose report time is earlier than the trigger time (for "count" operator, the value is 1).

(Current trigger time, so report time less than current window start).

In the context of this PR, I don't understand how a trigger could be partially consumed. Not that this PR goes into the details of summary buckets, but in step 2.1 is the trigger's entire value not added to the spec's current value, resulting in N reports depending on the summary buckets?

@yanzhangnyc I think you're describing an implementation, not an explainer-level algorithm description, particularly with the idea that part of a trigger's value is left over for another report in your third item.

Why isn't deleting all triggers associated with the spec + window sufficient?

Let's say we consumed 10 of a trigger's value of 12. If we erase this trigger, we have no way of knowing the priority of the remaining value of 2 as it applies to the procedure of generating reports in the next window.

Why isn't deleting all triggers associated with the spec + window sufficient?

Let's say we consumed 10 of a trigger's value of 12. If we erase this trigger, we have no way of knowing the priority of the remaining value of 2 as it applies to the procedure of generating reports in the next window.

That is an implementation detail not relevant to the explainer-level description here and is covered by "update the source's state based on all of the triggers that were successfully applied."

Ok, then if nothing else, this shows how hard it is for me to understand the current proposal.

What does "update the source's state based on all of the triggers that were successfully applied" mean?

yanzhangnyc · 2023-11-15T21:57:43Z

flexible_event_config.md

+Given that triggering attribution can affect a source's state without producing a report, we will need a new algorithm for doing trigger prioritization. Here is a sketch of how it could work:
+
+1. Always maintain a sorted list of triggers, sorted in order of priority (descending) and trigger time (ascending)
+2. Whenver a spec's window's end time is hit (breaking ties arbitrarily)


When a new trigger "matching" this source, we will perform the following process. Not at end of a reporting window

Why does this matter?

I intentionally described this per reporting window to minimize the amount of state / accounting. I think the end result should be the same?

To me it's a lot easier to understand this algorithm when it's described as happening at the end of each report window, not when a trigger is handled.

@csharrison @giladbarkan-github , Depending on how to undertand "end of trigger window". For example, at end of the trigger window of trigger_data 1, does 1) all triggers processed or 2) only triggers containing trigger_data 1 is processed? If 2), the trigger data with earlier reporting window will have the highest priority. If 1), it might be even more complicated than handling it at trigger time. Let me think about any other complication for this option.

@yanzhangnyc The PR says "iterate through triggers in order". I take that to mean all triggers associated with this source.

@yanzhangnyc The PR says "iterate through triggers in order". I take that to mean all triggers associated with this source.

If so, we need to emphasize "at the end window of any trigger data" instead of just simply mention "trigger window end".

I updated the wording. PTAL

Call ma various sxe per

flexible_event_config.md

apasel422 · 2023-11-15T22:26:22Z

flexible_event_config.md

+Given that triggering attribution can affect a source's state without producing a report, we will need a new algorithm for doing trigger prioritization. Here is a sketch of how it could work:
+
+1. Always maintain a sorted list of triggers, sorted in order of priority (descending) and trigger time (ascending)
+2. Whenver a spec's window's end time is hit (breaking ties arbitrarily)


To me it's a lot easier to understand this algorithm when it's described as happening at the end of each report window, not when a trigger is handled.

flexible_event_config.md

Co-authored-by: Andrew Paseltiner <[email protected]>

flexible_event_config.md

Co-authored-by: Andrew Paseltiner <[email protected]>

flexible_event_config.md

apasel422 · 2023-11-22T15:05:03Z

flexible_event_config.md

+Given that triggering attribution can affect a source's state without producing a report, we will need a new algorithm for doing trigger prioritization. Here is a sketch of how it could work:
+
+1. For every source, maintain a list of triggers, sorted in order of priority (descending), then trigger time (ascending)
+2. At the end of any report window (across all of a source's specs, breaking ties arbitrarily):


Is there any concern that breaking ties arbitrarily will make it harder to ensure interop conformance?

Could someone please give an example where breaking a tie one way would differ from another? What choice are we referencing here?

giladbarkan-github · 2024-01-18T13:51:17Z

flexible_event_config.md

+2. At the end of any report window (across all of a source's specs, breaking ties arbitrarily):
+    1. Iterate through the source's triggers in order, "applying" them to generate a list of "speculative" reports. Stop whenever privacy limits are hit.
+    2. Send all of the speculative reports that are scheduled to be emitted in the current window
+    3. Update the source's total value per trigger data, and total # of event-level reports based on all of the triggers that were successfully applied in the current window.


What's the difference between "successfully" applied and otherwise applied?

giladbarkan-github · 2024-01-18T13:53:18Z

flexible_event_config.md

+    2. Send all of the speculative reports that are scheduled to be emitted in the current window
+    3. Update the source's total value per trigger data, and total # of event-level reports based on all of the triggers that were successfully applied in the current window.
+    4. Delete all of the speculative reports that are not scheduled to be emitted in this window.
+    5. Delete all of the triggers associated with the current spec and window from the source's trigger list


Not sure if this works with the current Android implementation that has "partial" application of a trigger's value, which can extend to the next window. Maybe I'm misunderstanding.

giladbarkan-github · 2024-01-18T13:54:25Z

flexible_event_config.md

+    1. Iterate through the source's triggers in order, "applying" them to generate a list of "speculative" reports. Stop whenever privacy limits are hit.
+    2. Send all of the speculative reports that are scheduled to be emitted in the current window
+    3. Update the source's total value per trigger data, and total # of event-level reports based on all of the triggers that were successfully applied in the current window.
+    4. Delete all of the speculative reports that are not scheduled to be emitted in this window.


How did the reports that are deleted here get created?

csharrison added 3 commits November 15, 2023 15:24

Update flexible_event_config.md

9b5acdc

Update flexible_event_config.md

8931255

Remove TODO

4c541a8

yanzhangnyc reviewed Nov 15, 2023

View reviewed changes

apasel422 approved these changes Nov 15, 2023

View reviewed changes

Update flexible_event_config.md

7dd5563

Co-authored-by: Andrew Paseltiner <[email protected]>

apasel422 approved these changes Nov 15, 2023

View reviewed changes

flexible_event_config.md Outdated Show resolved Hide resolved

csharrison and others added 2 commits November 15, 2023 16:33

Update flexible_event_config.md

01fdce3

Co-authored-by: Andrew Paseltiner <[email protected]>

Update flexible_event_config.md

ec39b2b

csharrison marked this pull request as ready for review November 16, 2023 02:14

apasel422 approved these changes Nov 16, 2023

View reviewed changes

giladbarkan-github reviewed Nov 16, 2023

View reviewed changes

flexible_event_config.md Outdated Show resolved Hide resolved

yanzhangnyc approved these changes Nov 16, 2023

View reviewed changes

csharrison added 2 commits November 16, 2023 09:54

Update flexible_event_config.md

694eb06

Update flexible_event_config.md

ebeee69

apasel422 reviewed Nov 22, 2023

View reviewed changes

apasel422 added the flexible-event Regarding the flexible event configuration proposal label Dec 1, 2023

giladbarkan-github reviewed Jan 18, 2024

View reviewed changes

WinaiKongbok mentioned this pull request Mar 22, 2025

Trigger value was fully applied in the creation of a report whose report time is earlier than the trigger time (for "count" operator, the value is 1). #1507

Closed


		Given that triggering attribution can affect a source's state without producing a report, we will need a new algorithm for doing trigger prioritization. Here is a sketch of how it could work:

		1. Always maintain a sorted list of triggers, sorted in order of priority (descending) and trigger time (ascending)

Conversation

csharrison commented Nov 15, 2023 • edited by apasel422 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

giladbarkan-github Nov 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yanzhangnyc Nov 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

csharrison commented Nov 15, 2023 •

edited by apasel422

Loading

giladbarkan-github Nov 15, 2023 •

edited

Loading

yanzhangnyc Nov 15, 2023 •

edited

Loading