A User’s Experience when Downloading Firefox

We recently reinitiated Funnelcake, an effort begun in 2007 to better understand the full cycle of a user’s experience — from visiting www.mozilla.com all the way through to becoming a long-term Firefox user.  We are currently shipping Funnelcake roughly once per month, and we have some new insights to share based on some numbers from November’s edition.

You may recall that, last year, much of our analysis focused on the attrition or churn rate over time, i.e., what are the odds that a new user today continues using Firefox a month from today or six months from today?

For this discussion, we want to focus on another area – what is the experience of a new user at the precise moment he/she clicks on the download button?

At first glance, this may seem like an ultra simple thing to examine.  However, there are indeed different hoops a user has to navigate through at this moment in their experience.  Once a user clicks the download button, he/she is shown a dialog screen related to running or saving the .exe file.  At this moment, two things can happen:

  1. A user succeeds in getting that download file
  2. The user does not receive the full and complete file

Looking at our download mirror data, it appears that roughly 79% of people enjoy success (#1) and about 21% of users experience the latter (#2).

The next step in a user’s experience applies to group #1.  Moving forward, two things can happen to this user:

  1. The user can launch/run the installation file, successfully go through all the steps during installation, and complete the installation process
  2. The user does not complete installation

Looking at the data again, we see that of the users at this stage in the process, 79% of people enjoy success through the installation steps, whereas 21% do not (the 79-21 numbers repeating here is just a coincidence).

An alternate view of this user experience would be to ask, “for every 100 people who initiate the download process, where exactly do they end up just a few moments later?”  Looking at the diagram below, you can see that roughly 21 abandon the process when they don’t receive the full download file, 63 receive the download file and complete the installation process, and 17 receive the download file but don’t complete installation.

So, what are the business insights here?

There are likely some actions we can take to improve the user’s experience during the download and installation process.  I was surprised by the 21% number above… much more digging needs to be done to ensure this is fully accurate and to break this down further (e.g., by OS, by browser, etc.), so that we can start to consider product or UI related changes.  With respect to the 17% number above, we are already taking action.  With the help of Kampyle (a tool for these users to provide feedback), we’re eager to soon have some insights into the potential pain points or thoughts of users at this precise moment in their experience.

15 responses

  1. Adam wrote on :

    If that number is indeed correct, a solution may be to have the installer also act as the downloader using a protocol which is more fault tolerant (like bit torrent).

  2. Dave wrote on :

    I think Google solved it’s 21% loss problem by making the click on the download button pop-up it’s installer. Check out getting crome. You click download and the installer pops up.

    Try it yourself.
    Could firefox test a similar install?

  3. Ant Bryan wrote on :

    Luckily the Firefox download is relatively small. Download failures are annoying. We try to give them every chance to succeed with Metalink: mirrors, checksums, etc.

    Check out how openSUSE uses them for ISO downloads: http://lizards.opensuse.org/2008/12/16/best-way-to-download-opensuse/

  4. Tristan wrote on :

    Ken, great post, as usual. Keep them coming! What you post here is invaluable for the Open Source community.

  5. Dan wrote on :

    I would guess that most of the 21% who don’t finish downloading the file are on slower connections. The download file is over 7 MB now on Windows whereas it used to be less than 5. Work in decreasing the size of download total should be started, or even just decreasing the size of the initial download and then having a stub download further data (like Dave mentions above) would be good.

  6. Staś Małolepszy wrote on :

    Would it be possible for the .exe to be a small (less than 1 MB) downloader of the real installer? Personally I’m not a fan of this solution (mostly because rarely anyone bothers to give the exact information on the download size), but maybe it is something that we could test?

    This is how I see it:

    1. The user clicks “Download” on mozilla.com. The download box has the information about the download size: “Download Firefox – Free 3.0.5 for Windows, English (US) (300KB now, 7MB later)

    2. The 300KB downloader is saved on the user’s computer. The small size of the downloader minimizes the risk of interrupting the download or getting an incomplete file.

    3. The downloader is run from user’s computer (either automatically after the download finishes, or manually by the user — for this reason it should have an icon with the Firefox logo, but still visually different from the icon we use for the browser).

    4. The downloader downloads the real installer (~7MB). It has the ability to pause and resume download.

    5. Once the real installer is downloaded, the downloader closes and the installer opens, enabling the user to continue with the installation.

    A possible problem is that after the installation, there are three icons on the user’s desktop: the downloader, the installer and the Firefox shortcut.

  7. bc wrote on :

    Dan has a great point especially on Mac where the download size is 17M due to the universal builds. It would take a dialup user an hour or more to download a Mac build.

  8. Ted Mielczarek wrote on :


    Note that Google cheats here, because they install a “Google Update” plugin with any of their Google desktop software, which has the side-effect of letting them do 1-click installs from Firefox. (Personally this scares the shit out of me.)

  9. nthomas wrote on :

    Does the analysis of the d/l failure rate include people who retry ? I would expect some proportion would try again in the case of a transmission error or server timeout.

  10. kkovash wrote on :


    Good question! We did try to incorporate this user experience into our findings. From the mirror data, we’re able to consider download requests where the user doesn’t get the full data. Specifically, we looked at the number of builds worth of bytes we shipped under this scenario, which means that we pushed enough data equivalent to X many builds. These “effective downloads” represent an upper bound number of downloads for users retrying, so we incorporated a certain percentage into the numbers presented above.


  11. Matthew Holloway wrote on :

    My parents had a slow dialup connection and I couldn’t grab Firefox 3 on that machine. I ended up bringing the files over on a USB drive.

    Downloading OpenOffice.org was even more problematic.

  12. Robert Strong wrote on :

    Just a small nit: the number possible for the dropoff number for the installer is actually the total minus the number of incomplete downloads which makes the installer dropoff rate closer to 18%

  13. Ted Mielczarek wrote on :

    I wonder if it’s worth creating a simple script that could try downloading the installer and email a warning somewhere if it failed (noting the mirror that it was downloading from). Then we could get this script running on a regular basis, and see if there’s any sense to the data. Are certain mirrors failing more often? From certain ISPs?

  14. Alexander wrote on :

    Agree with Dave, instead of a download then install procedure, a one click download/install like Google’s chrome is a far better, quicker and easier solution for the user. 🙂

  15. darkhole wrote on :

    Maybe, you can simply change the Installer Icon.
    It’s very generic, and many people don’t know that tis is an installer.
    I’m using Linux, and don’t have this problem. But a icon file very personal to Firefox is a good decision.