Activation rate: как измерить первую ценность продукта

Коротко

Активация отвечает на рабочий вопрос: какая доля новых пользователей получила первую заметную ценность за выбранное время. Это не универсальное событие «пользователь стал хорошим». Для каждого продукта нужно назвать конкретный момент, после которого у человека появляется причина вернуться.

• Сначала опишите первую ценность словами, потом ищи для неё событие.
• Выберите окно: первые 15 минут, сутки, 7 дней или другой честный срок.
• Считайте активацию от понятного входа в продукт: регистрации, установки или первого визита.
• Смотрите activation рядом с D1/D7 retention, а не вместо него.

Регистрация не равна активации

Регистрация фиксирует намерение попробовать. Активация фиксирует первый результат. В сервисе отчётов пользователь активирован не тогда, когда подтвердил email, а когда увидел первый собранный отчёт. В CRM — когда завёл сделку или контакт. В маркетплейсе — когда нашёл подходящий товар или договорился с продавцом.

Иногда первая ценность — не одно событие, а короткая связка. Например, в B2B-продукте нужно подключить источник данных, настроить первый объект и открыть результат. Тогда не надо выбирать один слабый клик: лучше собрать честную последовательность и явно назвать её activation definition.

Как выбрать activation event

Хорошее activation event лежит близко к ценности, происходит достаточно часто и не срабатывает само по себе. Если событие слишком раннее, метрика будет красивой, но пустой. Если слишком позднее, команда узнает о проблеме через неделю, когда onboarding уже не спасти.

Кандидата в активацию выбирает разрыв в D7, а не удобство трекинга

Четыре вопроса из таблицы выше отсеивают явно негодные события, но между двумя живыми кандидатами они не выбирают. Выбор делает один расчёт на исторической когорте. Возьмите условную июньскую когорту BI-сервиса: 10 000 регистраций, D7 по всей когорте 20%. Для каждого кандидата посчитайте три числа — сколько человек до события дошло, сколько времени у них на это ушло и какой D7 у дошедших против не дошедших.

Сразу видно, что самый широкий разрыв не у того события, которое стоит брать. report_shared делит когорту почти надвое по возвращаемости: 58% против 15%, разрыв 43 п.п. Но охват у него 1 150 человек из 10 000, а медианное время — больше двух суток. Метрика на таком событии опаздывает: об испорченном onboarding вы узнаете на третий день, когда когорта уже прошла, и шевелиться она будет от поведения самых мотивированных 11%, а не от первого опыта остальных.

Проверьте арифметику, она сходится для всех трёх строк. У report_created активированные дают 3 900 × 40% = 1 560 вернувшихся, неактивированные — 6 100 × 7% = 427, вместе около 1 990, то есть те же 20% по когорте. То же упражнение для email_confirmed: 8 100 × 22% + 1 900 × 11% ≈ 1 990. Событие не создаёт возвращаемость и не забирает её — оно только делит одну и ту же когорту на две части. Вопрос лишь в том, насколько полезно это деление для работы.

По трём числам вместе выигрывает середина. report_created накрывает 39% когорты — достаточно, чтобы метрика реагировала на изменения в onboarding, а не на поведение узкой группы. Медиана 38 минут укладывается в первые сутки с большим запасом. Разрыв 33 п.п. достаточно широк, чтобы за ним стояло что-то содержательное. email_confirmed проваливает именно разрыв: 11 п.п. — это почти фоновая разница между «человек дошёл до письма» и «человек закрыл вкладку».

Отдельная ловушка — событие, доступное не всем. report_scheduled есть только на платном тарифе, а платный триал из 10 000 регистраций берут 1 800. Активация на таком событии меряет не первый опыт, а долю платных регистраций: отдел продаж сменил правило выдачи триала — метрика поехала, хотя в продукте не поменялось ничего. То же относится к событиям, которые пишутся только в мобильном приложении или только в новой версии интерфейса.

И последнее: 33 п.п. на июньской когорте — это одно наблюдение, а не свойство события. Пересчитайте разрыв на марте и апреле. Если выходит 31, 34 и 33 п.п., кандидат устойчив. Если 9, 12 и 33 — в июне сработал релиз, сезон или кампания, и вы выбрали событие по случайному максимуму. Устойчивость важнее ширины: метрику, которая меняет смысл каждый квартал, нельзя поставить в onboarding-дашборд.

Формулировка тоже входит в проверку. «Создал отчёт на своих данных в первые сутки» можно произнести на встрече, и все поймут одинаково. «Достиг core_value_state = 3» понятно только автору правила, и через полгода никто не вспомнит, что в это состояние попадает пользователь, которому данные загрузил менеджер внедрения. Пересматривать выбор нужно после каждого изменения core workflow: событие живёт не вечно, а пока сценарий первой ценности выглядит так же.

Таблица ниже условная, а запрос под ней выполняется на учебной базе симулятора SQL-аналитика, где кандидатов четыре: созданное пространство, отчёт, приглашение и экспорт. У июньской когорты из 1 042 человек D7 равен 24,6%. Разрыв у всех четырёх отрицательный, от −0,6 до −5,5 п. п., и не выходит за пределы шума; на июльской три из четырёх уже положительные — тоже в пределах шума. Возврат здесь сгенерирован по каналу и дню жизни, а не по действиям первых дней, поэтому проверку не проходит ни один кандидат. Это законный исход расчёта: событие, которое не отделяет вернувшихся, активацией не назначают.

with cohort as (
  select user_id, signup_date
  from users
  where signup_date >= date '2026-06-01' and signup_date < date '2026-07-01'
),
returned as (                                    -- открыл приложение на седьмой день
  select distinct c.user_id
  from cohort c
  join events e on e.user_id = c.user_id
   and e.event_name = 'app_open'
   and cast(e.event_time as date) = c.signup_date + 7
),
candidates (event_name) as (
  values ('workspace_created'), ('report_created'), ('invite_sent'), ('export_completed')
),
reached as (                                     -- по строке на пару «человек × кандидат»
  select k.event_name, c.user_id,
         min(cast(e.event_time as date) - c.signup_date) as day_of_event
  from cohort c
  cross join candidates k
  left join events e
    on e.user_id = c.user_id
   and e.event_name = k.event_name
   and e.event_time >= c.signup_date
   and e.event_time <  c.signup_date + interval '7 days'
  group by k.event_name, c.user_id
)
select
  r.event_name,
  count(*) filter (where r.day_of_event is not null) as reached_users,
  percentile_cont(0.5) within group (order by r.day_of_event) as median_day,
  round(100.0 * count(*) filter (where r.day_of_event is not null and ret.user_id is not null)
        / nullif(count(*) filter (where r.day_of_event is not null), 0), 1) as d7_reached,
  round(100.0 * count(*) filter (where r.day_of_event is null and ret.user_id is not null)
        / nullif(count(*) filter (where r.day_of_event is null), 0), 1) as d7_missed
from reached r
left join returned ret on ret.user_id = r.user_id
group by r.event_name
order by reached_users desc, r.event_name;

• Считайте охват, медианное время и разрыв в D7 — одного числа из трёх не хватает для выбора.
• Отбрасывайте кандидата, до которого доходит меньше пятой части когорты: он описывает ядро, а не новых пользователей.
• Отбрасывайте событие, недоступное части аудитории по тарифу, платформе или версии.
• Повторите расчёт на двух-трёх когортах и сравните разрывы между собой.
• Запишите определение словами; если фраза требует внутреннего термина, правило ещё не готово.

Активация и D7 должны читаться вместе

Если activation rate падает, а D7 остаётся прежним, возможно, вы просто поменяли трекинг или выбрали слишком раннее событие. Если падают обе метрики, стоит смотреть первый сценарий, время до результата, ошибки, качество канала и соответствие обещания лендинга реальному продукту.

График условный. Он не доказывает, что рост activation сам по себе вызовет рост retention. Он показывает полезный порядок расследования: сначала найдите, в какой когорте люди перестали получать первую ценность, потом сверяйте это с возвращаемостью.

Как посчитать activation rate в SQL

Запрос написан для учебной базы симулятора SQL-аналитика: users хранит регистрацию, events — одно действие в строке, первой ценностью считается созданный отчёт, report_created. Проверку разрывом в D7 он здесь не прошёл, поэтому запрос показывает технику расчёта, а не готовую метрику. У регистрации есть только дата, поэтому окно — не 24 часа, а календарный день: считаем долю тех, у кого день первого отчёта совпал с днём регистрации.

По неделям регистрации доля меняется от 33,7% до 49,4%, по всем 4 613 пользователям — 38,5%. В июне она 43,6%, позже — 37,0%: 1 июля запущен платный поиск, где отчёт создают 23,4%; без него было бы 42,4%. Изменился трафик, а не онбординг. Окно длиннее дня дало бы те же числа: отчёт в этой базе создают только в день регистрации — так сгенерированы данные.

Событие нужно заменить на своё. Если активация состоит из последовательности шагов, соберите в отдельном CTE полную связку и только затем считайте пользователя активированным.

with cohort as (
  select user_id, signup_date,
    cast(date_trunc('week', signup_date) as date) as cohort_week
  from users
),
first_value as (                  -- зерно: пользователь, день первого отчёта
  select user_id, min(cast(event_time as date)) as first_value_day
  from events
  where event_name = 'report_created'
  group by user_id
)
select c.cohort_week, count(*) as new_users,
  count(*) filter (where f.first_value_day = c.signup_date) as activated_users,
  round(100.0 * count(*) filter (where f.first_value_day = c.signup_date) / count(*), 1) as activation_rate_day0_pct
from cohort c
left join first_value f on f.user_id = c.user_id
group by c.cohort_week
order by c.cohort_week;

Где activation rate начинает врать

Самая частая ошибка — назвать активацией первый удобный event из трекинга. Вторая — смотреть только общий процент, хотя слабый результат мог прийти из одного канала или одной версии приложения. Третья — сравнивать недели с разным временем на активацию: сегодняшняя когорта ещё не прожила 24 часа, а в отчёте уже выглядит хуже прошлой.

• Не считайте тестовые аккаунты, ботов и сотрудников частью новых пользователей.
• Не смешивайте пользователей из self-serve, sales и приглашений коллег.
• Зафиксируйте таймзону и правило «первые 24 часа» или календарный день.
• Проверьте, не изменилась ли логика события после релиза.
• Сегментируйте хотя бы по каналу, платформе и типу нового пользователя.

Активация — это гипотеза о первой ценности

Activation event нельзя выбрать только потому, что он уже есть в схеме событий. Спросите: после какого действия пользователь впервые понимает, зачем ему продукт? В сервисе отчётности это может быть созданный отчёт на своих данных, в таск-трекере — завершённая настройка рабочего процесса, в игре — не запуск, а первый осмысленный игровой результат. Название события лишь техническая деталь; сначала нужно описать ценность словами.

Если первая ценность состоит из нескольких шагов, не прячьте последовательность за одним флагом. Полезно хранить отдельные события и собирать derived activation: пользователь подключил источник, загрузил данные и получил первый результат в течение 24 часов. Так команда видит, на каком шаге ломается путь, а не только итоговый процент.

Activation rate нужно связывать со временем до ценности

Два сегмента могут иметь одинаковый activation rate, но разный опыт. В одном пользователи получают результат за десять минут, в другом — на двадцать третьем часу после нескольких попыток. Средний процент этого не покажет. Поэтому рядом с activation rate полезно смотреть median time-to-value и долю пользователей, которые активировались после ошибки или подсказки.

Окно тоже влияет на решение. Activation24h подходит, когда пользователь ожидаемо решает задачу в первый визит. Для сложного B2B onboarding может быть честнее Activation7d. Не выбирайте более длинное окно только для того, чтобы поднять процент: оно должно соответствовать обещанному сценарию и циклу сделки.

• Покажите activation rate вместе с median time-to-value.
• Разделите активацию в первый визит и после повторного визита.
• Сравнивайте одинаковые окна по каналам и платформам.
• Проверьте, не достигается ли событие автоматически импортом данных.
• Свяжите изменение activation с D7 retention или следующим core action.

Как отличить проблему активации от плохого трафика

Если activation rate снизился, начните с сегментов, а не с редизайна onboarding. Сравните источник, рекламное обещание, платформу, тариф, тип регистрации и версию продукта. Падение только у paid-канала часто означает несовпадение ожиданий; падение на всех каналах после изменения интерфейса больше похоже на продуктовую или техническую проблему.

После локализации проверьте путь внутри сегмента. Для каждого шага нужны количество пользователей, время до шага и ошибки. Если пользователи доходят до подключения источника, но не получают первый отчёт, улучшайте именно этот переход. Если они даже не начинают сценарий, исследуйте обещание, навигацию и мотивацию. Activation rate — итог диагностики, а не единственная точка приложения усилий.

• Найдите сегмент, который дал большую часть изменения.
• Сопоставьте activation с ошибками и временем на каждом шаге.
• Проверьте соответствие рекламы и первого экрана реальной задаче.
• Сформулируйте одну гипотезу на эксперимент или качественное интервью.

Что делать дальше

Вывод «активация 43%» ничего не подсказывает команде. Полезнее сказать так: «Падение сосредоточено в paid social на Android; органика и web стабильны. В сессиях этого сегмента выросла ошибка на подключении источника данных. Следующий шаг — проверить этот этап onboarding и кампании, которые приводят пользователей с другим ожиданием».

После активации логично разбирать сам путь до целевого действия: где именно пользователи выпадают, сколько времени им нужно и меняется ли картина по сегментам. Для этого нужна честная воронка конверсии.