Closed Bug 1037495 Opened 7 years ago Closed 6 years ago

Telemetry support for App Usage Metrics in FxOS


(Firefox OS Graveyard :: Gaia::System, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:2.2+, tracking-b2g:-, b2g-v2.2 fixed, b2g-master fixed)

2.2 S6 (20feb)
blocking-b2g 2.2+
tracking-b2g -
Tracking Status
b2g-v2.2 --- fixed
b2g-master --- fixed


(Reporter: marshall, Assigned: marshall)



(Whiteboard: tracking-b2g: 2.2 blocking)


(3 files)

Just like we do for FTU pings, we'll need to make sure we can support payloads being submitted by the app usage metrics service in Gaia which recently landed in 2.1.

Currently, payloads look like this (I realize we may need to update this)

      start: timestamp of batch start time (in millisecond format),
      stop: timestamp of batch end time,
      deviceID: "0i9n4ffh" // a unique id used to link batches together,
      locale: "en_US" // the user's language from navigator.language,
      screen: {
        width: the screen width in css pixels,
        height: the screen height in css pixels,
        devicePixelRatio: device pixels per css pixel
      deviceinfo: {
        'deviceinfo.update_channel': update channel,
        'deviceinfo.platform_version': gecko version number (I think)
        'deviceinfo.platform_build_id': more version details,
        '': if true user probably has abnormal app usage patterns!
      apps: {
         // the properties of this object are application origins and the values of those properties are
         // the usage data for those applications.  For example:
         '': {
           usageTime: total app usage time during this reporting period, in seconds
           invocations: number of times the app has been opened in this period
           installs: number of times this app has been installed in this period
           uninstalls: number of times this app has been uninstalled in this period
           activities: { // the activity handlers this app has invoked, and how many times
             '': 1,    // gallery handled an activity once
             '': 4   // wallpaper app handled activity 4 times
         // more app data here
Please add top-level keys for:

ver: 1
info: {
  reason: whatever reason you want to use for the app usage metrics pings
  appUpdateChannel: nightly, aurora, beta, release, etc
  appBuildID: build id
  appName: FirefoxOS
  appVersion: 33.0a1
  // Any other info keys such as "locale" can go here too, but please
  // try to match field names with existing telemetry payloads.
Per mreid, it looks like we'll also need to update the URL scheme to:
Updating AppUsageMetrics to use the proper URL and data format meant copying quite a bit of code from the FTU ping, so instead I factored that code out into a shared Telemetry module. In the future this module should handle getting the proper settings automatically, but I wanted to bring a little bit of sanity before going too deep down the rabbit hole.

Other than the new shared code (and updating AUM / FTU ping to use it, there are a handful of other changes I'd like a sanity check on:

* AppUsageMetrics now uses uuid() to generate it's Device ID, since AFAICT the Telemetry server requires a UUID in it's URL format. This also now matches FTU ping

* For the FTU ping, we used version number of '3' for the FTU ping so the Telemetry server could shuffle data from the payload into the proper 'info' key. I've changed this back to '1', because the FTU ping and AUM are now using the same code to construct the Telemetry URL and payload

* Some unit tests that were in ftu_ping_test.js have been removed in favor of tests that now exist indepently in telemetry_test.js
Attachment #8555994 - Flags: review?(fabrice)
Attachment #8555994 - Flags: review?(etienne)
Attachment #8555994 - Flags: review?(dflanagan)
Attachment #8555994 - Flags: feedback?(slyu)
Attachment #8555994 - Flags: feedback?(mreid)
Attachment #8555994 - Flags: feedback?(dzeber)
Shing, just a heads up that this change will rearrange the data slightly for both AppUsageMetrics and FTU ping, since the data is now being properly formatted for the Telemetry server. In general, the change takes the form of:

  ver: 1,
  info: {
    reason: (ftu|appusage)
    appName: 'FirefoxOS',
    appUpdateChannel: 'x',
    appVersion: 'x',
    appBuildID: 'x',

    [all other AUM or FTU ping payload data we are used to seeing will go here]
Ravi, can you mark this as blocking for 2.2? We need to make sure that App Usage Metrics is using the right URL and payload format for the Telemetry Server.
Flags: needinfo?(rdandu)
[Tracking Requested - why for this release]: We need App Usage Metrics for 2.2 release as it is essential to compute Monthly Active Usage (MAU). MAU is critical metric identified by Mozilla management to track across Mozilla products this year.
tracking-b2g: --- → ?
Flags: needinfo?(rdandu)
This is 2.2 blocking. Since the component is telemetry, blocking-b2g flag is not showing up on the bugzilla to note there. Ccing Kevin Hu, and Bhavana Bajaj on the bug to track it for 2.2.
QA Whiteboard: 2.2
Whiteboard: tracking-b2g: 2.2 blocking
Comment on attachment 8555994 [details] [review]
Factor out common telemetry code (pull request)

This looks good to me - I commented on the version-change back from V3 to V1, but my question is answered by comment 3.

Generally the "id" used in Telemetry is expected to be a document id, not a device id, though pretty much any non-empty string will do. You could just generate a new uuid for each submission if you prefer.

If possible, could you post a sample payload + submission URL here so I can test it?
Attachment #8555994 - Flags: feedback?(mreid) → feedback+
Assignee: nobody → marshall
Component: Telemetry Server → Gaia::System
Product: Webtools → Firefox OS
Target Milestone: --- → 2.2 S5 (6feb)
Version: Trunk → unspecified
blocking-b2g: --- → 2.2?
Comment on attachment 8555994 [details] [review]
Factor out common telemetry code (pull request)

I like the (thin and well tested) TelemetryRequest a lot, and the move to a true uuid() was probably overdue, so r+ for me!

(I'd like to see an integration test for the ftu_ping eventually but its a bit outside of the scope of this bug.)
Attachment #8555994 - Flags: review?(etienne) → review+
Attachment #8555994 - Flags: review?(fabrice) → review+
Comment on attachment 8555994 [details] [review]
Factor out common telemetry code (pull request)

Looks good to me too. Please post a sample payload when you get a chance so we can get an idea of what it looks like now.
Attachment #8555994 - Flags: feedback?(dzeber) → feedback+
Comment on attachment 8555994 [details] [review]
Factor out common telemetry code (pull request)

r- from me because you don't handle the upgrade case from 2.1 where a device already has a deviceID that is not a uuid. 

And TelemetryRequest.sendRequest() modifies the object that is passed in. If that object is reused, there won't be a proper timeout.

I did not attempt to review the FTU changes or the tests because I'm not familiar with those.

Overall, though, this looks good, and if you fix the issues identified above, I'll be happy to give r+
Attachment #8555994 - Flags: review?(dflanagan) → review-
Blocks: 1109422, 1126524
Blocks: 1129060
Flags: in-moztrap?(slyu)
Comment on attachment 8555994 [details] [review]
Factor out common telemetry code (pull request)

Hey David, I'm using a different string for the DEVICE_ID_KEY to simply force a new UUID to be created for v2.1->v2.2 users, and no longer deleting the timeout key, amongst your other suggestions.. Do you want to take a look back over the PR before I land it?
Attachment #8555994 - Flags: review?(dflanagan)
Comment on attachment 8555994 [details] [review]
Factor out common telemetry code (pull request)

I have not tried testing this code, but you've addressed my issues from last time, and it looks good to me.
Attachment #8555994 - Flags: review?(dflanagan) → review+
Comment on attachment 8555994 [details] [review]
Factor out common telemetry code (pull request)

Removing the old (and now out-dated) r-. Not sure why bugzilla has me down for two different reviews
Attachment #8555994 - Flags: review-
Blocking in B2G triage based on importance of correct payload format.
blocking-b2g: 2.2? → 2.2+
master -
Closed: 6 years ago
Resolution: --- → FIXED
Comment on attachment 8566742 [details] [review]
[gaia] marshall:bug1037495_sharedTelemetry_v2.2 > mozilla-b2g:v2.2

Updates URL and payload format for AppUsageMetrics and FTU ping

[Bug caused by] (feature/regressing bug #):Bug 1037495

[User impact] if declined: AppUsageMetrics will continue to post to a wrong path on the Telemetry server

[Testing completed]: new unit tests, and verified data was properly received on the telemetry server w/ Dave Zeber

[Risk to taking this patch] (and alternatives if risky): Code for building the Telemetry URL and payload have been put in a common place, which means a new component.

[String changes made]: None
Attachment #8566742 - Flags: approval-gaia-v2.2?(bbajaj)
Attachment #8566742 - Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+
Comment on attachment 8555994 [details] [review]
Factor out common telemetry code (pull request)

Clear my flag since it has been merged
Attachment #8555994 - Flags: feedback?(slyu) → feedback+
Attached file MozTrap Cases
Flags: in-moztrap?(slyu) → in-moztrap+
You need to log in before you can comment on or make changes to this bug.