On Wednesday night I spoke at the Facebook Developer Garage in London on 'Jumping the Shark', based on mathematical analysis by Andrew Chen. See my presentation at the bottom of the post - I have written up the essentials of my talk below.
Slide 2: this is the 'shark fin', a graph showing the exponential growth and then equally fast fall in active users over time - this could be daily active users of a Facebook application, but could also refer to other time periods such as a week or month, and could apply to web sites or other viral applications.
Slide 4: Network saturation causes a slow down in new user growth, and eventual plateau. With Facebook applications, this can be seen easily by considering the following: if in each time period your current users send out 10 new invites, and you have a 10% conversion rate, then at 0% saturation all ten of the invites will be sent to new users, and you will acquire 1 new user for each current user in each time period. However, as the network becomes more saturated this conversion rate will lower - at 50% saturation, 5 of every 10 invites will go to users who either already have the application, or who have already rejected it. Thus, your 10% conversion rate will only apply to the 5 new users, so you'll get 0.5 new users for each current user in each time period.
Slide 5: You may think that, with 60m users, it would be almost impossible for any one Facebook application to hit its 'carrying capacity', i.e. full network saturation. However, the average user on Facebook does not have a social graph equally spread across the whole Facebook ecosystem. Instead, they will exist within 1-3 closely knit networks. The picture in the slide is a visual representation of my own social graph on Facebook, using an application called nexus. The large radial curve shows my former university, Durham, where you can see very heavy connections between all users. Likewise, the small curve shows my hometown, Malvern, which is equally interconnected.
If a developer seeds an application to their own social graph, it is likely to only gain traction in the networks he is heavily connected to. So, for example, the Durham University network has 24,000 users - if only 10% of users are likely to install your application, this leaves a total carrying capacity of any application only seeded to Durham University of 2,400. Of course, you could be lucky, and the application may spread to other networks, but the chance of this is much lower.
Slide 6: Once new user growth has slowed or plateaued, it is left to the retention rate to ensure that any application maintains a high active user base. The graph shows how at 99% retention rate the active user base steadily falls off once new user growth has stopped.
Slide 7: Although 50% retention rate may sound high, once your new user acquisition has slowed or stopped, this will create a dramatic fall in active users, down to almost nothing in the same time period it took for your userbase to grow to its peak - creating the shark fin.
Slide 9: There are a number of ways to prevent the 'shark fin'. The first is to ensure that you have the maximum carrying capacity possible - this means that an application must be seeded early into as many different and diverse networks as it can. For some applications you may be able to do this by seeding to fan pages - even if these only have a few thousand fans, they are likely to be from diverse networks, and are more likely than other users to install a relevant application. If you don't have access to a fan page, then advertising, either with banner ads or social ads around Facebook, or by using application advertising networks, is the only way to ensure that your application is widely seeded (you could also use traditional advertising or other channels to reach your current customers).
Once you've ensured a high carrying capacity, you then need to ensure that your application has a clear retention loop. The Facebook application platform is great for viral loops, with applications able to build in newsfeed stories and invite requests into the fabric of the application. However, although this is fine for growing the installed user base, to maintain a high active user base you must have a clear retention loop that keeps users coming back. This is a serious pitfall that many applications on Facebook have fallen into - and without a continuing active user base, there's no-one to market to or to click on adverts.
It's extremely important that you measure your retention rates from day 1, and test the effect of changes to the application on retention rate. Although the drop off is disguised by exponential growth during the initial phase, the drop off is still happening, and if you wait until active users have dropped off the other side of the shark fin then even if you fix the retention loop you will have less active users than otherwise. Thus, you need to ensure the retention loop is working as early as possible to ensure that you hit the maximum number of active users you can, and keep them.
If you're interested in the maths I'd advise you to check out Andrew Chen's post on this, especially his notes about cohort analysis for testing retention rate over time.
5 comments:
Fascinating stuff but I have been playing with the spreadsheet and got some anomalous results.
Try:
Invite Conversion @ 10%
Avg Invites @ 23
INitial user base @ 2,500
Carrying capacity @ 250,000
You get an odd sawtooth which I don't understand. Any ideas what is going on here?
Hi,
Thanks for your comment - I'll take a look at this. Was that invites per user per time period, or average per user overall?
Josh
I'll email you the XLS I've got.
Hi Paul,
Thanks for the spread sheet.
This is due to a mathematical error. The growth algorithm is allowing the user base to exceed carrying capacity. Because the conversion rate is worked out as 1 - [saturation %] * 10% when the saturation% exceeds 100% the conversion rate becomes negative, causing it to create a drop in users. The same problem then again causes the new users to exceed the carrying capacity again so the same happens. This just needs some jiggying around to ensure that whatever initial numbers you put in the cumulative users can never exceed carrying capacity.
Although this is a 'mathematical error', it does actually have a cross over to real life - if you drive your viral loop too hard (e.g forced invites etc) then you're likely to gain more users than reflects the natural carrying capacity for your application, and these users are likely to drop off/uninstall the app very quickly.
Hi Josh - yes, that looks like a reasonable pathway. I agree that this would reflect the "real world" in this way. Nice anomolous activity! Thanks for looking at it for me.
Post a Comment