1824786 - Add event telemetry for the migration wizards

Status: RESOLVED FIXED

(Firefox :: Migration, task, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

Per bug 1824010 comment 1, which is reproduced here:

The different events I think would make sense are:

1. migration_wizard.opened - when the migration wizard loads
2. migration_wizard.no_browsers_found - if the user sees the error message that no browsers were found that can be migrated from.
3. migration_wizard.browser_selected - includes extra_data for the browser that was selected.
4. migration_wizard.profile_selected - includes extra_data for the browser that the profile is being migrated from
5. migration_wizard.resources_selected - what resource types were selected (for the new migration wizard, we should also record for variant 2 whether or not the user expanded the resource type selector section), and the migrator key.
6. migration_wizard.safari_perms - if permissions were requested to access the Safari profile directory
7. migration_wizard.safari_password_file - if the user chose to import passwords from a CSV file from Safari for the new Migration Wizard (this doesn't exist in the old wizard).
8. migration_wizard.migration_started - migration began (including browser type, resources types)
9. migration_wizard.migration_finished - migration completed (including browser type, resources types)

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey loines, I'm looking at the documentation for event telemetry, and one thing that jumps out is that the limit on extra key values is 80 bytes.

We have quite a few migrators, and their IDs are currently as follows:

firefox
safari
brave
canary
chrome
chromium
chromium-edge
chromium-edge-beta
opera
vivaldi
opera-gx

If we do the simple thing and use a single-character delimiter like a semi-colon, we get this string:

"firefox;safari;brave;canary;chrome;chromium;chromium-edge;chromium-edge-beta;opera;vivaldi;opera-gx"

Which has 99 characters in it, blowing us through our limit (that's presuming we're already downcasting these JavaScript strings to a byte-per-character).

Is it sufficient to just include the number of other migrators? Or is there a better way of including which migrators are also available outside of event telemetry?

Comment 2

[Leif Oines [:loines]]

I do think we want to know the particular IDs of the migrators.

One approach might be to make each possible migrator its own key, with boolean values indicating whether that browser was selected / available (depending on the particular event). This is similar to how we key the histograms already - its not a very compact representation but I think it can work. Doing it this way might also make accessing the stats about individual source browsers slightly easier on the backend, compared to a solution that uses the colon-separated list.

If we need to future proof to handle potential future new keys, we can add an other option.

Does this work from a technical perspective?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Leif Oines [:loines] from comment #2)

Does this work from a technical perspective?

Yes it does, thank you!

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Actually, I'm wrong. This doesn't work, because apparently we have a limit of 10 extra_keys per event, and there are actually 15 possible migrator keys (the list from comment 1 only listed the ones on my local macOS machine).

Is there another Telemetry data structure I could use here instead? Would a categorical histogram or a keyed scalar make sense to use?

Comment 5

[Leif Oines [:loines]]

Can we we mostly keep the event format from comment 1 except move the information about what source browser were available at the time it was opened to a MIGRATION_WIZARD_AVAILABLE_BROWSERS keyed scalar?

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Spoke to loines separately, and we're going to use a keyed numeric scalar, where the keys will be migrator keys, and the value will be how many browser/profile pairs were discovered. This will be separate from the event telemetry.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1824786 - Add event telemetry for the migration wizards. data-review=jhirsch, r?niklas!

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Attachment: Data collection request.md

Comment 9

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Comment on attachment 9326655 [details]
Data collection request.md

data-review+, great to see we are carefully instrumenting the steps in the migration flow 👍

Note that the implementation of the browser.migration.safari_password_file event is not in this bug, but (according to discussion in the phabricator review) will be in bug 1825874. I'll mention this in a comment on that bug as well.

---

1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?

Yes, the usual Firefox data docs at https://probes.telemetry.mozilla.org.

2. Is there a control mechanism that allows the user to turn the data collection on and off?

Yes, the usual telemetry opt-out controls in about:preferences.

3. If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, mconley will monitor.

4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, interaction data.

5. Is the data collection request for default-on or default-off?

Default-on.

6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No.

7. Is the data collection covered by the existing Firefox privacy notice?

Yes.

8. Does the data collection use a third-party collection tool?

No.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/51364a45cba3
Add event telemetry for the migration wizards. data-review=jhirsch, r=niklas

Comment 11

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/51364a45cba3