A viral loop is a product mechanism where existing users bring in new ones, and the K-factor measures how well it works: average invites sent per user multiplied by the share of invites that turn into new users. Above 1.0, each user brings in more than one more and growth compounds without paid acquisition. Below 1.0 the loop still lowers the cost of growth, which is often the more realistic goal.
How it works
The arithmetic is simple. If the average user sends three invites and one in five converts, K is 0.6. The hard part is counting.
Invites leave through email, share links, copied URLs, embedded content and integrations, and each path tends to be built by a different team at a different time. A K-factor built from the original email invite undercounts every path added since.
Dave Boyce's Freemium calls the same quantity R0, average invites per user times invite conversion, and argues that virality above 1 is useful but not required, because invited users cost almost nothing to acquire and pull blended acquisition cost down either way (Ch 7). Whichever name a team uses, the inputs are the same two counts, and both have to be complete.
What it assumes your events already do
| Event | What the framework uses it for | What it reports when the event breaks |
|---|---|---|
Invite sent and acceptedinvite_sent, invite_accepted | Invites sent, the first half of K. | An untracked share path undercounts invites and makes the loop look weaker than it is. |
Acquisition source on signuputm_source, referrer | Invite conversion, the second half: which signups came from an invite. | If the referrer is dropped at signup, converted invites look organic, K falls toward zero, and the loop is deprioritised. |
Activation or First Impact eventfirst_report_shared | Whether invited users reach value. | Without it, a loop that brings in users who never activate looks like a success. |
Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.
The share link that was nearly cut
Illustrative example. The company and the figures are invented to show the mechanism.
A team adds a link that lets recipients of a shared report sign up from the shared page. The link works well, but the signup it leads to does not carry the referring user. Six months later K has fallen from 0.4 to 0.25, because more invites now travel through the untracked link.
The growth team proposes removing the share feature to simplify the product. It was the best-performing path in the loop, and the metric meant to protect it was the reason it nearly went.
Checks before you trust it
- List every path through which a user can bring in another user, and the event each one fires.
- Confirm the referring user or account survives all the way to the signup event.
- Report K per path as well as in total.
- Check that invited users activate at a similar rate to self-signups.
Check the events under it
Before Viral loop and K-factor goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.