Firefox OS/Metrics/App Usage: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (Moved from main page)
mNo edit summary
Line 110: Line 110:


See [[FirefoxOS/Metrics/App Usage]]
See [[FirefoxOS/Metrics/App Usage]]
=High Level Requirements=
#Product Planning: Need to know the number of devices sold. This will help product decisions be data driven.
#User Benefit: knowing the following information will improve security updates and app functionality
## Build IDs, Country, Operator, OEM, Version of HW: These are needed for Device Updates and Security patches: When a bug is found, or a security risk is detected, they need to be sent as an update to the particular OEM, Operator.
##Screen Height, Width, Pixel density: This is needed for CoreApps development (Gallery, Camera, Dialer, Browser) and 3rd party apps. These apps need to know the screen sizes, resolutions that they would need to support.
==Delta to what exists today in Marketplace Ping==
#Information:
##ActivationPing gives the total number of "sold"(activated) FFOS devices, whereas current ADI ping gives the number of devices connected to WiFi on a particular day
###Product planning needs the information about devices sold (ActivatioPing). Current ADI ping approximated devices active on a certain day on WiFi. Difference gives us an idea of retention of product, and engagement of user.. This will help us focus on what is causing the dropoff, investigate why certain markets are doing better/worse, and making data-driven investments in improving the retention
##Activation Ping has additional information on Build IDs, Country, Operator, OEM, Version of HW, Screen Size, Screen Height, Width, Pixel density. While the previous ADI ping contains the model of device.
#Reliability:
##Current Ping from 1.3 shows approx 5 devices reporting as of March 24th 2014. https://dataviz.mozilla.org/views/ADI_Ping_1_3/HistoricalADITrend#2
#Cost:
##From previous versions, Partners removed ADI ping due to cost concern. Activation Ping is sent once in lifetime of device, which should have allay cost concerns.

Revision as of 05:13, 3 February 2015

Summary

Links

Requirements

For all system and 3rd party apps, track:

  1. Total time that each app (by URL) has been actively been used (in the foreground while the screen is on)
  2. Counts for the number of times an app has been opened, closed, or crashed
  3. A list of apps that have been uninstalled since the last successful report

Design

The App Updates Metrics (AUM) service actively collects usage information by hooking into several system events. The determination of running time of an app looks something like this:

  • When an app is opened, or the user switches to the homescreen, AUM marks it as the currently running app, and records the current time
  • When the device is locked, the display goes to sleep, or another app is opened, AUM records the delta of the current time with the current app's start time
  • When the device is unlocked after the display was sleeping, the current app's start time is reset to the current time so we don't record usage time while the screen was off/locked
  • AUM also records installs, uninstalls, and and activity invocations (on activity URLs -- not running time) of apps

When the device is idle and and any of these registered events occur:

  • AUM will save the currently collected metrics to async storage
  • If the device is also online and a specified interval has passed (default 24 hours), AUM will begin attemping to transmit the stored metrics to the Telemetry server
  • If transmission fails, then a separate retry interval (default 1 hour) controls how often AUM will retry transmission until it is successful

Example Payload and URL

POST https://fxos.telemetry.mozilla.org/submit/telemetry/metrics/FirefoxOS/appusage
{
    "apps": {
        "app://verticalhome.gaiamobile.org/manifest.webapp": {
            "activities": {},
            "installs": 0,
            "invocations": 1,
            "uninstalls": 0,
            "usageTime": 23
        }
    },
    "deviceID": "j2670k6q",
    "deviceinfo": {
        "developer.menu.enabled": true,
        "deviceinfo.platform_build_id": "20140902135234",
        "deviceinfo.platform_version": "34.0a1",
        "deviceinfo.update_channel": "unknown"
    },
    "locale": "en-US",
    "screen": {
        "devicePixelRatio": 1.5,
        "height": 569,
        "width": 320
    },
    "start": 1411567451826,
    "stop": 1411577295717
}

Glossary

apps Usage for each app in this batch (these are not aggregates), keyed by the app's manifest URL
installs The number of app installs
uninstalls The number of app uninstalls
invocations The number of times the app was started
usageTime The total number of seconds the app was used
deviceID A randomly generated deviceID to help server side de-duplication. This is separate from any other ID in the system, including the FTU activation ping
deviceinfo
developer.menu.enabled Whether or not this is a 'production' build
deviceinfo.platform_build_id The timestamp that gecko was built
deviceinfo.platform_version The version string of gecko
deviceinfo.update_channel Update channel used for FxOS OTA updates
locale Platform locale string, i.e. 'en-US'
screen
devicePixelRatio ratio of physical pixels to virtual pixels on the device
width screen width in CSS pixels
height screen height in CSS pixels
start UNIX device timestamp of when this batch of metrics started recording
stop UNIX device timestamp of when this batch of metrics stopped recording

Notes

  • The size of the JSON payload that we send to the telemetry server seems to be between 1KB-3KB on average.

App usage metrics

See FirefoxOS/Metrics/App Usage