Open Bug 995794 Opened 11 years ago Updated 2 years ago

Acquire stub installer usage metrics (reinstall)

Categories

(Firefox :: Installer, enhancement, P3)

x86_64
Windows 8.1
enhancement

Tracking

()

People

(Reporter: robert.strong.bugs, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [stubv3=])

User Story

As a product manager I want to understand how often users re-install Firefox and through which means so that I can identify user patterns and potential issues.

Acceptance criteria:
- The stub ping data includes details from all known previous installs:
---Version installed
---Installation date and time (time is useful to cover scenarios where users re-install right after having installed)
---Installation type. Type can be stub installer or full installer
- Known previous installs are Firefox installs that were made prior to the current install. The registry could be used to find existing installs, so the information would survive if something happened to the installation directory
- Remove 'had_old_install', 'version' and 'old_version' fields from the stub ping

To be clarified:
- Does it make sense to have an installation type "other" covering 3rd party builds?
- Could we have a "Uninstalled" flag to understand date of uninstallation?
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.
Whiteboard: [stubv2=] → [stubv3=]
I expect this would include how many installs are there by way of the stub installer vs the full.
Priority: -- → P2
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?
User Story: (updated)
Flags: needinfo?(mhowell)
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.
Flags: needinfo?(mhowell)
(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
User Story: (updated)
Blocks: 1429889
Summary: Stub installer metric for usage → Acquire stub installer usage metrics (reinstall)
Type: defect → enhancement
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.