Регистрация не доказывает полученную ценность
Регистрация имеет низкий порог: аккаунт создают из любопытства, по просьбе коллеги или ради шаблона. Считать всех зарегистрированных активированными — значит улучшать поток, не обязанный приносить удержание и выручку: отчёт растёт, а когорта исчезает после первого визита.
В Product-Led Growth активация — наблюдаемое действие, после которого пользователь получил обещанный результат. В аналитике это не открытый дашборд, а опубликованный отчёт с подключённым источником; в сервисе совместной работы — не рабочее пространство, а завершённая задача, по которой коллега получил уведомление или внёс правку. Событие описывает ценность, а не технический переход интерфейса.
Регистрация — метрика приобретения: она показывает стоимость и качество входящего потока, но не отвечает, заработал ли продукт для клиента. Первое полезное действие, повторное применение и доход связывает отдельная воронка. О том, как продуктовая механика соединяет этапы, — материал про масштабируемый Product-Led Growth; здесь важна проверка измерений, а не модель роста.
Воронка PLG как цепочка проверяемых переходов
Воронка фиксирует переходы, меняющие вероятность успеха, а не все клики. На каждом этапе выбирают единицу учёта: пользователя, аккаунт или оплачивающую организацию. Иначе в B2B активность одного энтузиаста выдадут за успех компании, где остальные не начали работу.
| Этап | Наблюдаемый сигнал | Вопрос | Решение |
|---|---|---|---|
| Квалифицированный вход | регистрация с подходящей ролью, размером компании или задачей | пришёл ли целевой сегмент? | менять канал или обещание лендинга |
| Первый результат | activation event в заданный срок | получена ли ценность? | убирать трение онбординга |
| Повторная ценность | возврат к критическому действию в интервале продукта | есть ли причина вернуться? | развивать регулярный сценарий |
| Командное принятие | несколько активных участников и общий объект | закрепился ли продукт в аккаунте? | передавать сигнал sales или customer success |
| Доход и расширение | покупка, рост мест, лимита или модуля | превращается ли ценность в деньги? | проверять упаковку и момент предложения |
Для ежедневного продукта повторную ценность измеряют через сутки или неделю. Для квартального планирования возврат на следующий день ничего не значит: работа выполнена. Удержание привязывают к естественному ритму задачи, иначе возникают ложный отток и ненужные уведомления.
North Star Metric стоит выше цепочки: она описывает повторяемую рыночную ценность и устойчивость бизнеса. Активация — ранний входной показатель. Онбординг можно изменить за неделю, но экран приветствия не обязан сразу поднять квартальный доход; эта причинная дистанция защищает планирование от магии дашборда.
Событие активации выбирают по будущему возврату
Хорошее activation event отражает завершённый результат, происходит достаточно рано, доступно большинству целевой аудитории, надёжно фиксируется и делит когорту по будущему поведению. Последнее важнее всего: если пользователи с действием и без него возвращаются одинаково, событие удобно для отчётности, но не для продукта.
Не собирайте его из случайных обязательных шагов: «создал проект + пригласил коллегу + посмотрел видео» может скрывать разные мотивы. Сначала определите единицу ценности. Для B2B SaaS согласования договоров это может быть договор, отправленный контрагенту и прошедший хотя бы один раунд правок; затем проверьте ранние действия, действительно ему предшествующие.
Пример: за неделю зарегистрировались 1 000 подходящих пользователей, 420 завершили полезное действие в первые три дня. К 28-му дню к критическому сценарию вернулись 210 из них и 116 из 580 неактивированных: удержание 50% против 20%, разрыв 30 процентных пунктов. Это перспективная гипотеза, но не доказательство причинности: в активированной группе могут быть более мотивированные пользователи или клиенты с другой задачей.
В словаре метрик фиксируют знаменатель, допустимый срок от регистрации, исключения для тестовых и внутренних аккаунтов, часовую зону и владельца качества трекинга. Формулировка «активный пользователь» без действия непригодна для эксперимента и отчёта руководству.
Self-serve и sales-assisted требуют разных срезов
В self-serve активация обычно начинается на уровне пользователя: он сам достигает результата, решает вернуться или оплатить. Смотрите время до первой ценности, долю активированных за первые 24 часа, повтор критического действия и оплату; сегментируйте хотя бы по каналу, роли, тарифу и сценарию входа. Среднее скрывает, что реклама даёт быстрые регистрации с низким удержанием, а органический поиск — меньше пользователей, но лучшую экономику.
В sales-assisted оплату, внедрение и продуктовые действия часто выполняют разные люди. Индивидуальное событие всё ещё нужно, но сигнал продажам строят на уровне аккаунта. Product-qualified account — не лид, скачавший файл или посетивший страницу цен, а организация с подтверждённым ICP и признаками ценности: несколько участников сделали рабочее действие, создан общий объект, объём работы достиг минимального порога.
Порог PQL нельзя копировать у другого SaaS. Для продукта с одной ежемесячной операцией три активных дня бессмысленны, для ежедневной поддержки клиентов — слишком слабый сигнал. Продажам нужен объяснимый аккаунт: совершённые действия, владелец, подходящий тариф или размер команды, срок окна уместного контакта. Иначе менеджеры игнорируют передачу, а продукт обвиняет их отношение к лидам вместо пересмотра критерия.
Где ломаются красивые дашборды
Первый сбой — действие, которое легко накрутить интерфейсом. Просмотр подсказки, пустой проект или подключённая интеграция могут вырасти после редизайна без результата для клиента. Спросите: будет ли радовать рост, если ухудшатся возвраты и поддержка? Если нет, добавьте защитный показатель.
Второй сбой — неполная идентификация: пользователь начал с личной почты, затем вошёл в корпоративный аккаунт, а система записала два пути. В B2B это искажает активацию и PQL. Третий — изменение трекинга: событие переименовали, свойство перестало поступать из мобильного приложения, и график внезапно «улучшился». Перед выводами проверяют объём событий, долю пустых свойств, дедупликацию и дату релиза.
Опасно связывать доход с любым использованием функции: пользователь может из любопытства открыть дорогой модуль, а через месяц аккаунт снизит тариф. Доход — поздний тест ценности, а не повод превращать любой продуктовый сигнал в агрессивное предложение. Для персонализации достаточно минимума поведенческих данных, понятной цели контакта и возможности отказаться от сообщений.
Когорта проверяет гипотезу, а не подтверждает её
Когортный анализ отвечает, различаются ли будущие возвраты сопоставимых групп, разделённых ранним поведением. Сравнивайте пользователей одного периода регистрации с одинаковым временем на возврат. В B2B нужен второй срез по аккаунтам: один активный администратор не должен делать удержанной всю организацию.
Ниже запрос в синтаксисе, близком к PostgreSQL: он считает удержание на 28-й день среди новых пользователей, у которых report_published случился в первые три суток. Замените таблицы и поля своей схемой, а событие возврата согласуйте с ритмом продукта.
WITH first_signup AS (
SELECT user_id, MIN(event_time)::date AS signup_date
FROM events WHERE event_name = 'signed_up' GROUP BY user_id
), cohorts AS (
SELECT s.user_id, s.signup_date,
MAX(CASE WHEN e.event_name = 'report_published'
AND e.event_time < s.signup_date + INTERVAL '3 days'
THEN 1 ELSE 0 END) AS activated,
MAX(CASE WHEN e.event_name = 'report_published'
AND e.event_time::date = s.signup_date + 28
THEN 1 ELSE 0 END) AS retained_d28
FROM first_signup s LEFT JOIN events e ON e.user_id = s.user_id
GROUP BY s.user_id, s.signup_date
)
SELECT activated, COUNT(*) AS users,
AVG(retained_d28::numeric) AS retention_d28
FROM cohorts GROUP BY activated;
Расчёт не контролирует канал, роль, страну, тариф и сезонность. Добавьте их как разрезы, если они меняют состав потока. Затем проведите эксперимент: случайно покажите части новых пользователей новый онбординг, заранее назначьте основную активацию и защитные метрики, а удержание проверьте после полного цикла. Даже положительный тест не делает событие вечной истиной: меняются продукт, сегмент и ценностное обещание.
Метрики ведут к решениям, а не к отчётам
Операционный набор не требует десятков чисел: у каждой метрики должны быть решение и владелец. Ранние показатели позволяют менять опыт сейчас, поздние проверяют закрепление ценности и денег, защитные не дают оптимизировать локально.
| Тип | Метрика и формула | Ритм | Решение |
|---|---|---|---|
| Ранняя | Активация = активированные новые пользователи / все подходящие новые пользователи | еженедельно | где ломается онбординг, кому нужен отдельный путь |
| Ранняя | Медианное время до ценности | еженедельно | какие шаги, импорты, настройки тормозят результат |
| Поздняя | Удержание D28 = вернувшиеся в день 28 / пользователи стартовой когорты | по зрелым когортам | связан ли ранний сигнал с повторной ценностью |
| Доходная | Доля аккаунтов с расширением = аккаунты с ростом мест, лимита или модуля / активные платящие аккаунты | ежемесячно | где следующий тариф совпадает с потребностью |
| Защитная | Ошибки, обращения в поддержку, ранние отмены, жалобы на сообщения | вместе с тестом | не куплен ли рост активации ухудшением опыта |
Для PQL добавьте долю аккаунтов, принятых продажами после проверки, и долю принятых, дошедших до согласованного следующего шага. Большой объём непринятых передач означает слабый критерий или неясный маршрут; малый объём при хорошей конверсии может означать намеренно узкий ICP.
Что проверить до запуска новой метрики
Не ждите идеального хранилища — пройдите короткий рабочий цикл.
- Запишите гипотезу: «действие X в срок Y связано с возвратом Z»; выберите единицу анализа — пользователя или аккаунт.
- Опишите событие глаголом и объектом, свойства, исключения, источник и владельца: например,
report_publishedс идентификатором проекта, типом интеграции и признаком тестового аккаунта. - После релиза проверьте событие в реальных сессиях, сопоставьте сырые события с интерфейсом и CRM: скрин дашборда не заменяет логи.
- Постройте когорты активированных и неактивированных, добавьте важные сегменты и зафиксируйте окно наблюдения до просмотра результата.
- Назначьте ритуал: раз в неделю продукт, аналитика и продажи обсуждают не график, а выбор, который он должен изменить.
Цена плохой метрики растёт с автоматизацией: сигнал в CRM формирует очередь менеджеров, письма влияют на доверие, бонусная схема заставляет подстраивать продукт под счётчик. Поэтому доступ, срок хранения и минимизация персональных данных — часть качества PLG-аналитики наряду с формулой.
Вместо витрины метрик нужен цикл проверки
Метрика активации не обязана впечатлять: она должна объяснять, какое раннее действие предсказывает повторную ценность для конкретного сегмента и что делать при сдвиге показателя. Начните с одного сценария и зрелой когорты, зафиксируйте определение, проверьте связь с удержанием, затем добавьте доходный и защитный контуры.
Через квартал пересмотрите событие с учётом изменений продукта и ICP. Если связь с удержанием исчезла, не защищайте старый дашборд: пересоберите гипотезу ценности. Готовность отменить красивый, но пустой счётчик отличает измерение Product-Led Growth от отчётности ради отчётности.