I start with this Wikipedia ” entry about k-factor on purpose. Certainly, in theory it is all right. However, this is just a high-brow theory. In real life, this k-factor should be calculated during the entire lifetime of a project, from the launch till the closure. This formula corresponds to the “global” k-factor, which nobody really needs, aside from the security service of a venture capital fund who try to find out why this or that startup has gone dead.
In real life, what we are interested in is the “local” k-factor (the term is borrowed from “Freemium Economics” by Eric B. Seufert), i.e., the value calculated during a certain period of time. For example, within my approach, I use weekly factors, thus using the “weekly k-factor”. Moreover, in our case the statement that the project grows or collapses exponentially, if the value of the k-factor exceeds or falls short of unity, respectively, is wrong!
However, Richard Fond, the author of the Bliss Drive blog , and the Wikipedia entry, and even Harry Harrison in his story called “The K-factor” fail to allow for many factors. Borrowing the term blindly from nucleonics and epidemiology, they assume that merely “infecting” a newcomer is sufficient to expand the user database. In reality, how a project retains existing users is more important than how fast it grows. And the ways, which are used to retain users, should also enter the formula.
K-factors of actual projects rarely exceed unity, for long periods of time, anyway. A normal current value of the K-factor for a successful and growing project at any given time moment is equal to 10%, 20%, or 30%, and the project is thriving at that, despite the fact that it should collapse, according to the classical formula. But why? Because it is not a nuclear explosion or a plague in a population of mice, where the death rate is 100% of the infected animals. The thing is that in the normal project, the “infected” users continue using the project and even attract new customers in the following time period. This can be regarded as a different factor, namely, k-retention being the ratio of the number of the users, who use the service repeatedly during the current period, as compared with the previous period. This parameter will be always less than unity, since some users will be lost anyway. Even in such environments as a prison or North Korea, this factor fails to reach unity due to release of inmates, mortality, and escapes.
The real, “fundamental” coefficient, which shows the natural dynamics of the project, is the sum of the above-specified factors, specifically, k-factor and k-retention. If the total exceeds 1, the project grows, if it is less, the number of loyal users decreases.
Additionally, I call for using only “active” users when calculating these factors, i.e., those who, rather than being just passive visitors, perform some purposeful actions typical of the project, game or service under consideration. For example, for a drawing service, it is creation and saving of a new sketch, for a game, playing through at least one level, etc. Only then we will obtain unbiased evaluations of our parameters.
For instance, if we create a virtual prison, we should count only the prisoners who have real prison terms, rather than adding all their relatives, guards, controllers, investigators and lawyers. The latters are random factors in this game.
Fair and equitable calculations will show that for a good project, the k-factor will equal to about 10% (if it is higher, accept my congratulations!), and the k-retention, to about 90%. The sum of these parameters will yield the sought-for value of 1, the stability level, when the project neither grows, nor withers away. The only thing to be done here would be to increase at least one of the parameters by 1% to make the project to increases by 1% daily or weekly.
It is known that the daily growth rate of 1% yields a 37-fold increase per year. ☺
PS: I call the sum of the above-said two factors the “f-growth”
In real life, what we are interested in is the “local” k-factor (the term is borrowed from “Freemium Economics” by Eric B. Seufert), i.e., the value calculated during a certain period of time. For example, within my approach, I use weekly factors, thus using the “weekly k-factor”. Moreover, in our case the statement that the project grows or collapses exponentially, if the value of the k-factor exceeds or falls short of unity, respectively, is wrong!
However, Richard Fond, the author of the Bliss Drive blog , and the Wikipedia entry, and even Harry Harrison in his story called “The K-factor” fail to allow for many factors. Borrowing the term blindly from nucleonics and epidemiology, they assume that merely “infecting” a newcomer is sufficient to expand the user database. In reality, how a project retains existing users is more important than how fast it grows. And the ways, which are used to retain users, should also enter the formula.
K-factors of actual projects rarely exceed unity, for long periods of time, anyway. A normal current value of the K-factor for a successful and growing project at any given time moment is equal to 10%, 20%, or 30%, and the project is thriving at that, despite the fact that it should collapse, according to the classical formula. But why? Because it is not a nuclear explosion or a plague in a population of mice, where the death rate is 100% of the infected animals. The thing is that in the normal project, the “infected” users continue using the project and even attract new customers in the following time period. This can be regarded as a different factor, namely, k-retention being the ratio of the number of the users, who use the service repeatedly during the current period, as compared with the previous period. This parameter will be always less than unity, since some users will be lost anyway. Even in such environments as a prison or North Korea, this factor fails to reach unity due to release of inmates, mortality, and escapes.
The real, “fundamental” coefficient, which shows the natural dynamics of the project, is the sum of the above-specified factors, specifically, k-factor and k-retention. If the total exceeds 1, the project grows, if it is less, the number of loyal users decreases.
Additionally, I call for using only “active” users when calculating these factors, i.e., those who, rather than being just passive visitors, perform some purposeful actions typical of the project, game or service under consideration. For example, for a drawing service, it is creation and saving of a new sketch, for a game, playing through at least one level, etc. Only then we will obtain unbiased evaluations of our parameters.
For instance, if we create a virtual prison, we should count only the prisoners who have real prison terms, rather than adding all their relatives, guards, controllers, investigators and lawyers. The latters are random factors in this game.
Fair and equitable calculations will show that for a good project, the k-factor will equal to about 10% (if it is higher, accept my congratulations!), and the k-retention, to about 90%. The sum of these parameters will yield the sought-for value of 1, the stability level, when the project neither grows, nor withers away. The only thing to be done here would be to increase at least one of the parameters by 1% to make the project to increases by 1% daily or weekly.
It is known that the daily growth rate of 1% yields a 37-fold increase per year. ☺
PS: I call the sum of the above-said two factors the “f-growth”