Коротко: k-factor — это среднее число новых пользователей, которых приводит один существующий пользователь через приглашения. Считается как число приглашений на одного пользователя, умноженное на конверсию приглашения в регистрацию. Если k больше 1, продукт растёт сам по себе, экспоненциально: каждый пришедший приводит больше одного нового. Если k меньше 1, виральность есть, но она только удешевляет платное привлечение, а не заменяет его. Дальше разберу, как это посчитать честно по когортам, при чём тут длина вирального цикла и почему на эту метрику нельзя молиться.
Что такое k-factor простыми словами?
Представьте, что у вас 1000 новых пользователей. Каждый в среднем отправил 4 приглашения друзьям. Из этих приглашений зарегистрировалось 15%. Значит, тысяча человек привела 1000 × 4 × 0.15 = 600 новых. Вот это отношение — 600 приведённых на 1000 исходных — и есть k-factor, равный 0.6.
Формула в два множителя:
k = (приглашений на пользователя) × (конверсия приглашения в регистрацию)
Первый множитель отвечает за то, насколько активно люди зовут других. Второй — насколько хорошо приглашение конвертит. Улучшить можно и то, и другое: добавить кнопку «позвать друга» в удачный момент (растёт число приглашений), переписать текст приглашения и упростить онбординг по ссылке (растёт конверсия). Произведение и даёт итоговый вирусный коэффициент.
Важно не путать k-factor с долей пользователей, которые хоть раз кого-то позвали. Можно иметь много «активных приглашающих», но низкий k, если каждый зовёт по одному человеку и почти никто не доходит. И наоборот — небольшая группа евангелистов, зовущих десятками, вытянет метрику вверх.
Что значит k больше единицы, а что — меньше?
Это водораздел между двумя разными мирами. При k > 1 каждый пользователь приводит больше одного нового, те приводят ещё больше — включается самоподдерживающийся рост. Формально число пользователей после n циклов ведёт себя как начальная_когорта × k^n: при k = 1.2 за десять циклов один пользователь превращается примерно в шесть, за двадцать — в тридцать восемь. Это и есть та самая экспонента, ради которой все и гоняются за виральностью.
При k < 1 эффект затухающий. Приведённые приводят ещё, но каждая волна меньше предыдущей. Сумма всей цепочки ограничена: один платно привлечённый пользователь с k = 0.5 даст в сумме 1 / (1 − 0.5) = 2 пользователя с учётом всех виральных волн. Полезно, но конечно. Продукт всё равно живёт на платном или органическом трафике сверху.
Честно скажу: устойчивый k > 1 — большая редкость и почти всегда временное явление на старте, пока аудитория свежая. Мессенджеры и соцсети образца раннего роста туда попадали. Обычный SaaS или маркетплейс живёт с k где-то между 0.15 и 0.7, и это нормально. Не гонитесь за единицей любой ценой — 0.4 при дешёвом платном канале часто выгоднее, чем натянутая 0.9 через агрессивный спам приглашениями, который убивает удержание.
Что такое виральный цикл и почему его длина решает всё?
k-factor говорит, сколько новых пользователей придёт. Длина вирального цикла (cycle time) говорит, как быстро. Это время от момента, когда пользователь пришёл, до момента, когда приведённый им человек тоже зарегистрировался и сам начал звать. Один множитель без другого обманчив.
Сравните два продукта с одинаковым k = 1.5. У первого цикл — один день (позвал друга в тот же вечер, тот зашёл утром). У второго — тридцать дней (приглашение уходит раз в месяц с отчётом). За квартал первый прокрутит около 90 циклов, второй — три. Разница в итоговой базе — астрономическая, хотя коэффициент один и тот же.
Практический вывод: работать над сокращением цикла часто дешевле, чем над самим k. Убрать лишний шаг в онбординге по инвайт-ссылке, показать приглашение сразу после первого «вау-момента», а не через неделю — и цикл ужимается вдвое без единого нового множителя. Чтобы измерить cycle time, нужны события с таймстампами: когда отправлено приглашение и когда по нему пришла регистрация. Разберём такие агрегаты в SQL-тренажёре на реальных таблицах событий.
Как посчитать k-factor на реальных данных?
Нужны три сущности: пользователи (users), отправленные приглашения (invitations) и признак того, что приглашённый зарегистрировался. Часто приглашения лежат в таблице событий events, но логически модель та же. Базовый расчёт по когорте приглашающих на PostgreSQL:
with invites as (
select
inviter_id,
count(*) as sent,
count(*) filter (where invitee_signed_up) as converted
from invitations
where invited_at >= date '2026-06-01'
and invited_at < date '2026-07-01'
group by inviter_id
),
cohort as (
select count(distinct id) as users
from users
where created_at >= date '2026-06-01'
and created_at < date '2026-07-01'
)
select
round(sum(i.sent)::numeric / c.users, 2) as invites_per_user,
round(sum(i.converted)::numeric / nullif(sum(i.sent), 0), 3) as invite_conversion,
round(sum(i.converted)::numeric / c.users, 2) as k_factor
from invites i
cross join cohort c
group by c.users;Обратите внимание: k_factor в последней строке — это приведённые регистрации на одного пользователя когорты, и он ровно равен произведению invites_per_user × invite_conversion. Знаменатель — размер когорты приглашающих, а не число тех, кто отправил хоть одно приглашение. Это принципиально: молчуны тоже часть базы, и делить надо на всех.
То же самое на Python, если данные уже вытащены в датафрейм:
import pandas as pd
# invitations: inviter_id, invitee_signed_up (0/1)
# cohort_users: id новых пользователей за период
cohort_size = cohort_users["id"].nunique()
sent = len(invitations)
converted = invitations["invitee_signed_up"].sum()
invites_per_user = sent / cohort_size
invite_conversion = converted / sent
k_factor = invites_per_user * invite_conversion
print(round(k_factor, 2)) # например 0.58Потренироваться в таких группировках и join'ах можно в Python-тренажёре, а базовый синтаксис агрегатов удобно подсмотреть в SQL-справочнике.
Почему k-factor честнее считать по когортам?
Потому что «средний k за всё время» смешивает старых и новых пользователей и почти всегда врёт в лучшую сторону. Виральность живого продукта не постоянна: у ранней аудитории она выше, потом рынок насыщается, друзей звать всё меньше — «пригласить уже некого». Если вы делите суммарные приведённые регистрации на суммарную базу за два года, вы усредняете горячий старт с остывшим настоящим и получаете красивое, но бесполезное число.
Когортный подход фиксирует группу пользователей по месяцу прихода и смотрит, сколько новых привела именно эта группа за сопоставимое окно (скажем, за первые 30 дней жизни). Тогда видно динамику: когорта января дала k = 0.7, июня — 0.45. Это сигнал о насыщении или об ухудшении инвайт-механики, который в общем среднем полностью тонет.
Второй плюс когорт — сопоставимая зрелость. У всех пользователей когорты одинаковое окно на то, чтобы позвать друзей. Иначе вчерашний регистрант, который ещё физически не успел никого пригласить, тянет метрику вниз и создаёт ложное ощущение падения. Та же логика, что в когортном анализе удержания — если тема близка, посмотрите разбор в кейсах. А базовую метрику активной аудитории, на которую всё это ложится, я держу под рукой в описании DAU.
Как виральность снижает CAC?
Прямо: каждый бесплатно приведённый пользователь уменьшает среднюю стоимость привлечения. Логика простая. Вы платите за одного пользователя, он через виральную цепочку приводит ещё сколько-то бесплатно, и деньги, потраченные на первого, размазываются на всех.
Считается через тот же множитель. Если платный CAC — 1500 рублей, а k = 0.5, то на каждого оплаченного пользователя приходится в сумме 1 / (1 − 0.5) = 2 пользователя с учётом виральных волн. Эффективный CAC падает вдвое — до 750 рублей. При k = 0.3 множитель 1 / 0.7 ≈ 1.43, эффективный CAC — около 1050 рублей. Даже скромная виральность заметно улучшает юнит-экономику, если платный канал не бесплатный.
paid_cac = 1500
k = 0.5
viral_multiplier = 1 / (1 - k) # 2.0
effective_cac = paid_cac / viral_multiplier
print(round(effective_cac)) # 750Отсюда и стратегический вывод: улучшение k с 0.3 до 0.5 — это не «плюс немного трафика», это удешевление всего привлечения примерно на треть. Поэтому продуктовые команды так любят реферальные программы: они бьют не по объёму, а по знаменателю в экономике. Вопросы про связку виральности и CAC регулярно всплывают на собеседованиях — потренировать формулировки можно на вопросах для интервью и в заданиях.
Где k-factor врёт и чего не показывает?
Метрика мощная, но у неё есть слепые зоны, и без них картина неполная.
Она ничего не знает про удержание. Можно раздуть k подарками за приглашения и залить продукт людьми, которые пришли ради бонуса и отвалились через день. Формула посчитает их как успех, а база через месяц сдуется. k-factor без удержания и качества когорт — vanity-метрика. Всегда смотрите рядом на retention приведённых пользователей отдельно от органических.
Она предполагает бесконечный рынок. В реальности аудитория конечна: сеть насыщается, «звать больше некого», и k неизбежно падает со временем сам по себе. Экстраполировать сегодняшний k > 1 на год вперёд — классическая ошибка прогноза.
Она чувствительна к атрибуции и двойному счёту. Если один и тот же человек получил приглашения от троих и пришёл, кому засчитать конверсию? Если приглашённый сам был бы органиком — вы приписали виральности чужую заслугу. Плюс приглашения без регистрации, самоприглашения и фрод легко искажают оба множителя.
И она молчит про деньги. Виральный пользователь и платящий пользователь — не одно и то же. Иногда самые «заразные» сегменты хуже всего монетизируются. Поэтому k-factor всегда живёт в связке с LTV, удержанием и CAC, а не отдельным табло на стене. Собрать эту связку в целостную аналитику помогает системная практика — например, базовый курс по SQL, с которого удобно начать разбираться в подобных запросах.
Что запомнить про k-factor
k-factor — это приглашения на пользователя, умноженные на их конверсию. Больше 1 — самоподдерживающийся экспоненциальный рост, меньше 1 — затухающее удешевление платного привлечения через множитель 1 / (1 − k). Длина вирального цикла определяет скорость и часто важнее самого коэффициента. Считать честно — только по когортам приглашающих с равным окном зрелости, иначе среднее приукрашивает. И держать метрику рядом с удержанием, LTV и CAC, потому что в одиночку она легко превращается в красивую, но пустую цифру.
Если хочется довести навык до автоматизма — на тренажёре собрана практика по SQL и Python на реальных данных, продуктовые кейсы и AI мок-собеседования. Free-доступ открывает первые задачи каждого раздела; Pro снимает лимиты и открывает все кейсы, задания и безлимитный разбор с AI-интервьюером.