Virality as a topic has been covered extensively on Mobile Dev Memo over the years; for a primer, see this article and this YouTube video. Calculating virality (captured in the k-factor metric) ex post is fairly straightforward; if proper attribution is in place and no major promotional campaigns were live (like television ads or app store featuring), then an analyst might just measure the number of paid installs and divide the number of organic or non-paid installs into them, deriving the k-factor as below (all examples are from this spreadsheet):
Once the k-factor is measured over the course of some number of periods, it could be projected forward over a greater number of periods, producing the holy grail of app marketing: compounding viral growth (since the viral users each period beget even more viral users the next period). A projection of that might look like this:
It’s easy to see how projections like this could become ridiculous over the course of a few periods: forward virality graphs tend to always look similar, featuring impressive exponential growth as a result of compounding. But usually the k-factors used to model that viral growth are static over a very long projection period (sometimes years!). This simple graph shows a growth projection with a k-factor of 1 (meaning: each new users recruits one additional user to the app) applied to 25 periods, with 100 paid users added each period:
A k-factor of 1 or more produces exponential growth, which is what all companies aspire to achieve with their app. And growth for many apps, especially those with strong social features, actually is exponential over some stage of their lifecycles, which makes for impressive pitch decks and financial projections.
But exponential growth is usually indicative of a specific period in an app’s life when exuberant early adopters are promoting it to small circles of people that find the app most relevant and engaging. By definition this moment in an app’s history is fleeting; it’s obvious that exponential growth can’t last forever, but the more disheartening realization is that can’t even usually last very long. Yet it’s incredibly common to see developers project their growth out with bowed lines like the one above because, on a DAU base of just a few thousand users, the app has grown exponentially for a few weeks or months.
The reality for most apps is that virality is like a flame: the hotter it burns, the faster it exhausts the oxygen it needs to stay alive. There’s a maximum install limit for viral growth for any app: it might be 100,000 installs or it might be 100MM, but it exists, and projecting viral growth beyond that number merely sets unrealistic expectations and delays the process of thinking about growth strategically. At the very least, a robust growth model should factor in reductions to virality over time (as the most relevant users get burned through and viral growth slows). To be more realistic, a developer might factor in a ceiling to viral growth (a “saturation point”) and model their virality like an S curve, with viral growth slowing as the cumulative number of viral installs reaches the saturation point. The graph below models the same scenario above but with viral installs shrinking in proportion to the progress that total cumulative viral installs have made against the saturation point (set here at 10,000):
This is not as appealing as the graph above, but it’s more realistic: virality slows down over time as it approaches some natural limit. A viable business can be built on this kind of assumption, but the permanent up-and-to-the-right assumption in the graph above actually prevents any kind of methodological thinking from taking place because endless, impressive growth is just a natural feature of that product.