995794 - Acquire stub installer usage metrics (reinstall)

Status: NEW

(Firefox :: Installer, enhancement, P3)

Description

[Robert Strong (they/them - no direct email)]

I think a metric usage would provide insight especially when compared to the existing version on install. For example, we get the previous version when we install on top of an existing install. If we also had date of use for let's say the 10th or 30th previous launch we could infer how often Firefox is used. This would provide us with an approximation of whether Firefox is used often and they are reinstalling vs. the case where Firefox is not used that often and is being manually upgraded due to not using it that often. We have always had around 48% of installs being pave over installs which is another reason why I think this would be valuable.

Comment 1

[David Durst [:ddurst]]

I expect this would include how many installs are there by way of the stub installer vs the full.

Comment 2

[Romain Testard [:RT]]

I updated the user story with some details of how we could set this up.
This is interesting to me in order to help understand what's going on WRT users re-installing Firefox and how we could potentially address this with current onboarding activities.
Matt, does the requirement in the user story field look reasonable?

Comment 3

[Molly Howell (she/her) (no longer active)]

Yeah, this sounds good. Date/time of a previous installation wouldn't be too hard for the installer to start getting.

We don't necessarily need to tie the "known previous installs" state to the profile directory like the field in the current ping does; we could use the registry to find existing installs, so the information would survive if something happened to that directory.

> What should we do with 'had_old_install', 'version' and 'old_version'?
We certainly don't have to leave those fields alone. If they're totally supplanted by the new info, we can just remove them. Or we can change their semantics somehow if they're not useful as they are.

> Could we have a "Uninstalled" flag to understand date of uninstallation?
I would rather not have the uninstaller intentionally leave behind something like that, partly because it just doesn't feel right to have an uninstall *create* new stuff, and partly because I think it would be unreliable; there would be a lot of cases of annoyed users or specific tools like CCleaner and Revo Uninstaller deleting anything like that because they would interpret it as an incomplete uninstallation.

Comment 4

[Romain Testard [:RT]]

(In reply to Matt Howell [:mhowell] from comment #3)
> Yeah, this sounds good. Date/time of a previous installation wouldn't be too
> hard for the installer to start getting.
> 
> We don't necessarily need to tie the "known previous installs" state to the
> profile directory like the field in the current ping does; we could use the
> registry to find existing installs, so the information would survive if
> something happened to that directory.
Awesome, updated the US accordingly
> 
> > What should we do with 'had_old_install', 'version' and 'old_version'?
> We certainly don't have to leave those fields alone. If they're totally
> supplanted by the new info, we can just remove them. Or we can change their
> semantics somehow if they're not useful as they are.
OK, it probably makes sense to remove them since that data would be available in the new field
> 
> > Could we have a "Uninstalled" flag to understand date of uninstallation?
> I would rather not have the uninstaller intentionally leave behind something
> like that, partly because it just doesn't feel right to have an uninstall
> *create* new stuff, and partly because I think it would be unreliable; there
> would be a lot of cases of annoyed users or specific tools like CCleaner and
> Revo Uninstaller deleting anything like that because they would interpret it
> as an incomplete uninstallation.
I see, thanks