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.

uitelemetry-screenshot-crop

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:
uitelemetry-heatmap

12 Replies to “Firefox for Android: Collecting and Using Telemetry”

  1. For me, the “Try again” button ends up disabled very often for some reason, so manually reloading is the only way out.

  2. I don’t know what can be done about it, but I use reload all the time on mobile. Firefox has some knowledge of “offline” and “online”, but doesn’t deal well with the reality of rapid switching between offline, online and connection speeds varying from 5KB/s to 350KB/s. If a page that I know can load in 6-8 seconds hasn’t loaded in 30 seconds or so, then I know I have a much better chance of getting the page by starting again, instead of waiting another 30 seconds. I don’t know if Firefox can know that though… Good that a project has started to investigate, anyway.

  3. To add to what Michael said, mobile Firefox seems to have also an “auto-detection” of Internet connectivity of sorts which is annoying on private networks where it insists it’s offline and refuses to load anything until you force-reset it, and then it works again for a minute or two.

  4. As a user of Nightly on Android, I certainly reload a lot. The major reason is that pages regularly don’t load properly the first time. This is usually because:
    – when I opened the tab (perhaps from Twitter) I didn’t have connectivity
    – I did have connectivity, but FF’s DNS resolving was misbehaving because of past lack of connectivity
    – FF was quit by the OOM manager on Android, and on restore some tab failed to load (see previous connectivity discussion).

    In general, mobile connectivity is bad, and Firefox’s is worse, so reloading is often needed.

  5. @Sam – Improving Firefox’s network connectivity behavior is one of the projects we’ve started to address the “reload” usage. Thanks for the additional feedback. Always appreciated.

  6. @Dan, @Mark – Me too, I typically intend to scroll the page but the gesture is interpreted as a long tap. Then the browser freezes for half a second before showing the selection handles. I often accidentally bring up the context menu of images.

  7. re: Opening links from other applications

    What really, really hurts the experience here is the decision to not focus new tabs automatically. There is a bug about the general issue of getting some sort of check box, so new tabs can be focused automatically. (Which was closed wontfix because the tab bar is apparently mostly used used as a read-later list… which to me is not really an argument either way. But well…)
    In any case, whenever a new tab is open from another application, please focus it!

Comments are closed.