22 августа 2026 г.
Проблема второй задачи: почему активация умирает после первой победы
Регистрацию обвешивают аналитикой до предела. А момент, который решает судьбу удержания, наступает позже — когда пользователь берётся за то главное, ради чего существует ваш продукт, и никто за этим не следит.
Все разборы онбординга, на которых мне доводилось сидеть, идут по одному сценарию. Кто-то показывает воронку регистрации, указывает на провал между «создал аккаунт» и «активирован», и все в комнате соглашаются исправить первые пять минут. Форма покороче. Пустое состояние получше. Продуктовый тур. А потом цифры почти не двигаются, потому что пользователь, который уходит, редко теряется в первые пять минут. Он теряется на второй неделе, когда пытается сделать то, ради чего пришёл, — и за этим моментом никто не следит.
Я хочу дать этому моменту имя, показать, как найти его в ваших собственных данных, и доказать, что именно здесь помощь внутри продукта даёт самую большую отдачу.
Две задачи, одна воронка
В каждом продукте есть первая задача и вторая задача, и это вещи совершенно разной природы.
Первая задача — это настройка. Создать рабочее пространство, пригласить коллегу, подключить источник, импортировать файл. Она линейна и одинакова для всех, а раз она одинакова для всех, по ней легко провести тур, её легко покрыть аналитикой и легко оптимизировать. Сюда уходит большая часть усилий по онбордингу, и, честно говоря, у большинства продуктов здесь всё в порядке.
Вторая задача — это сама работа. Собрать первый настоящий отчёт. Запустить первую кампанию. Провести первую сверку. Это то, что назвал бы пользователь, спроси вы его, зачем он зарегистрировался. Она многошаговая, ветвится в зависимости от его данных, зависит от решений, принятых при настройке, и выглядит по-разному в стартапе из двух человек и в корпорации на 400 рабочих мест.
Воронка сводит обе к одной цифре. «Активированным» пользователя обычно считают по первой задаче — ведь именно она порождает чистые события, — и поэтому дашборд зеленеет ровно в тот момент, когда начинается настоящий риск.
Посмотрите на своё определение активации. Если каждое событие в нём может выполнить пользователь, который ещё не получил с помощью вашего продукта ничего ценного, ваша метрика активации измеряет настройку, а не успех.
Почему пользователи уходят именно на второй задаче
Дело не в том, что вторая задача сложнее, хотя обычно так и есть. Дело в том, что на ней пользователь остаётся без помощи — причём вполне определённым образом.
Тура уже нет. Продуктовые туры срабатывают один раз: при первом визите, на заранее известном пути. Вторая задача случается на четвёртый день, на странице, куда тур не заглядывал, и начинается из состояния, которого автор тура не предусмотрел.
Документация написана для всех. Она объясняет функцию. Но не может объяснить функцию для этого аккаунта, с этими данными, на этом тарифе, после того как пользователь пропустил третий шаг настройки. Чем сильнее ваш продукт подстраивается под клиента, тем меньше может сказать общая документация.
С вашей стороны никто не знает, что это происходит. Пользователь, застрявший на настройке, иногда пишет в поддержку. Застрявший на второй задаче обычно не пишет: он думает, что сам виноват, собирается вернуться к ней позже — и не возвращается. Ни тикета, ни записи сессии, которую кто-нибудь посмотрел бы, ни оповещения. Аккаунт затихает и уходит при продлении с чистой историей обращений в поддержку.
На второй задаче продукт перестаёт быть демо и становится работой. И именно в этот момент большинство продуктов перестаёт помогать.
Как найти её в своих данных
События у вас почти наверняка уже есть — вы просто провели черту не там. Вот упражнение, которое я бы сделал на этой неделе.
1. Запишите одним предложением работу, ради которой новый клиент зарегистрировался. Не функцию — работу. «Отправить рассылку по настоящему списку». «Закрыть месяц».
2. Сопоставьте с этой работой минимальную последовательность событий, которая доказывает, что она сделана. От трёх до шести событий, и в конце — что-то, что существует в реальном мире: отправленное письмо, закрытый период, опубликованная страница.
3. Измерьте долю пользователей, которые проходят эту последовательность в течение 14 дней после завершения настройки. Назовите это выполнением второй задачи.
4. Поставьте эту цифру рядом с вашим нынешним показателем активации.
Разрыв между этими двумя цифрами и есть ваша настоящая проблема онбординга, и у большинства продуктов это самая большая величина во всей воронке.
1-я задача — настройка — линейная, с туром, покрыта аналитикой
2-я задача — сама работа — ветвится, без тура, здесь пользователи и уходят
14 дней — разумное окно для выполнения второй задачи
Как обычно выглядит эта цифра
Все команды, которых я просил это посчитать, получали одну и ту же картину: активация — в диапазоне 40–60%, выполнение второй задачи — где-то между 10 и 25%. Половина пользователей, которых ваш дашборд называет активированными, так и не делает того, ради чего пришла. Это не проблема документации и не вопрос шлифовки UX. Это проблема помощи в нужный момент.
Почему очевидные решения не дотягивают
Больше туров. Команды пытаются сделать тур по второй задаче и понимают, почему этого никто не делает: она ветвится. Тур, который работает для пустого аккаунта, ломается на аккаунте с импортированными данными; тур для тарифа Growth указывает на кнопку, которой нет в тарифе Launch. В итоге вы поддерживаете целое дерево туров, которые портятся при каждом изменении интерфейса.
Документация получше. Документация — правильный ответ для справки и неправильный для застрявшего пользователя. Ему приходится уйти из продукта, найти нужную страницу, переложить общие инструкции на свой конкретный экран и вернуться — и всё это время держать в голове недоделанное намерение. Большинство на это не идёт.
Чат-виджет. Уже ближе: помощь хотя бы находится в продукте. Но бот, прочитавший вашу документацию, отвечает текстом, а текст всё равно приходится переводить в клики. К тому же он не видит экран пользователя и не может знать, что кнопка, которую он описывает, на тарифе этого пользователя неактивна.
Каждое из этих решений немного улучшает цифру, и кажется, что направление верное. Это не так. У всех у них один потолок: они описывают продукт пользователю, вместо того чтобы проходить задачу вместе с ним.
Что на самом деле сдвигает цифру
Чаще всего вторую задачу выполняют клиенты, у которых есть персональный живой менеджер по успеху клиентов. Это не совпадение, и дело не в том, что менеджер знает продукт лучше документации. Дело в том, что он делает три вещи, которые документации не под силу:
– Видит реальную ситуацию пользователя — его экран, его данные, его тариф — и подсказывает конкретный следующий шаг, а не общий.
– Проводит пользователя по шагам вживую, а не описывает их. Показать на кнопку лучше, чем назвать её.
– Замечает тишину. Когда аккаунт застревает на второй задаче, менеджер выходит на связь раньше, чем пользователь решит, что продукт ему не подходит.
Экономика живого менеджера сходится только начиная с определённой суммы контракта. Эта проблема так интересна мне потому, что все три вещи теперь умеет делать софт: читать отрисованный интерфейс, подводить курсор к нужному элементу, следить за использованием и заговаривать первым. В этом и состоит вся идея Barkan — менеджер по успеху клиентов для каждого аккаунта, а не только для крупных, — и именно на второй задаче он оправдывает своё место.
– Ваша метрика активации, скорее всего, измеряет настройку, а не успех. Определите выполнение второй задачи и отслеживайте его отдельно.
– Пользователи уходят на второй задаче, потому что на ней нет тура, нет документации в контексте и стоит тишина, а не потому, что она слишком сложная.
– Решение — помощь, которая видит экран, показывает шаг и заговаривает первой. У попыток получше описать продукт низкий потолок.
Практический план на ближайшие 30 дней
1. На этой неделе: определите вторую задачу и измерьте, сколько пользователей её выполняет. Приготовьтесь к неприятной цифре.
2. Вторая неделя: просмотрите десять сессий пользователей, которые начали вторую задачу и не закончили. Запишите, на каком именно шаге застрял каждый. Эти шаги сгруппируются.
3. Третья неделя: добавьте помощь в двух местах, где пользователи застревают чаще всего, — в продукте, на том самом экране, с учётом состояния пользователя. Если у вас нет слоя подсказок, даже контекстное приглашение, которое открывает чат с человеком, лучше, чем ничего.
4. Четвёртая неделя: измерьте снова. Главная цифра — выполнение второй задачи; всё остальное — лишь косвенные показатели.
Первая задача заводит пользователя в здание. Вторая решает, останется ли он. Покройте её аналитикой, дайте пользователю на ней помощника и перестаньте поздравлять себя с воронкой, которая заканчивается у входной двери.
Barkan видит экран пользователя, показывает следующий шаг живым курсором и заговаривает первым, когда аккаунт застревает. Один тег script, $25 на балансе, без привязки карты.
«Большинству пользователей не нужен ещё один ответ. Они хотят, чтобы им показали путь или чтобы всё сделали за них. В этом весь продукт.»
Gabriel Lancelot
Сооснователь Barkan
