Предсказатель удержания, а не отчётная галочка
Активация предсказывает удержание, если поведение в первые дни стабильно разделяет будущих возвращающихся и ушедших пользователей. Высокая доля прошедших onboarding сама по себе ничего не доказывает: можно закрыть экраны и нажать кнопку, не получив ценности.
Сначала зафиксируйте удержание: возвращение в D21–D28, повторную покупку, созданный отчёт, размещённый заказ или другое критическое действие. Затем ищите раннее событие, после которого вероятность возврата выше в повторяющихся когортах и сопоставимых сегментах.
Хорошая активация наступает до Retention, доступна заметной доле новичков и связана с ценностью, а не движением по интерфейсу. Для сервиса проектов это первый проект с приглашённым участником; для маркетплейса, где ценность в выборе, — сохранённый товар или первый заказ, а не открытие каталога. Универсального действия нет.
Событие выбирают по разрыву когорт
Составьте список ранних действий, например за первые семь дней после регистрации. Для каждого сравните Retention совершивших и не совершивших действие в абсолютных пунктах и относительном выражении. Одной разницы недостаточно: её может создавать состав трафика.
Когортная матрица показывает то, что скрывает среднее. Это условный формат отчёта, не отраслевой ориентир; ячейки содержат удержание активированных / неактивированных пользователей одной недели регистрации.
| Событие в первые 7 дней | Когорта 1 | Когорта 2 | Когорта 3 | Чтение результата |
|---|---|---|---|---|
| Создал проект | 46% / 22% | 44% / 21% | 47% / 24% | устойчивый разрыв |
| Добавил аватар | 33% / 28% | 27% / 26% | 35% / 30% | слабый сигнал |
| Пригласил коллегу | 58% / 25% | 55% / 23% | 39% / 24% | проверить состав канала |
«Создал проект» сильнее, потому что разрыв повторяется и не меняется хаотично. Большой эффект «пригласил коллегу» в первых двух когортах и просадка в третьей требуют проверки: мог прийти новый канал, измениться механика приглашений или тип пользователей.
Проверяйте распространённость. Почти идеальная связь у малой группы уже мотивированных пользователей полезна для изучения ценной аудитории, но не для onboarding. Операционная метрика должна оставлять пространство для роста и описывать улучшаемый продуктом путь.
Корреляция ломается на канале и намерении
Главная ловушка — смещение отбора. Пользователи с ясной задачей из брендового поиска быстрее создают проект и чаще возвращаются; пришедшие из широкой рекламы могут зарегистрироваться из любопытства, не активироваться и уйти. В общей таблице создание проекта станет выглядеть причиной, хотя разрыв частично объясняется намерением.
Сравнивайте активированных и неактивированных внутри источника, кампании, страны, устройства и версии продукта. Учитывайте признаки до активации: число сессий до первого действия, сценарий входа, выбранный тариф, роль в рабочем пространстве. Это не устранит скрытые различия, но снизит риск принять качество трафика за эффект продукта.
Сегментация нужна для решения. Если разрыв есть в платном поиске, но исчезает в партнёрском трафике, не объявляйте событие универсальным: пути к ценности различаются либо посадочная страница обещает не то, что даёт первый сеанс. Лучше пересобрать onboarding или разделить аудитории, чем усреднять их.
Исключите обратную причинность: пользователь может вернуться по внешней причине и совершить раннее действие уже во второй визит. В окно активации должны входить только действия до измеряемого возврата.
SQL должен фиксировать время и право попасть в выборку
Неверный SQL создаёт ложную связь. Не включайте свежие регистрации, не прожившие окно Retention. Смещение бессмертного времени возникает, если на активацию дают семь дней, а неактивированных сравнивают с ушедшими на второй: первая группа уже получила больше времени в продукте.
Упрощённый запрос: активация — создание проекта, удержание — критическое действие на 21–28-й день; берутся только регистрации, достаточно старые для обоих окон.
WITH base AS (
SELECT user_id, signup_at
FROM users
WHERE signup_at < current_date - interval '28 day'
), flags AS (
SELECT b.user_id,
MAX(CASE WHEN e.event_name = 'project_created'
AND e.occurred_at >= b.signup_at
AND e.occurred_at < b.signup_at + interval '7 day'
THEN 1 ELSE 0 END) AS activated,
MAX(CASE WHEN e.event_name = 'core_action'
AND e.occurred_at >= b.signup_at + interval '21 day'
AND e.occurred_at < b.signup_at + interval '28 day'
THEN 1 ELSE 0 END) AS retained
FROM base b
LEFT JOIN events e ON e.user_id = b.user_id
GROUP BY 1
)
SELECT activated, COUNT(*) AS users, AVG(retained) AS retention
FROM flags
GROUP BY 1;
Для решения добавьте дату регистрации, канал, устройство, страну и вариант интерфейса. Проверьте дубликаты, смену идентификатора после авторизации и пропуски трекинга. Если project_created отправляется до успешного сохранения, измеряются нажатия, а не ценность.
Сигнал должен пережить повторную проверку
Разрыв одной когорты случаен, особенно при малых группах или десятках проверяемых событий. Выберите кандидата на ранних когортах, затем проверьте на последующих: это снижает риск эффекта, существующего лишь в историческом срезе.
Фиксируйте размер групп, абсолютную разницу и доверительный интервал, а не только среднее удержание. В малом сегменте впечатляющий процентный рост может исчезнуть через неделю. Для денежной метрики смотрите медиану, распределение и долю пользователей с доходом: среднее искажают несколько крупных плательщиков.
Используйте отрицательный контроль — действие без прямой связи с ценностью, например смену темы. Если оно предсказывает Retention почти так же, как активация, обе метрики, вероятно, ловят интенсивность первого визита, устройство или неполный контроль каналов, а не продуктовую механику.
Сравните время до активации: действие в первые десять минут и на шестой день имеет разный смысл. Раннее может означать понятный первый опыт, позднее — настойчивость; складывать их в один флаг нельзя.
Эксперимент отделяет влияние продукта от выбора пользователя
Наблюдения показывают связь; влияние проверяет эксперимент, меняющий вероятность активации, но не состав аудитории. Например, одна группа получает в onboarding готовый шаблон проекта, другая — текущий путь. Распределяйте пользователей случайно до первого экрана и записывайте условие показа отдельным событием экспозиции.
Цепочка должна быть ясна: вариант влияет на создание проекта, оно связано с Retention, а вариант не ухудшает другой опыт. Контролируйте:
- Retention в заранее выбранном окне и по описанному критическому действию.
- Долю создавших проект и время до действия.
- Ошибки, обращения в поддержку, отмены, удаление проектов и денежные показатели, если изменение затрагивает оплату.
Рост активации без Retention значит, что действие упростили, но к ценности не приблизили. Рост Retention без заметной смены активации также важен: интерфейс мог улучшить понимание продукта через другой механизм. Не приписывайте эффект событию без подтверждения всей цепочки.
До старта зафиксируйте окно конверсии, значимый для решения эффект и срок теста. Ежедневная проверка повышает шанс остановиться на случайном колебании. После выката наблюдайте новые когорты: новизна интерфейса, сезонность и рекламный микс меняют эффект.
Рост продукта меняет смысл раннего действия
На ранней стадии одно действие иногда описывает ценность, но с новыми ролями, тарифами, странами и сценариями — нет. Администратор создаёт проект, исполнитель ждёт приглашения, клиент лишь смотрит результат; общая активация начинает штрафовать нормальное поведение.
Храните несколько путей активации для ролей, объединённых первым полезным результатом, и датируйте версии определения. Иначе квартальный график смешает старую таксономию, новый onboarding и изменение продукта, а скачок нельзя будет объяснить.
Качество трекинга критично: владелец события, условия срабатывания, тесты после релиза и журнал изменений защищают от тихой деградации. Переименование события или автосоздание сущности требует отдельной проверки когорт до и после релиза.
Метрика заслуживает места в ежедневной работе
Рабочая активация подтверждена трижды: когортный разрыв стабилен, связь сохраняется в сопоставимых каналах и сегментах, а эксперимент меняет не только раннее действие, но и удержание. До этого это гипотеза.
Начните с одного критического действия и окна Retention, соберите матрицу нескольких когорт, разложите её по источникам и проверьте тайминг SQL. Так слабая метрика обнаружится быстрее бесконечной настройки дашборда, а команда получит предмет для эксперимента: сокращать путь к первой ценности, а не заставлять пройти ещё один шаг.