Generate enrollment IDs and include them on all related telemetry events
Categories
(Firefox :: Normandy Client, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox71 | --- | fixed |
People
(Reporter: mythmon, Assigned: mythmon)
References
Details
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
2.62 KB,
text/plain
|
tdsmith
:
data-review+
|
Details |
When enrolling a user in an experiment (add-on or preference), an enrollment ID should be generated. For any subsequent event sent about that experiment, the enrollment ID should be included as an extra field. This will make it easier to analyze sequences of events for an experiment.
This will also help debug why we see users enrolling many times in an experiment, enrolling once but unenrolling many times, or other combinations of invalid events. The leading theory about why this happens is profile duplication, which causes many clients to share one Telemetry and Normandy ID. By randomly generated these IDs at the time of enrollment, we make it easier to identify cloned profiles.
Assignee | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
adding a requirement here, we need this enrollment ID to also be added to main pings. Reason being, usage metrics are calculated from main pings (or downstream from there, main summary, experiments table, search table, etc.) so having enrollment ID present there allows us to distinguish between cloned profiles sharing client_ids. If they're only present in event telemetry, we won't have this capability.
Assignee | ||
Comment 2•6 years ago
|
||
That requirement is already captured in bug 1555178.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 3•6 years ago
|
||
Comment 5•6 years ago
|
||
Friendly reminder that adding keys to telemetry events is a new collection so it should receive data review before landing in a build.
Super psyched for this!
Assignee | ||
Comment 6•6 years ago
|
||
This is very similar to the data review from bug 1555172, which introduced some of the APIs this feature uses (but didn't actually collect new data).
One thing to note is that current these identifiers are not cleared when Telemetry is disabled, which is a problem. I've filed bug 1584337 to cover that.
Assignee | ||
Updated•6 years ago
|
Comment 7•6 years ago
|
||
Comment 8•6 years ago
|
||
bugherder |
Comment 9•6 years ago
•
|
||
Trust & Security Data Collection Review:
Approved for the additional identifier. Note: I believe this is Cat 2 - interaction data, rather than Cat 1 - technical data, but if I'm misunderstanding how you are interpreting this ID, please advise.
- 1 to the requirement that if a user opts out of telemetry, this ID needs to be deleted. Adding Mark Reid for situational awareness as he works on telemetry deletion requirements for the California Consumer Privacy Act.
Updated•6 years ago
|
Comment 10•6 years ago
|
||
Thanks, Alicia! I asserted that it's category 1 because if experiments are enabled, the enrollment IDs will be created automatically without any user intervention. The identifiers themselves are random and do not contain information. Knowing that an enrollment ID for a client exists doesn't let us infer anything about user actions (except that Firefox was running during the experiment's enrollment period, which is generally true for Cat 1 data).
Comment 11•6 years ago
•
|
||
(In reply to Tim Smith 👨🔬 [:tdsmith] from comment #10)
Thanks, Alicia! I asserted that it's category 1 because if experiments are enabled, the enrollment IDs will be created automatically without any user intervention. The identifiers themselves are random and do not contain information. Knowing that an enrollment ID for a client exists doesn't let us infer anything about user actions (except that Firefox was running during the experiment's enrollment period, which is generally true for Cat 1 data).
Thanks Tim. That makes sense. Bug 1555172 called it cat 2 so if there is a discrepancy in the way we define it for category purposes we should make sure we are clear why its Cat 2 in 1555172 and Cat 1 here. Looks like that is because this is the ID creation bug and 155172 is related to the events themselves.
Description
•