The Viral Coefficient, and Why K Above 1 Almost Never Happens

K is two small numbers multiplied together

The definition is short: K = i × c, where i is the number of invitations an average user sends and c is the fraction of those invitations that turn into a new user. Both factors are measured over the same population and the same window, and both are small in almost every real product. Five invitations at a 10% conversion rate is K = 0.5. Ten invitations at 5% is also K = 0.5. Notice how hard the target of 1 is: at a 10% invitation conversion rate you need more than ten accepted-through invitations per user; at 5% you need more than twenty. Products that genuinely sustained a K above 1 did so by making the invitation part of the core action — you could not use the thing without sending one — and even then only while the addressable pool was still empty.

The reason K above 1 is rare is structural rather than a matter of effort. It is a product of two fractions, and improving either one is hard: invitations sent per user is limited by how many relevant contacts a person has and by how willing they are to spend social capital, while invitation conversion is limited by how well the message travels out of context. Doubling a 5% conversion rate to 10% is a serious achievement; it takes you from K = 0.25 to K = 0.5, which is a real gain and still nowhere near 1. Plan for the improvement, not for the threshold.

Below 1 the loop is a finite multiplier: 1/(1−K)

Start with 1,000 users and a K of 0.7. They invite, and 700 join. Those 700 invite, and 490 join. Then 343, then 240, then 168, then 118. The generations shrink by a factor of K each time, so the running total is a geometric series: 1,000 × (1 + 0.7 + 0.7² + 0.7³ + …) = 1,000 ÷ (1 − 0.7) = 3,333. That closed form, 1/(1−K), is the number people actually want when they ask what a referral loop is worth. It says one paid user brings 3.33 users in total when K is 0.7, and 2 users in total when K is 0.5.

The multiplier is brutally non-linear near 1, and that is where most planning goes wrong. Going from K = 0.2 to K = 0.5 raises the multiplier from 1.25 to 2. Going from 0.5 to 0.7 raises it from 2 to 3.33. Going from 0.7 to 0.9 raises it from 3.33 to 10. The last step is a smaller improvement in K than the first and a far bigger improvement in outcome — which sounds like an argument for chasing 0.9, until you look at how long it takes to collect. That is the next section, and it is the one that changes decisions.

Cycle time: why a K of 0.7 beats a K of 0.9 for three months

The viral coefficient has no time in it. It tells you how big the total gets, never how fast. Cycle time — the average lag between a user joining and the users they invite joining — supplies the missing axis, and the two numbers together decide everything. Put a K of 0.7 on a one-day cycle against a K of 0.9 on a thirty-day cycle, and watch the same 1,000-user cohort under each.

The fast loop, K = 0.7 with one cycle a day, stands at 1,700 users after day 1, 2,190 after day 2, 2,533 after day 3 and 3,059 after day 6. By day 30 it has essentially finished, at 3,333. The slow loop, K = 0.9 with one cycle every thirty days, has completed exactly one generation by day 30: 1,000 + 900 = 1,900 users. On day 60 it reaches 2,710. It does not pass 3,000 until day 90, where it stands at 3,439. So the loop with the lower coefficient reaches 3,000 users on day 6 and the loop with the higher coefficient reaches it on day 90 — fifteen times longer, from a coefficient that is 29% better.

Be precise about what that proves, because the slow loop is not simply worse. Its ceiling is far higher: 10,000 users against 3,333, and it overtakes the fast loop at around day 85. By day 365 it stands at 7,458 and is still climbing. So the honest statement is that cycle time dominates the first quarter and the coefficient dominates the long run — and for a company deciding what to build this quarter, the first quarter is usually the one that pays salaries. Halving your cycle time costs an engineering sprint on the invitation flow; raising K from 0.7 to 0.9 usually requires changing what the product is.

Why K above 1 does not stay above 1

Above 1 the series stops converging and the loop compounds: a 1,000-user cohort at K = 1.1 reaches 64,002 after twenty cycles and 487,852 after forty. That is the case everyone wants and almost nobody sustains, because K is not a constant of the product — it is a measurement taken against a particular population at a particular moment. As adoption spreads, invitations increasingly land on people who already have an account, and the conversion term c falls. K falls with it, crosses 1 from above, and the loop settles into the finite-multiplier regime. Diffusion models have described this shape since Frank Bass published his product growth model in 1969, and Andrew Chen's essays on Facebook-era app growth document exactly what it felt like from inside a platform when it happened.

The operational consequence is that a K measured on your earliest, most enthusiastic cohort is the most flattering K you will ever see, and it is not the one to plan on. Measure it per cohort and watch the trend. A K that is 0.8 in the first month and 0.4 six months later is not a broken referral programme; it is the ordinary arithmetic of a pool that is filling up.

The realistic goal: a sub-1 K that lowers blended acquisition cost

Stop treating 1 as a pass mark and the metric becomes immediately useful. If you pay $60 to acquire a customer and each paid customer brings 1/(1−K) customers in total, your blended cost per customer is 60 × (1 − K). A K of 0.2 takes it to $48. A K of 0.5 takes it to $30. A K of 0.7 takes it to $18. Those are enormous improvements to unit economics achieved entirely below the threshold everyone fixates on, and they show up in the same place a paid channel would: in the ratio between lifetime value and acquisition cost, and in how quickly that cost is repaid.

One caveat keeps that calculation honest. Referred users are not free — a referral programme usually pays a reward on both sides, and that reward belongs in the acquisition cost of the referred customer. Subtract it before you celebrate. If a $20 two-sided reward buys you a K of 0.5, your blended cost is 60 × 0.5 + 20 × 0.5 = $40, not $30, because half your customers now arrive with a $20 incentive attached. It is still a large improvement on $60; it is simply not the improvement the coefficient alone advertises.

Measuring K without flattering yourself

Three mistakes account for most inflated coefficients. The first is counting every new user as viral when only the ones carrying a referral token are. The second is measuring i and c over different windows — invitations sent this month against conversions from invitations sent at any time — which mixes a small numerator with a large denominator or the reverse. The third is measuring across the whole user base rather than by cohort, which lets a single early spike keep the average high for a year.

The clean method is boring and works. Take a cohort defined by join week. Count the invitations that cohort sent within a fixed window, count the users those specific invitations produced, divide, and record the pair (K, cycle time) with the cohort's date attached. Do that every week and you get a trend rather than a trophy — and the trend is what tells you whether the loop is improving, or whether the pool is simply still fresh.

Frequently asked questions

What is a good viral coefficient?

Any K you can measure honestly and sustain is good, because the value is continuous rather than pass-or-fail. A K of 0.2 already multiplies every acquired user by 1.25 and cuts a $60 paid acquisition cost to $48. A K of 0.5 doubles the cohort and cuts the cost to $30. Treating 1 as the target discards all of that, and 1 is nearly unreachable because K is the product of two small fractions.

How do I calculate the viral coefficient?

Take one cohort, defined by the week its members joined. Divide the invitations that cohort sent within a fixed window by the size of the cohort to get i. Divide the new users produced by exactly those invitations by the number of invitations to get c. Multiply: K = i × c. Then compute the total the cohort will generate as cohort size ÷ (1 − K), and record the average lag between an invitation and the resulting signup — that is your cycle time, and it matters as much as K.

What is viral cycle time and why does it matter so much?

It is the average lag between a user joining and the users they invite joining. K tells you how big the total becomes; cycle time tells you when. A K of 0.7 on a one-day cycle reaches 3,059 users from a 1,000-user cohort by day 6 and finishes at 3,333. A K of 0.9 on a thirty-day cycle is only at 1,900 by day 30 and does not pass 3,000 until day 90 — fifteen times slower to the same milestone, even though its eventual ceiling of 10,000 is three times higher.

Can a product keep K above 1 permanently?

No, because K is measured against a pool that fills. Above 1 the loop compounds — a 1,000-user cohort at K = 1.1 reaches 64,002 after twenty cycles — but as adoption spreads, invitations increasingly reach people who already joined, the conversion term falls, and K crosses back below 1. That decay is the normal shape of product diffusion, not a failure of execution. Measure K per cohort and read the trend rather than the peak.

Should I optimise the coefficient or the cycle time first?

Cycle time, almost always, because it is cheaper to move and it dominates the near term. Shortening the lag between joining and inviting is usually a change to the invitation flow: prompt earlier, remove a step, let an invitation land without an account. Raising K from 0.7 to 0.9 generally means changing what the product does for the invited person. In the worked comparison the faster loop is ahead until about day 85; if your planning horizon is a quarter, that is the whole horizon.