Firefox OS/Metrics

FTU ping

Design of Activation Ping

1. Activation Ping is triggered through the first-time use experience / activation.
2. Never pings again once it is successful (unless the phone's "userdata" partition is formatted through the recovery partition, but this is not a case we support generally, it means wiping all of the user's data)
3. Can also be disabled, but requires extra work on top of disabling app updates or removing the Firefox marketplace app

Details

When a device is first activated, The FTU ping service sends a simple one-off HTTP request to our telemetry server. The HTTP request contains a JSON payload with some high level information about the device and network, but no unique hardware identifiers. A randomly generated pingID is sent to help with filtering on the server side, but this ID is discarded by the server once filtering has occurred (generally after 24 hours).

Currently, the logic for the FTU ping is broken down like this:

1. Unless the setting ftu.pingEnabled is explicitly set to false, start the FTU ping service. If the setting is missing, or any other value, then the ping service is enabled.
2. Lazily get or create a randomly generated pingID, which is used for server side filtering. This pingID is only generated once per device, and is discarded on the server side.
3. Record the time the ping service started, to track the delta of time to a successful ping.
4. Pull all relevant ping payload settings asynchronously.
5. Create an interval timer to attempt a ping once an hour. This is configurable with ftu.pingTryInterval.
   1. Check for availability of voice network information. If none is available, try again on the next interval. If this fails 24 times, then continue trying the ping until is successful. This is configurable in the setting ftu.pingMaxNetworkFails.
   2. Send an HTTP request to FTU_PING_URL/PING_ID/ftu/FirefoxOS/VERSION/UPDATE_CHANNEL/BUILD_ID. By default, the ping URL is https://fxos.telemetry.mozilla.org, and is configurable in the ftu.pingURL setting, or via make with FTU_PING_URL.
      1. If the HTTP request succeeds, set ftu.pingEnabled to false, and disable the interval timer. Otherwise, try again on the next interval.

Example payload and URL

POST https://fxos.telemetry.mozilla.org/submit/telemetry/e426da9f-2a29-4e09-895b-c883903956cb/ftu/FirefoxOS/31.0a1/default/20140325104133

{
    "activationTime": 1395769944966,
    "devicePixelRatio": 1,
    "deviceinfo.firmware_revision": "",
    "deviceinfo.hardware": "qcom",
    "deviceinfo.os": "1.5.0.0-prerelease",
    "deviceinfo.platform_build_id": "20140325104133",
    "deviceinfo.platform_version": "31.0a1",
    "deviceinfo.product_model": "ALCATEL ONE TOUCH FIRE",
    "deviceinfo.software": "Boot2Gecko 1.5.0.0-prerelease",
    "deviceinfo.update_channel": "default",
    "icc": {
        "mcc": "310",
        "mnc": "410",
        "spn": null
    },
    "locale": "en-US",
    "network": {
        "mcc": "310",
        "mnc": "410",
        "operator": "AT&T"
    },
    "pingID": "e426da9f-2a29-4e09-895b-c883903956cb",
    "pingTime": 1395852542588,
    "screenHeight": 480,
    "screenWidth": 320
}

Testing tips

Testing the FTU ping can be tedious and time consuming with the default settings. Here's a few things you can do to make it better:

• When using build.sh or make, set FTU_PING_URL to a local IP so you can monitor the http request, i.e: cd gaia; make FTU_PING_URL=... reset-gaia
• Set DEBUG = true in gaia/apps/system/js/ftu_ping.js to see messages at various stages of the ping lifecycle, and the raw ping data when it is actually sent
• Change DEFAULT_TRY_INTERVAL in gaia/apps/system/js/ftu_ping.js to something much smaller than 1 hour (i.e. 15 seconds)

High Level Requirements

1. Product Planning: Need to know the number of devices sold. This will help product decisions be data driven.
2. User Benefit: knowing the following information will improve security updates and app functionality
   1. 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.
   2. 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

1. Information:
   1. 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
      1. 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
   2. 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.
2. Reliability:
   1. 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
3. Cost:
   1. From previous versions, Partners removed ADI ping due to cost concern. Activation Ping is sent once in a lifetime, which should allay cost concerns.