For #10261: PWA Telemetry

[eliserichards]

For #10261
Depends on mozilla-mobile/android-components#7493 and mozilla-mobile/android-components#7805

Events in Fenix:

• Event.ProgressiveWebAppOpenFromHomescreenTap -> map to HOMESCREEN_ICON_TAP
• Event.ProgressiveWebAppForeground -> map to ENTER_FOREGROUND
• Event.ProgressiveWebAppBackground -> map to ENTER_BACKGROUND
• Event.ProgressiveWebAppInstallAsShortcut: An event ping when tapping the ‘Install’ menu. -> map to `ProgressiveWebAppFacts.Items.INSTALL_SHORTCUT
• Distinguish between ‘Install’ PWA vs ‘Add to homescreen’ shortcut. There is no differentiation here ATM. In AC, we treat both as creating a shortcut and then map that to either the PWA or "bookmark" when it's opened. This install ping is added in AC instead of fenix (see below)

Events needing AC Facts:

• mozilla-mobile/fenix#10261: Add facts for PWAs android-components#7493
  • ProgressiveWebAppFacts.Items.ENTER_FOREGROUND: An event ping when putting a PWA to the foreground with the current system time
  • ProgressiveWebAppFacts.Items.ENTER_BACKGROUND: An event ping when putting a PWA to the background with the current system time
  • ProgressiveWebAppFacts.Items.HOMESCREEN_ICON_TAP: An event ping when tapping PWA homescreen icons.
• mozilla-mobile/fenix#10261: PWA install fact android-components#7805
  • ProgressiveWebAppFacts.Items.INSTALL_SHORTCUT: An event ping when installing a PWA.

Pull Request checklist

• Tests: This PR includes thorough tests or an explanation of why it does not
• Screenshots: This PR includes screenshots or GIFs of the changes made or an explanation of why it does not
• Accessibility: The code in this PR follows accessibility best practices or does not include any user facing features. In addition, it includes a screenshot of a successful accessibility scan to ensure no new defects are added to the product.

After merge

• Milestone: Make sure issues finished by this pull request are added to the milestone of the version currently in development.

To download an APK when reviewing a PR:

1. click on Show All Checks,
2. click Details next to "Taskcluster (pull_request)" after it appears and then finishes with a green checkmark,
3. click on the "Fenix - assemble" task, then click "Run Artifacts".
4. the APK links should be on the left side of the screen, named for each CPU architecture

[codecov-commenter]

Codecov Report

Merging #11859 into master will decrease coverage by 0.08%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master   #11859      +/-   ##
============================================
- Coverage     28.43%   28.35%   -0.09%     
  Complexity     1033     1033              
============================================
  Files           418      418              
  Lines         16761    16826      +65     
  Branches       2180     2190      +10     
============================================
+ Hits           4766     4771       +5     
- Misses        11650    11710      +60     
  Partials        345      345              

Impacted Files	Coverage Δ	Complexity Δ
...a/org/mozilla/fenix/browser/BaseBrowserFragment.kt	0.00% <ø> (ø)	0.00 <0.00> (ø)
...java/org/mozilla/fenix/components/metrics/Event.kt	29.25% <0.00%> (-0.61%)	0.00 <0.00> (ø)
...la/fenix/components/metrics/GleanMetricsService.kt	12.02% <0.00%> (-0.24%)	4.00 <0.00> (ø)
...zilla/fenix/components/metrics/MetricController.kt	35.57% <0.00%> (-1.43%)	0.00 <0.00> (ø)
...lla/fenix/customtabs/ExternalAppBrowserFragment.kt	0.00% <0.00%> (ø)	0.00 <0.00> (ø)
...illa/fenix/shortcut/PwaOnboardingDialogFragment.kt	0.00% <0.00%> (ø)	0.00 <0.00> (ø)
...a/org/mozilla/gecko/search/SearchWidgetProvider.kt	24.00% <0.00%> (-9.34%)	1.00% <0.00%> (ø%)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6f5f8cc...566ef33. Read the comment docs.

[eliserichards]

Waiting on mozilla-mobile/android-components#7493 to be merged

[eliserichards]

Request for data collection review form

All questions are mandatory. You must receive review from a data steward peer on your responses to these questions before shipping new data collection.

1. What questions will you answer with this data?

• Do we make PWA sites easily discoverable?
• How often users install a PWA on their phone’s homescreen?
• How often do users run a PWA site in Fenix?

2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements?

• We would like to better understand the use of Progressive Web Apps to streamline the experience for users, and to ensure that the initial interaction with the app is useful and doesn't drive people away.

3. What alternative methods did you consider to answer these questions? Why were they not sufficient?

• There is not currently an alternative to measure this.

4. Can current instrumentation answer these questions?

• No, there are no currently metrics around web apps.

5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the found on the Mozilla wiki.

• All data is Category 2.

6. How long will this data be collected?

• Until 10/01/2020

7. What populations will you measure?

• All release, beta, and nightly users with telemetry enabled.

8. Please provide a general description of how you will analyze this data.

• Glean / Amplitude

9. Where do you intend to share the results of your analysis?

• Only on Glean, Amplitude and with mobile teams.

[NotWoods]

Should events also be added for when the actual PWA is in foreground?

[liuche]

data-review+ only, pending questions about the time ms collected - is that useful to DS?

Data Review Form (to be filled by Data Stewards)

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, these probes are documented in metrics.md

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

Yes, this telemetry is controlled by Fenix data settings

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

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

Type 2, interaction with PWA

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 there need to be a check-in in the future to determine whether to renew the data? (Yes/No) (If yes, set a todo reminder or file a bug if appropriate)**

No, has expiry

9. Does the data collection use a third-party collection tool? If yes, escalate to legal.

No

[liuche]

Is the idea that DS will do this calculation themselves? Can you verify with Marissa that that is the case, or if the client should calculate that duration between foreground/background when backgrounding the activity? Personally I'd prefer for the client to do this duration calculation and send that number, rather than sending 2 timestamps.

[eliserichards]

This is all done in AC and they don't want calculations like this to happen 😢

[eliserichards]

Also we haven't defined what time we want between foreground/bg, so Marissa can change it as needed without needing a code fix

Changes changes changes! Let's move everything to AC :j

[eliserichards]

AC changes didn't make it into 52.0.0, so this needs to wait to merge so it doesn't break when we cut for beta tonight