Ручной рост-хакинг упирается в скорость человека. Пока аналитик находит просевший шаг воронки, когорта уже утекла. В продуктовой модели каждое касание оставляет след, и выигрывает команда, которая реагирует на эти следы за часы. Модель машинного обучения здесь помогает, но только на сшитых данных и на объёме, где она точнее простого правила.
Сигналов стало больше, чем людей, способных их прочитать
В продуктово-ориентированной модели след оставляет каждое действие: клик, обращение к функции, конверсия. Собирать их научились давно. Теперь команды различаются тем, что успевают с ними сделать.
Ранний рост-хакинг держался на интуиции и быстрых экспериментах. Сегодня к ним добавились машинное обучение, прогнозы и автоматические решения. Они ищут, что на самом деле приводит пользователей, удерживает их и приносит деньги. И делают это на объёмах, которые вручную не разобрать.
ИИ удобно представлять вторым оператором внутри цикла. Он замечает закономерности, которые человек пропустит, предлагает следующий шаг и подстраивает продукт под пользователя, пока команда спит. Это меняет экономику каждого этапа воронки.
Зрелый продукт порождает терабайты событий на разных устройствах и маршрутах. Без модели этот объём остаётся шумом. С моделью он превращается в закономерности, ради которых стоит действовать, и это ценнее ещё одного дашборда.
Аналитика переходит от вопроса «что случилось» к вопросу «что делать». Обычный отчёт сообщает, что пользователь уже ушёл. Прогноз позволяет вмешаться раньше: удержать того, кто вот-вот застрянет, или поменять цену сегменту до оттока.
У любой полезной аналитики три шага: заметить проблему, что-то сделать и проверить экспериментом, сработало ли. ИИ ускоряет все три. Он читает поведение почти в реальном времени, рекомендует шаг, сам формулирует и проверяет гипотезы.
Одна оговорка остаётся в силе. Модель видит корреляции. Причинность проверяют отдельно, контрольной группой.
Четыре рычага воронки и ловушка в каждом
Привлечение смещается от объёма к правильным пользователям: тем, чей профиль и первые сессии предсказывают устойчивое использование. Предиктивный скоринг лидов ранжирует регистрации по вероятности конверсии. Бюджет перетекает к кампаниям с реальной отдачей, а онбординг подстраивается под намерение вместо одного первого экрана для всех.
Ловушка в том, что модель учится на себе. Обученная на лучших клиентах прошлого квартала, она постепенно сводит привлечение к похожим на них аудиториям (lookalike). Новых людей в воронку приходит всё меньше. Небольшой бюджет на случайное исследование не даёт модели съесть собственный хвост.
Активация решает, поймёт ли новичок, зачем ему продукт. Время здесь важнее содержания. Модель может разделить пользователей на тех, кто осваивается, и тех, кто нет. Но главная её задача другая: поймать момент, когда новичок вот-вот застрянет, и показать подсказку именно к этому шагу, а не общую для всех. Прирост вовлечённости первой недели обычно сильнее зависит от того, когда срабатывает подсказка, чем от её текста.
Удержание вырастает из ценности, которую пользователь получает непрерывно. Отдельной кампанией его не купить. Модель здесь полезна трижды. Она заранее замечает по поведению, что человек собирается уйти. Подсказывает, каким способом его лучше вернуть. И показывает, какие функции нужны этой группе, даже если маркетинг хотел бы продвигать другие.
Монетизация остаётся самым недоиспользованным рычагом. Реакцию на цену можно проверять по группам пользователей, а не гадать. Тариф подороже или дополнительную услугу предлагают, когда человек к этому готов. А спад активности за недели предупреждает, что клиент может отменить подписку.
Для подписочного продукта прогноз ценности клиента за жизненный цикл (LTV) управляет и бюджетом привлечения, и ценовыми экспериментами. Модель LTV, обученная на текущих когортах, ошибётся с сегментом, как только сдвинется продукт или рынок. Поэтому её часто обучают заново на свежих когортах. Раз в год пересматривать мало.
Ошибка в оттоке на два пункта стоит трети бюджета
Вот расчёт, на котором держится этот бюджет, на примере одного тарифа.
LTV = ARPU × валовая маржа × срок жизни, где срок жизни ≈ 1 / месячный отток.
Пусть тариф даёт ARPU 30 €/мес при марже 75%, а модель оценивает месячный отток сегмента в 4%:
- срок жизни: 1 / 0,04 = 25 месяцев;
- LTV по марже: 30 × 0,75 × 25 = 562,5 €;
- потолок CAC, если тратить треть LTV, около 187 €;
- окупаемость при CAC 120 €:
CAC / (ARPU × маржа)= 120 / 22,5 ≈ 5,3 месяца.
Треть LTV взята не с потолка. При таком правиле на каждый евро привлечения приходится три евро валовой прибыли, и этого запаса хватает, чтобы пережить ошибку прогноза. Затраты в примере к тому же возвращаются меньше чем за полгода.
Сильнее всего результат зависит от оттока. Если оценка сдвигается с 4% до 6%, срок жизни падает до ~17 месяцев, а LTV до ~375 €. Потолок привлечения при трети LTV опускается со 187 € до 125 €. Устаревшая модель промахивается сразу на весь бюджет, который она обосновывает.
North Star должна двигаться медленнее поведения
Четыре рычага тянут каждый в свою сторону и без единого показателя быстро разъезжаются. North Star-метрика собирает продукт, клиента и бизнес вокруг одного числа.
С ИИ её можно сделать подвижной. Модель проверяет, какие действия лучше всего предсказывают, что пользователь останется надолго. Когда поведение меняется, она пересчитывает метрику. Цель на дашборде перестаёт быть раз и навсегда заданной.
Риск очевиден. Под метрику, которая переопределяет себя каждую неделю, невозможно планировать. Калибровка должна быть медленной и объяснимой.
Вместе всё это работает по кругу. Система смотрит на поведение и покупки, предсказывает, что будет, делает персональное предложение и учится на результате. Каждый круг делает следующий чуть точнее. Но только при честной проверке: с контрольной группой и без того, чтобы приписывать модели заслуги сезона.
Бандит экономит трафик и охотно масштабирует шум
Важно, сколько экспериментов команда успевает провести. Насколько сложны модели, тут не главное.
Ручной эксперимент упирается в людей. Автоматический тест может перебрать сотни комбинаций сразу. Байесовские методы оценивают, насколько можно доверять результату. Генеративные модели сами готовят мелкие варианты текста и дизайна. Очередь экспериментов перестаёт быть узким местом.
Чаще всего автоматика опирается на многорукого бандита. Система не ждёт конца теста и на ходу перебрасывает трафик к вариантам, которые пока выигрывают. Простейшую версию Стив Ханов описал в 2012 году в посте «20 lines of code that will beat A/B testing every time»: в 10% случаев показывать случайный вариант, в 90% лучший на данный момент (epsilon-greedy). Показы это действительно экономит.
Платить за экономию приходится точностью. Вариант, который случайно вырвался вперёд на первой сотне сессий, получает больше трафика. И закрепляет мнимое преимущество раньше, чем выяснится, настоящее ли оно.
Отсюда три требования к настройке:
- выделенная доля трафика на исследование (10% у Ханова годятся как отправная точка);
- минимальный объём наблюдений до решения;
- запрет трогать без присмотра цену и ключевые сообщения.
Без этих ограничений система уверенно масштабирует шум. Тот, кто разрешил ей ставить эксперименты, должен сам читать каждый тест, который касается цены или сообщений.
Бандит подходит не для всякого вопроса. Если вариант живёт неделю (баннер к распродаже, тема письма), быстрая перекачка трафика окупается. Если решение останется надолго (новая цена, новый онбординг), нужен классический тест с заранее заданным объёмом выборки. Иначе появляется соблазн подглядывать в результаты. А каждая лишняя проверка, после которой тест останавливают при первом хорошем результате, повышает шанс принять случайный всплеск за победу. При ежедневных проверках доля ложных побед легко вырастает в несколько раз против заявленных 5%.
Узкое место сидит в склейке данных
Рост с моделями держится на четырёх слоях. Аналитика поведения в реальном времени. Аккуратный сбор данных о клиентах. Деление пользователей на группы и рассылки. Автоматические эксперименты. Каждый слой зависит от предыдущего. Группы не точнее данных под ними, а эксперимент не надёжнее аналитики, которая его измеряет.
Ниже всех лежит идентификация пользователя, и её недооценивают сильнее всего. Один человек заходит с телефона утром и с ноутбука вечером. До регистрации он анонимен, после обретает имя. Между этими состояниями его действия легко разваливаются на несколько несвязанных профилей.
Пока следы не сшиты в одну историю, поведенческая модель учится на обрубках. Отток засчитывается там, где пользователь просто пересел на другое устройство. «Новый» пользователь на деле возвращается в третий раз.
Масштаб прикинуть несложно. Пусть 20% активных пользователей заходят с двух устройств, и половину из них склеить не удалось. Тогда 10% базы модель видит дважды: один профиль живёт, второй «ушёл». Ложный отток такого размера перекрывает любой выигрыш от более точного алгоритма.
Эта ошибка тише ошибки модели и поэтому опаснее. В метриках качества модели её не видно: модель добросовестно предсказывает по тем данным, что ей дали. Когда команда жалуется, что «модель плохо предсказывает», проблема нередко лежит на два слоя ниже, в наполовину склеенном пользователе.
Отсюда порядок вложений. В идентификацию и качество событий вкладываются раньше, чем в алгоритмы. Более умная модель быстро упирается в потолок, если под ней разорванные профили и события, которые в разных частях продукта называются по-разному. Да и выигрыш модели в офлайн-метриках сам по себе ещё ничего не говорит о бизнесе: это проверяют только экспериментом на живых пользователях.
Отказ от трекинга не равен уходу
У поведенческих данных есть внешнее ограничение, которое модель не отменяет. Часть сигнала пользователь не разрешает собирать. Согласие на трекинг, региональные требования к хранению и праву на удаление, отказ от части cookie вырезают куски следа ещё до аналитики.
Поэтому данные приходят неравномерно. По одним сегментам история почти полная, по другим с дырами. Модель, не знающая об этой асимметрии, выдаёт худшие прогнозы именно там, где данных меньше. Отсутствие сигнала она принимает за отсутствие поведения.
Обходить правила незачем. Лучше строить прогнозы так, чтобы при нехватке данных они ухудшались предсказуемо:
- помечать сегменты с разреженной историей;
- снижать вес автоматических решений там, где под ними мало наблюдений;
- отделять пользователя, отказавшегося от трекинга, от пользователя, который перестал возвращаться.
Последний пункт кажется тонкостью, но на нём ломаются кампании удержания. Система шлёт реактивационную серию человеку, который никуда не уходил: его просто перестали видеть. В лучшем случае бюджет потрачен впустую, в худшем раздражён лояльный клиент.
Согласие пользователей, качество данных и контроль со стороны человека относятся к одному слою. Вместе с остальными он складывается в то, что называют AI Growth OS:
| Уровень | Назначение | Примеры |
|---|---|---|
| Данные | Единая платформа поведения и транзакций | Amplitude, Snowflake |
| ИИ-модели | Прогнозы оттока и LTV, поведенческие предсказания | MLflow, Vertex AI |
| Эксперименты | Автоматические A/B- и многовариантные тесты | Optimizely, Amplitude |
| Автоматизация | Персонализация, коммуникации | Braze, Iterable |
| Управление | Качество данных, соблюдение правил, проверка человеком | DataOps |
Слой управления пропускают чаще всего, хотя именно он решает, можно ли доверять остальным. Без проверки данных и без человека, который следит за решениями, система уверенно улучшает не то.
Меньше нескольких сотен событий в квартал: берите правило
Многие продуктовые команды скажут, что модель им не нужна, и часто будут правы. Правило «не заходил 14 дней, отправить письмо» пишется за час. Его понимают все, и оно ловит большую часть уходящих. Модель оттока требует данных, инженеров, мониторинга и регулярного дообучения. На маленьком продукте она учится на нескольких десятках случаев и выдаёт уверенный шум.
На малых объёмах так и есть. Продукт теряет 60 платящих пользователей в месяц? Значит, у модели 60 положительных примеров, и за квартал она не увидит и двухсот уходов. Правило на таком материале почти всегда не хуже.
Порог условный, но рабочий. Пока за квартал набирается меньше нескольких сотен целевых событий (уходов, апгрейдов, активаций), начинайте с правил и контрольной группы.
На объёме решает точность, и её удобно перевести в деньги. Допустим, система каждый месяц отмечает 500 пользователей как группу риска и отправляет каждому предложение со скидкой на 10 €. Это 5 000 € в месяц.
- Правило с точностью 15% находит 75 настоящих уходящих. Предложение удерживает пятую часть, 15 человек. При LTV 562,5 € это около 8 400 €, чистыми примерно 3 400 €.
- Модель с точностью 30% находит 150 уходящих и удерживает 30. Это около 16 900 €, чистыми примерно 11 900 €.
Модель окупается ровно настолько, насколько она точнее правила на данных, которых не видела при обучении. Проверять это нужно до того, как отключать правило.
ИИ считает, человек решает, что можно оптимизировать
ИИ меняет разделение труда внутри команды роста. Распознавание паттернов и исполнение в масштабе уходят машине. Креатив, эмпатия и этика (что вообще позволено оптимизировать) остаются людям.
Порядок внедрения следует из устройства стека:
- Сшейте идентификацию пользователя и приведите в порядок названия событий.
- Выберите один рычаг с невысокой ценой ошибки, обычно время подсказки в активации, и запустите там петлю с контрольной группой.
- Цену и ключевые сообщения отдавайте автоматике последними, и только при человеке, который читает каждый такой эксперимент.
- Прогноз оттока, на котором держится потолок CAC, обучайте заново по расписанию.
Последний пункт измеряется в деньгах: ошибка в два процентных пункта оттока сдвигает допустимый бюджет привлечения на треть, и замечают её обычно уже в квартальном отчёте по привлечению, когда деньги потрачены.