Closed
Bug 1037495
Opened 11 years ago
Closed 10 years ago
Telemetry support for App Usage Metrics in FxOS
Categories
(Firefox OS Graveyard :: Gaia::System, defect)
Tracking
(blocking-b2g:2.2+, tracking-b2g:-, b2g-v2.2 fixed, b2g-master fixed)
People
(Reporter: marshall, Assigned: marshall)
References
Details
(Whiteboard: tracking-b2g: 2.2 blocking)
Attachments
(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,
'developer.menu.enabled': 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:
'homescreen.gaiamobile.org': {
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
'gallery.gaiamobile.org': 1, // gallery handled an activity once
'wallpaper.gaiamobile.org': 4 // wallpaper app handled activity 4 times
}
},
// more app data here
}
}
Comment 1•11 years ago
|
||
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.
}
| Assignee | ||
Comment 2•10 years ago
|
||
Per mreid, it looks like we'll also need to update the URL scheme to:
/submit/telemetry/<uuid>/reason/appname/appversion/channel/buildid
| Assignee | ||
Comment 3•10 years ago
|
||
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)
| Assignee | ||
Comment 4•10 years ago
|
||
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]
}
}
| Assignee | ||
Comment 5•10 years ago
|
||
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)
Comment 6•10 years ago
|
||
[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)
Comment 7•10 years ago
|
||
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.
Comment 8•10 years ago
|
||
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 | ||
Updated•10 years ago
|
Assignee: nobody → marshall
Component: Telemetry Server → Gaia::System
Product: Webtools → Firefox OS
Target Milestone: --- → 2.2 S5 (6feb)
Version: Trunk → unspecified
| Assignee | ||
Updated•10 years ago
|
blocking-b2g: --- → 2.2?
Comment 9•10 years ago
|
||
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+
Updated•10 years ago
|
Attachment #8555994 -
Flags: review?(fabrice) → review+
Comment 10•10 years ago
|
||
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 11•10 years ago
|
||
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-
Updated•10 years ago
|
Updated•10 years ago
|
Flags: in-moztrap?(slyu)
| Assignee | ||
Comment 12•10 years ago
|
||
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 13•10 years ago
|
||
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 14•10 years ago
|
||
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-
Comment 15•10 years ago
|
||
Blocking in B2G triage based on importance of correct payload format.
blocking-b2g: 2.2? → 2.2+
| Assignee | ||
Comment 16•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 17•10 years ago
|
||
| Assignee | ||
Comment 18•10 years ago
|
||
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)
| Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Updated•10 years ago
|
Keywords: checkin-needed
Updated•10 years ago
|
Attachment #8566742 -
Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+
Comment 19•10 years ago
|
||
status-b2g-v2.2:
--- → fixed
status-b2g-master:
--- → fixed
Target Milestone: 2.2 S5 (6feb) → 2.2 S6 (20feb)
Comment 20•10 years ago
|
||
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+
Comment 21•10 years ago
|
||
Updated•10 years ago
|
Flags: in-moztrap?(slyu) → in-moztrap+
You need to log in
before you can comment on or make changes to this bug.
Description
•