An Engineer’s Guide to App Metrics

Building and shipping a successful product takes more than raw engineering. I have been posting a bit about using Telemetry to learn about how people interact with your application so you can optimize use cases. There are other types of data you should consider too. Being aware of these metrics can help provide a better focus for your work and, hopefully, have a bigger impact on the success of your product.

Active Users

This includes daily active users (DAUs) and monthly active users (MAUs). How many people are actively using the product within a time-span? At Mozilla, we’ve been using these for a long time. From what I’ve read, these metrics seem less important when compared to some of the other metrics, but they do provide a somewhat easy to measure indicator of activity.

These metrics don’t give a good indication of how much people use the product though. I have seen a variation metric called DAU/MAU (daily divided by monthly) and gives something like retention or engagement. DAU/MAU rates of 50% are seen as very good.


This metric focuses on how much people really use the product, typically tracking the duration of session length or time spent using the application. The amount of time people spend in the product is an indication of stickiness. Engagement can also help increase retention. Mozilla collects data on session length now, but we need to start associating metrics like this with some of our experiments to see if certain features improve stickiness and keep people using the application.

We look for differences across various facets like locales and releases, and hopefully soon, across A/B experiments.

Retention / Churn

Based on what I’ve seen, this is the most important category of metrics. There are variations in how these metrics can be defined, but they cover the same goal: Keep users coming back to use your product. Again, looking across facets, like locales, can provide deeper insight.

Rolling Retention: % of new users return in the next day, week, month
Fixed Retention: % of this week’s new users still engaged with the product over successive weeks.
Churn: % of users who leave divided by the number of total users

Most analysis tools, like iTunes Connect and Google Analytics, use Fixed Retention. Mozilla uses Fixed Retention with our internal tools.

I found some nominal guidance (grain of salt required):
1-week churn: 80% bad, 40% good, 20% phenomenal
1-week retention: 25% baseline, 45% good, 65% great

Cost per Install (CPI)

I have also seen this called Customer Acquisition Cost (CAC), but it’s basically the cost (mostly marketing or pay-to-play pre-installs) of getting a person to install a product. I have seen this in two forms: blended – where ‘installs’ are both organic and from campaigns, and paid – where ‘installs’ are only those that come from campaigns. It seems like paid CPI is the better metric.

Lower CPI is better and Mozilla has been using Adjust with various ad networks and marketing campaigns to figure out the right channel and the right messaging to get Firefox the most installs for the lowest cost.

Lifetime Value (LTV)

I’ve seen this defined as the total value of a customer over the life of that customer’s relationship with the company. It helps determine the long-term value of the customer and can help provide a target for reasonable CPI. It’s weird thinking of “customers” and “value” when talking about people who use Firefox, but we do spend money developing and marketing Firefox. We also get revenue, maybe indirectly, from those people.

LTV works hand-in-hand with churn, since the length of the relationship is inversely proportional to the churn. The longer we keep a person using Firefox, the higher the LTV. If CPI is higher than LTV, we are losing money on user acquisition efforts.

Total Addressable Market (TAM)

We use this metric to describe the size of a potential opportunity. Obviously, the bigger the TAM, the better. For example, we feel the TAM (People with kids that use Android tablets) for Family Friendly Browsing is large enough to justify doing the work to ship the feature.

Net Promoter Score (NPS)

We have seen this come up in some surveys and user research. It’s suppose to show how satisfied your customers are with your product. This metric has it’s detractors though. Many people consider it a poor value, but it’s still used quiet a lot.

NPS can be as low as -100 (everybody is a detractor) or as high as +100 (everybody is a promoter). An NPS that is positive (higher than zero) is felt to be good, and an NPS of +50 is excellent.

Go Forth!

If you don’t track any of these metrics for your applications, you should. There are a lot of off-the-shelf tools to help get you started. Level-up your engineering game and make a bigger impact on the success of your application at the same time.

Fun With Telemetry: URL Suggestions

Firefox for Android has a UI Telemetry system. Here is an example of one of the ways we use it.

As you type a URL into Firefox for Android, matches from your browsing history are shown. We also display search suggestions from the default search provider. We also recently added support for displaying matches to previously entered search history. If any of these are tapped, with one exception, the term is used to load a search results page via the default search provider. If the term looks like a domain or URL, Firefox skips the search results page and loads the URL directly.


  1. This suggestion is not really a suggestion. It’s what you have typed. Tagged as user.
  2. This is a suggestion from the search engine. There can be several search suggestions returned and displayed. Tagged as engine.#
  3. This is a special search engine suggestion. It matches a domain, and if tapped, Firefox loads the URL directly. No search results page. Tagged as url
  4. This is a matching search term from your search history. There can be several search history suggestions returned and displayed. Tagged as history.#

Since we only recently added the support for search history, we want to look at how it’s being used. Below is a filtered view of the URL suggestion section of our UI Telemetry dashboard. Looks like history.# is starting to get some usage, and following a similar trend to engine.# where the first suggestion returned is used more than the subsequent items.

Also worth pointing out that we do get a non-trivial amount of url situations. This should be expected. Most search keyword data released by Google show that navigational keywords are the most heavily used keywords.

An interesting observation is how often people use the user suggestion. Remember, this is not actually a suggestion. It’s what the person has already typed. Pressing “Enter” or “Go” would result in the same outcome. One theory for the high usage of that suggestion is it provides a clear outcome: Firefox will search for this term. Other ways of trigger the search might be more ambiguous.


Firefox for Android: Collecting and Using Telemetry

Firefox 31 for Android is the first release where we collect telemetry data on user interactions. We created a simple “event” and “session” system, built on top of the current telemetry system that has been shipping in Firefox for many releases. The existing telemetry system is focused more on the platform features and tracking how various components are behaving in the wild. The new system is really focused on how people are interacting with the application itself.

Collecting Data

The basic system consists of two types of telemetry probes:

  • Events: A telemetry probe triggered when the users takes an action. Examples include tapping a menu, loading a URL, sharing content or saving content for later. An Event is also tagged with a Method (how was the Event triggered) and an optional Extra tag (extra context for the Event).
  • Sessions: A telemetry probe triggered when the application starts a short-lived scope or situation. Examples include showing a Home panel, opening the awesomebar or starting a reading viewer. Each Event is stamped with zero or more Sessions that were active when the Event was triggered.

We add the probes into any part of the application that we want to study, which is most of the application.

Visualizing Data

The raw telemetry data is processed into summaries, one for Events and one for Sessions. In order to visualize the telemetry data, we created a simple dashboard (source code). It’s built using a great little library called PivotTable.js, which makes it easy to slice and dice the summary data. The dashboard has several predefined tables so you can start digging into various aspects of the data quickly. You can drag and drop the fields into the column or row headers to reorganize the table. You can also add filters to any of the fields, even those not used in the row/column headers. It’s a pretty slick library.


Acting on Data

Now that we are collecting and studying the data, the goal is to find patterns that are unexpected or might warrant a closer inspection. Here are a few of the discoveries:

Page Reload: Even in our Nightly channel, people seem to be reloading the page quite a bit. Way more than we expected. It’s one of the Top 2 actions. Our current thinking includes several possibilities:

  1. Page gets stuck during a load and a Reload gets it going again
  2. Networking error of some kind, with a “Try again” button on the page. If the button does not solve the problem, a Reload might be attempted.
  3. Weather or some other update-able page where a Reload show the current information.

We have started projects to explore the first two issues. The third issue might be fine as-is, or maybe we could add a feature to make updating pages easier? You can still see high uses of Reload (reload) on the dashboard.

Remove from Home Pages: The History, primarily, and Top Sites pages see high uses of Remove (home_remove) to delete browsing information from the Home pages. People do this a lot, again it’s one of the Top 2 actions. People will do this repeatably, over and over as well, clearing the entire list in a manual fashion. Firefox has a Clear History feature, but it must not be very discoverable. We also see people asking for easier ways of clearing history in our feedback too, but it wasn’t until we saw the telemetry data for us to understand how badly this was needed. This led us to add some features:

  1. Since the History page was the predominant source of the Removes, we added a Clear History button right on the page itself.
  2. We added a way to Clear History when quitting the application. This was a bit tricky since Android doesn’t really promote “Quitting” applications, but if a person wants to enable this feature, we add a Quit menu item to make the action explicit and in their control.
  3. With so many people wanting to clear their browsing history, we assumed they didn’t know that Private Browsing existed. No history is saved when using Private Browsing, so we’re adding some contextual hinting about the feature.

These features are included in Nightly and Aurora versions of Firefox. Telemetry is showing a marked decrease in Remove usage, which is great. We hope to see the trend continue into Beta next week.

External URLs: People open a lot of URLs from external applications, like Twitter, into Firefox. This wasn’t totally unexpected, it’s a common pattern on Android, but the degree to which it happened versus opening the browser directly was somewhat unexpected. Close to 50% of the URLs loaded into Firefox are from external applications. Less so in Nightly, Aurora and Beta, but even those channels are almost 30%. We have started looking into ideas for making the process of opening URLs into Firefox a better experience.

Saving Images: An unexpected discovery was how often people save images from web content (web_save_image). We haven’t spent much time considering this one. We think we are doing the “right thing” with the images as far as Android conventions are concerned, but there might be new features waiting to be implemented here as well.

Take a look at the data. What patterns do you see?

Here is the obligatory UI heatmap, also available from the dashboard:

Zippity Update – Telemetry

I updated Zippity, our crowd sourcing data collection system, to add support for memory and CPU data telemetry. What is memory and CPU data telemetry you ask? Basically, we send data about the current Firefox Mobile memory and CPU usage patterns to Zippity. There are two ways to send the data:

  • Manually push a button: This might be a handy way to report metrics when you think Firefox Mobile is running slow on your phone.
  • Silently on idle once a day: During an idle moment, Zippity scans the metrics. This gives us data on the Firefox Mobile resting state. Hopefully we don’t see large CPU usage. Just install the Zippity add-on, and you start sending data – no additional work for you!

Why send this data you ask? We care a lot of the performance of Firefox Mobile, and we want to better understand how Firefox Mobile is running on your phone. We run a lot of tests at Mozilla, but these tests sometimes don’t compare well to the real world. For example, I have no performance issues running Firefox Mobile on my Nexus One, but we get lots of feedback from users that the performance is too slow on their phones. We need to run tests and collect data from Firefox Mobile running on your phone.

What kind of data is sent you ask? Firefox Mobile has a built-in memory reporting system and Zippity will enumerate that system to get detailed memory usage data. We also use the Linux /proc system to get information about the CPU usage. We only check the Firefox main and child processes. We don’t log any information about other processes. Thanks to Brad Lassey and Taras Glek for helping me get the data collected. Here is an example of the JSON formatted data sent to Zippity:

    "product": "Fennec 6.0a1",
    "os": "Android",
    "buildid": "20110416004121",
    "type": "metrics",
    "date": 1303152081000,
    "testkey": "telemetry-v1",
    "appid": "{a23983c0-fd0e-11dc-95ff-0800200c9a66}",
    "device": "Nexus One",
    "userkey": "",
    "osversion": "REL (10)",
    "data": {
        "reason": "manual",
        "malloc/allocated": 32377108,
        "malloc/mapped": 34603008,
        "malloc/committed": 34603008,
        "malloc/dirty": 77824,
        "js/gc-heap": 5242880,
        "js/string-data": 514630,
        "js/mjit-code": 88500,
        "storage/sqlite/pagecache": 4536536,
        "storage/sqlite/other": 1050816,
        "storage/permissions.sqlite/LookAside_Used": 29,
        "storage/permissions.sqlite/Cache_Used": 99208,
        "storage/permissions.sqlite/Schema_Used": 1272,
        "storage/permissions.sqlite/Stmt_Used": 5744,
        "storage/extensions.sqlite/LookAside_Used": 438,
        "storage/extensions.sqlite/Cache_Used": 428248,
        "storage/extensions.sqlite/Schema_Used": 6928,
        "storage/extensions.sqlite/Stmt_Used": 119024,
        "gfx/surface/image": 1088248,
        "images/chrome/used/raw": 0,
        "images/chrome/used/uncompressed": 1025124,
        "images/chrome/unused/raw": 0,
        "images/chrome/unused/uncompressed": 3648,
        "images/content/used/raw": 0,
        "images/content/used/uncompressed": 2144,
        "images/content/unused/raw": 4168,
        "images/content/unused/uncompressed": 8288,
        "layout/all": 563338,
        "storage/places.sqlite/LookAside_Used": 143,
        "storage/places.sqlite/Cache_Used": 428488,
        "storage/places.sqlite/Schema_Used": 11704,
        "storage/places.sqlite/Stmt_Used": 44152,
        "content/canvas/2d_pixel_bytes": 81120,
        "storage/cookies.sqlite/LookAside_Used": 14,
        "storage/cookies.sqlite/Cache_Used": 165000,
        "storage/cookies.sqlite/Schema_Used": 1816,
        "storage/cookies.sqlite/Stmt_Used": 0,
        "storage/formhistory.sqlite/LookAside_Used": 14,
        "storage/formhistory.sqlite/Cache_Used": 197920,
        "storage/formhistory.sqlite/Schema_Used": 1656,
        "storage/formhistory.sqlite/Stmt_Used": 0,
        "storage/addons.sqlite/LookAside_Used": 152,
        "storage/addons.sqlite/Cache_Used": 296616,
        "storage/addons.sqlite/Schema_Used": 4280,
        "storage/addons.sqlite/Stmt_Used": 29152,
        "storage/search.sqlite/LookAside_Used": 20,
        "storage/search.sqlite/Cache_Used": 99192,
        "storage/search.sqlite/Schema_Used": 1216,
        "storage/search.sqlite/Stmt_Used": 1840,
        "shmem/allocated": 0,
        "shmem/mapped": 0,
        "storage/index.sqlite/LookAside_Used": 148,
        "storage/index.sqlite/Cache_Used": 296656,
        "storage/index.sqlite/Schema_Used": 3032,
        "storage/index.sqlite/Stmt_Used": 51704,
        "uptime": 159848,
        "process": {
            "parent": {
                "user": 13,
                "system": 2,
                "rss": 77456
            "child": {
                "user": 22,
                "system": 2,
                "rss": 25132
            "cpu": 57

You can now access Metrics charts on Zippity to view the data. Trying to find ways to visualize the data isn’t easy. There is a lot of data. The charts are simple for now. The data point tooltip shows more detailed information.

Visit Zippity from your phone and install the add-on today. Thanks for using Zippity to help us collect data to make Firefox Mobile better.

Firefox 3 – Offline App Demo

Firefox 3’s offline capabilities have been getting some attention lately: Chris Double’s post on porting Zimbra to use offline shows-off the potential. Robert O’Callahan and John Resig give details on the different pieces of the capabilities, namely: Offline Cache, Offline Events and DOMStorage.

A Simple Demo – Task Helper

I put together a simple offline application sample to help illustrate how the features can work. Call it – explanation through code. The application is a simple task list system. The current functionality includes:

  • Add tasks – Enter text in field and press ‘Add’
  • Complete tasks – Mark completed tasks and press ‘Complete’
  • Remove tasks – Mark tasks and press ‘Remove’
  • Data is stored as JSON and XHR is used to interact with server (PHP)


Nothing fancy. However, the application is “offline-aware”, meaning:

  • Application resources (HTML & JS) are tagged as offline cacheable
  • Before interacting with server, online status is checked. If online, use XHR. If offline, use DOMStorage
  • Online/Offline status is monitored using events. When the application switches form offline to online, data is resync’ed with the server

There is really nothing fancy about the offline stuff either, but putting it all together does make for a neat application. Using the latest Firefox 3 alpha, you should be able to:

  • Use the application while online.
  • Go offline using the “Work Offline” menu. The event log should show that the app went offline
  • Continue to use the application while offline
  • Go online using the “Work Offline” menu. The event log should show that the app is back online and has updated the server with any offline changes

If you were using a version of Firefox 3 with the offline cache patch (bug 367447) you would be able to a little more:

  • Use the application while online.
  • Go offline using the “Work Offline” menu. The event log should show that the app went offline
  • Continue to use the application while offline
  • Restart browser
  • Switch to offline (or have no network connection)
  • Enter URL to app (or use a bookmark)
  • Start using app with data from last session
  • Switching to online will update the server with offline data

Currently, the offline events only fire when offline is toggled via the “Work Offline” menu. Getting the events to fire by watching the network connection is the goal and would make this much more unobtrusive for the user.

Here is the source to the task helper application:

I am My Data, My Data is Me

I couldn’t help but get caught up in the recent threads about data lock-in. I have become quite a “data-snob” recently which, I’m finding, is quite abnormal for a developer. Developers are all about the code. On one side you have the Mark Pilgrim & Jon Gruber (& Mark’s reply) discussing Apple’s data lock-in problems. On the other side you have Stewart Butterfield’s not-so-positive comments about allowing Flickr to export to Zooomr or Google’s new online Photo Ablums.

Lots of people are making the connection that these different threads have much in common: People use software to store important data; The data belongs to the people, not the software. This is not about Mac vs. Ubuntu or Flickr vs. Google. It’s about users feeling secure that their data won’t rot away in some application’s proprietary file format.

Is it any wonder that people are more at ease storing photographs in a shoebox than on a computer? It’s easy to take the photos out of the shoebox and move them to a photo album, or to a picture frame. How easy it is to move your photos and metadata to newer software? Or your letters, or your finanical information, or your tax returns?

Things are getting better. Microformats, Atom, and a desire for applications (specifically web applications) to interoperate is raising the bar. Even Microsoft Office finally has a relatively open format with full fidelity. Full fidelity is important or else you’ll lose data when you try to convert to another format. Software developers need to realize that the data will live longer than the software and there should be a simple, easy way to access the data without the software. Until then, your data may not be safe.