Given the consistently upward pressure exerted on CPI (cost-per-install) prices over the past six months — which, in my opinion, will not likely change any time soon — many mobile app developers are increasingly focusing on virality as a means of user acquisition. The benefits of high virality (k-factor) in a mobile app are obvious: not only are referred users free, but they also tend to monetize and retain better than acquired users, especially in multiplayer apps and apps with strong communities. But k-factor is difficult to measure in mobile, especially compared to the web, where users can be tracked via URLs.
First, a definition: k-factor is the viral growth rate of an app on a per-user basis.
A k-factor of one or more represents truly viral growth. But how can k-factor be measured on mobile, where the invitation channel is usually disconnected from the app’s platform? The obvious answer is that it can’t unless app developers build viral mechanics that are inherently measurable, like claimable rewards, community structures, or web-based registration funnels. But these approaches are all core functional features that need to be designed into an app from the very early stages of development. K-factor for an app which hasn’t been specifically designed to accommodate measuring virality can only be approximated using sampling and conversion estimation.
The component of k-factor that is unequivocally measurable is the invitation mechanism: an app developer should have no problem counting the exact number of times users invited other people to download the app using in-app mechanics. Starting from this number, the app developer must apply some conversion rate to invitations to come up with viral installs. This is understandably more art than science, but the goal of measuring k-factor isn’t to cut the marketing budget but rather to improve upon viral mechanics. With this understood, extrapolating a conversion rate from within the first-session funnel to viral invitations isn’t unreasonable, since they’re both fundamentally describing the same thing: after having been superficially introduced to the app, how many users continue to engage?
Another approach to approximating k-factor is to simply count any non-referred install as the result of virality; i.e. instead of counting viral installs from the bottom up, count them from the top down. This approach isn’t conceptually flawed since any organic install isn’t necessarily not the result of virality, but it will almost certainly lead to an inflated k-factor value that, at the very least, will downplay the need to devote resources to engineering more virality. I wouldn’t employ this approach, but it’s slightly more scientific than simply adopting the conversion rate from another process in the app.
Because k-factor has such important implications for the cost of user acquisition, measuring it accurately is a priority. But the cost of measuring k-factor with total precision is high, since it requires engineering around the foundation of the mobile platform. And given the choice between building convoluted, web-based registration processes that provide for absolute k-factor measurement and using frictionless registration processes that don’t provide much precision to the k-factor calculation, I’d choose the latter. K-factor is merely instructive: it lets an app developer know how much work they need to dedicate to viral mechanics to achieve virality.
Recent