The Eject Rate

Thoughts By 6 years ago

On the b2cloud website we pay attention to the number of users who visit and leave the site soon after (a.k.a Bounce rate), but I’m interested in the phenomenon of users downloading apps, and quickly deleting them. This is far more severe than a bounce, and I call this the Eject Rate.

A bounce implies that a user has found your website using a search engine, clicked a link, read some relevant content and pressed back to continue researching. The time investment might be seconds, or even a minute.

An app on the other hand requires the user to find it using search on a phone, press the result to access a description page, read text, view screenshots, press download, enter a password, wait for the download, find the icon, open the app and then access content. The time investment can often be minutes and large amounts of download bandwidth.The eject phenomenon happens when a user quickly exits the app, and then deletes it completely. Very bad!

Ill cover two aspects of the Eject Rate, how to calculate it and what can cause it.

How to calculate Eject Rate

This is by no means an exact science as such data isn’t provided to developers. But there are some tell tale signs:

  1. Sales Vs. Upgrades from iTunes Connect – After releasing an App and an update, simply divide upgrades by total sales. Using one of our apps for example upgrades (36,381), divided by Sales (75,299) equals 48%. Meaning the App has an Eject Rate of 52%. This is a conservative number as some users just don’t update Apps but may continue to use them.
  2. Retained Users from Flurry Analytics – Another indicator can be retained users, how many users have opened the App again within 7 days of downloading it. A b2cloud client example could be 2,690 new users in a week, 820 have returned which equals an Eject Rate of 69.5%

Some business logic is required in these calculations meaning some Apps don’t have daily appeal. For instance I infrequently use public transport but when I do, I open Tram Tracker. This could happen once a month. Therefore consider the realistic frequency of use for an App.

What increases Eject Rate

  1. Crashes – Put simply, if an App crashes or doesn’t retain a users data when its expected to, it will be deleted very quickly. A small percentage of innovative users may wait for updates, most will not give you a second chance
  2. Performance – App developers connecting to databases via API often choose to host content in the US to save on cost. Latency, slow ping and load times will frustrate users and cause them to Eject. A b2cloud built App that connected to a US hosting provider took on average 8 seconds to render search results, in contrast to our local server which took 2 seconds!
  3. Nagware – I believe Will is covering this in his blog post today and its the concept of forcing users to sign up on first load of an App with personal information. How does a user know if they want to invest their information when they haven’t taken a test drive!
  4. Feels Wrong! – Developers that cross compile or wrap Apps using Titanium often release Apps that just don’t feel right on any platform. Buttons don’t depress, bouncing table views are laggy and jittery and the whole experience doesn’t feel like native Mail, calendar and weather.

In summary, ensure an App has long term appeal and is built elegantly and without shortcuts. The result will be a low Eject Rate and many hundreds of thousands of happy users!