-
Notifications
You must be signed in to change notification settings - Fork 220
Propose a simple trigger prioritization algo for flex event #1112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 3 commits
9b5acdc
8931255
4c541a8
7dd5563
01fdce3
ec39b2b
694eb06
ebeee69
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,6 +9,7 @@ _Note: This document describes possible new functionality in the Attribution Rep | |
| - [Goals](#goals) | ||
| - [Phase 2: Full Flexible Event-Level](#phase-2-full-flexible-event-level) | ||
| - [API changes](#api-changes) | ||
| - [Trigger prioritization](#trigger-prioritization) | ||
| - [Trigger-data modulus matching example](#trigger-data-modulus-matching-example) | ||
| - [Configurations that are equivalent to the current version](#configurations-that-are-equivalent-to-the-current-version) | ||
| - [Equivalent event sources](#equivalent-event-sources) | ||
|
|
@@ -169,6 +170,15 @@ When the `event_report_window` for a spec completes, we will map its summary val | |
| "trigger_summary_bucket": [<bucket start>, <bucket end>] | ||
| } | ||
| ``` | ||
| ### Trigger prioritization | ||
|
|
||
| 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) | ||
|
||
| 1. Iterate through triggers in order, "applying" them to generate a list of "speculative" reports. Stop when privacy limits are hit. | ||
csharrison marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| 2. Flush all of the speculative reports that are scheduled to be emitted in the current window, and update the source's state based on all of the triggers that were successfully applied. | ||
csharrison marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| 3. Erase all of the triggers associated with the current spec and window. | ||
|
|
||
| ### Trigger-data modulus matching example | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "fully consumed" mean here?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Current trigger time, so report time less than current window start).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, then if nothing else, this shows how hard it is for me to understand the current proposal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "update the source's state based on all of the triggers that were successfully applied" mean?