Closed Bug 1198164 Opened 9 years ago Closed 9 years ago

[Metrics] FTU ping should include info on whether User opt-in for metrics

Categories

(Firefox OS Graveyard :: Stability, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rdandu, Assigned: thills)

References

Details

Attachments

(2 files)

During the FTU process, User can chooses to opt-out of Metric collection. The FTU ping should contain this info of whether User opt-out out of Metric collection. This helps better estimation of monthly active users.
Assignee: nobody → thills
Ravi, When you say opt-out of metric collection, you mean turn off the app usage ping, correct? Can you make sure that you and Jonas, as the Data Stewards, sign off on this addition to the FTU ping? Marshall
Flags: needinfo?(rdandu)
Marshall, Yes, this is on the agenda for next data stewards meeting.
Flags: needinfo?(rdandu)
Status: NEW → ASSIGNED
Dominik/Ravi, Since it looks like we are going with Option 7 in Bug 1181295, how is something like this for the additional flag in the payload: { . . . "metricsLevel: "none|basic|advanced" . . . }
Flags: needinfo?(rdandu)
Flags: needinfo?(dstrohmeier)
Looks good to me. Just to understand: metricsLevel: none would be that no data is shared, i.e. full opt-out, correct?
Flags: needinfo?(dstrohmeier)
Tamara, metricsLevel: "none|basic|enhanced" (enhanced instead of advanced). "none" is no data is collected. i.e full opt-out.
Flags: needinfo?(rdandu)
Blocks: 1226182
Dominik/Dave, Is this modification to FTU format ok? I added the metricsLevel there. I think it will be good to start tracking this. Values will be as per Ravi's Comment 5. { "ver": 1, "info": { "screenHeight": 569, "screenWidth": 320, "devicePixelRatio": 1.5, "preinstalled": { "https:\/\/marketplace.firefox.com\/packaged.webapp": "Marketplace", .... }, "activationTime": 1453937770044, "metricsLevel": "Enhanced", "deviceinfo.os": "2.6.0.0-prerelease", "deviceinfo.software": "Boot2Gecko 2.6.0.0-prerelease", "deviceinfo.product_model": "flame", "deviceinfo.firmware_revision": "", "deviceinfo.hardware": "qcom", "network": { "operator": "T-Mobile", "mnc": "260", "mcc": "310" }, "icc": { "mnc": "260", "mcc": "310", "spn": null }, "pingID": "EC22E144", "pingTime": 1453938072329, "locale": "en-US", "reason": "ftu", "appName": "FirefoxOS", "appUpdateChannel": "default", "appBuildID": "20160119113430", "appVersion": "46.0a1" } }
Flags: needinfo?(dzeber)
Flags: needinfo?(dstrohmeier)
Hi Tamara, looks ok to me. That this will be a good enough way to track this and to get an idea about the general opt-in/activation ratio.
Flags: needinfo?(dstrohmeier)
Attached file PR for 1198164 (deleted) —
Hi Sam, I'm wondering if you can take a look at my WIP changes to ftu_launcher.js. Essentially, we want to capture the user's input on the metricsLevel and send it along with the Ftu ping. They can either choose "none", "Basic", or "Enhanced". This is the last step in the FTU. However, the packet needs to be kicked off after the user has made the choice. I don't see any bad implications to kicking the ensurePing function to the "finish" step, but wanted to check if you think there can be something i'm overlooking here. From my testing, it appears there is no way to get out of the FTE without executing the "finish" function. Thanks, -tamara
Attachment #8713212 - Flags: feedback?(sfoster)
finish() is also called by this.service.request('FtuLauncher:skip'), i.e. every startup. Which I think is not what you want? If you want to ensure you get called only on first time use, after the user had made choices in the FTU UI, it looks like the close() method is a better place - which is called specifically when the FTU app has terminated.
Attachment #8713212 - Flags: feedback?(sfoster)
Thanks Sam. That makes sense.
Comment on attachment 8713210 [details] [gaia] tamarahills:bugfix/1198164-Include-metricsLevel-in-FtuPing > mozilla-b2g:master Hi Russ, Would you mind feedbacking this for me? Thanks, -tamara
Attachment #8713210 - Flags: feedback?(rnicoletti)
Comment on attachment 8713210 [details] [gaia] tamarahills:bugfix/1198164-Include-metricsLevel-in-FtuPing > mozilla-b2g:master lgtm, one nit.
Attachment #8713210 - Flags: feedback?(rnicoletti) → feedback+
Comment on attachment 8713210 [details] [gaia] tamarahills:bugfix/1198164-Include-metricsLevel-in-FtuPing > mozilla-b2g:master Hi Marshall, This patch includes an element in the FtuPing to include what metricsLevel the user chose during the FTE. They can choose None|Basic|Enhanced. Thanks, -tamara
Attachment #8713210 - Flags: review?(marshall)
Comment on attachment 8713210 [details] [gaia] tamarahills:bugfix/1198164-Include-metricsLevel-in-FtuPing > mozilla-b2g:master Looks good, I just had a question about the naming of the constant in the pull request.
Attachment #8713210 - Flags: review?(marshall) → review+
Gij11 and Gij18 appear to be broken for a while, so I'll go ahead and merge. I addressed Russ' and Marshall's suggestions. https://treeherder.mozilla.org/#/jobs?repo=gaia&revision=6a3d65dad6155059bb52aab8548ba12cbe701aef&selectedJob=3489625 Thanks, -tamara
Flags: needinfo?(dzeber)
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: