K-factor

Definition

K-factor is the average number of new users each existing user generates through invitations, calculated as invitations sent per user multiplied by the conversion rate of those invitations.

The term is borrowed from epidemiology, where it describes how many people each infected person infects. Above 1.0, growth compounds without acquisition spend; below 1.0, referrals amplify other channels but cannot sustain growth alone. Almost every app is below 1.0, and a K of 0.4 is genuinely valuable — the useful framing is amplification, not self-sustaining virality.

The formula, and what each half costs to move

K equals invitations sent per user multiplied by the conversion rate per invitation. Both factors are usually small, and their product is smaller still — which is why the arithmetic is worth doing before a referral programme is scoped.

The amplification column is the number that matters for planning. At K = 0.4, every 1,000 paid installs eventually produce roughly 1,667 total users, which means your true cost per user is 60% of your nominal CPI — a direct input into effective CPI. The jump between K = 0.4 and K = 0.9 is enormous, which is why marginal improvements matter far more as you approach 1.

Cycle time is the other half of the story

K tells you how much amplification you eventually get; viral cycle time tells you how fast. Two products with identical K grow at wildly different rates if one completes an invite loop in a day and the other in a month, and cycle time is usually the cheaper of the two to improve.

Cycle time is dominated by friction in the invite loop, and the largest single component is usually the recipient's journey. An invite link that opens a web page asking someone to find the app in the store loses most of its clicks before install — which is where deferred deep linking is not a nicety but the mechanism that determines the conversion half of K itself.

Measuring it honestly

The measurement needs three linked events: the invite sent, the invite clicked, and the resulting install joined back to the inviter. Without a referral identifier that survives the store, the last join is impossible and K becomes a guess.

-- K is a product of two rates. Reporting only K hides which one moved.
WITH inviters AS (
  SELECT
    DATE_TRUNC(DATE(installed_at), WEEK(MONDAY)) AS cohort_week,
    user_id
  FROM installs
),
invites AS (
  SELECT inviter_user_id AS user_id, COUNT(*) AS invites_sent
  FROM referral_invites
  GROUP BY inviter_user_id
),
converted AS (
  -- An install is referred only when the referral code survived to first open.
  SELECT r.inviter_user_id AS user_id, COUNT(DISTINCT i.user_id) AS referred_installs
  FROM installs i
  JOIN referral_invites r ON r.referral_code = i.referral_code
  GROUP BY r.inviter_user_id
)
SELECT
  c.cohort_week,
  COUNT(*)                                             AS cohort_size,
  ROUND(SUM(COALESCE(v.invites_sent, 0)) / COUNT(*), 2) AS invites_per_user,
  ROUND(SAFE_DIVIDE(SUM(COALESCE(x.referred_installs, 0)),
                    SUM(COALESCE(v.invites_sent, 0))), 4) AS invite_conversion,
  ROUND(SUM(COALESCE(x.referred_installs, 0)) / COUNT(*), 3) AS k_factor
FROM inviters c
LEFT JOIN invites   v USING (user_id)
LEFT JOIN converted x USING (user_id)
GROUP BY c.cohort_week
ORDER BY c.cohort_week DESC;

Two design decisions are embedded there. The denominator is the whole cohort, not just users who sent an invite — dividing by inviters produces a much larger number that describes an unrepresentative subgroup. And the conversion join requires the referral code to have reached first open, which on iOS means a deferred deep link, since no URL parameter survives the App Store.

Where the number gets inflated

• Dividing by inviters rather than by all users. Produces a flattering number describing a self-selected subgroup.
• Counting invites sent rather than delivered. A contact-list bulk send is not an invitation anyone saw.
• Counting reinstalls as referred installs. Existing users redeeming their own code is not growth.
• Attributing organics to referral. A wide referral window catches users who would have installed anyway; the same problem as view-through attribution.
• Ignoring incentive cost. K of 0.8 bought with a $10 credit on both sides is a paid channel with extra steps.

The honest version of the metric reports invites per user, invite conversion and cycle time separately, then derives K from them. Reporting K alone hides which half moved, and the two halves respond to completely different work — one is a prompt-placement problem, the other is almost entirely a link-routing problem.