Ловушка онбординга: почему улучшение онбординга не улучшает удержание

Проблема, которую не видит большинство команд

Посмотрите на свою воронку. Допустим, 78% новых пользователей завершают онбординг. Отлично. Теперь посмотрите на тех, кто остаётся через 90 дней. Цифра падает до 51%. Разрыв в 27 процентных пунктов — и это не исключение. Это типичная картина для B2B SaaS, которую команды либо не замечают, либо объясняют «сложным рынком».

Почему это происходит? Потому что большинство команд путают два понятия: завершение онбординга и активация пользователя. Завершение онбординга — событие, которое вы контролируете. Это набор шагов, которые пользователь проходит после регистрации: заполнил профиль, подключил интеграцию, посмотрел видео. Активация — совсем другое. Это момент, когда пользователь впервые получает ценность, релевантную его роли и задаче.

Команды улучшают онбординг: добавляют туториалы, сокращают количество шагов, делают интерфейс понятнее. Завершаемость растёт. Удержание — нет. Потому что пользователь может пройти весь онбординг и не получить ценности. Он выполнил инструкции — и ушёл, потому что инструкции не равны ценности.

В российском B2B SaaS эта ловушка имеет дополнительное измерение. Комплексные закупки с IT-согласованием создают то, что можно назвать командно-зависимой ловушкой. Пользователь регистрируется, проходит онбординг, но для получения реальной ценности продукта нужны действия коллеги: настройка прав доступа, подключение интеграции, согласование с отделом. Один человек проходит онбординг. Команда не получает ценность. Один человек уходит. Команда не возвращается.

"Активация — это не про завершение шагов. Это про достижение результата, который пользователь не мог получить до вашего продукта."

— Amplitude, Product Activation Framework

Когда вы улучшаете онбординг, вы улучшаете интерфейс. Но интерфейс — это только один слой. Под ним — архитектура активации: структура продукта, которая определяет, способен ли пользователь вообще добраться до ценности. Если архитектура не работает, никакой UX не спасёт.

Архитектура активации: фреймворк для диагностики

Определение, которое имеет значение

Большинство команд не могут ответить на простой вопрос: что значит «активированный пользователь» в вашем продукте? Определения варьируются от «зарегистрировался» до «использует все фичи». Ни одно из них не работает.

Единственное определение активации, которое имеет значение:

Без этих трёх компонентов у вас нет активации. Есть завершённый онбординг. Это не одно и то же.

Вывод: Если вы не можете сформулировать активацию в терминах ролевой ценности, которую можно измерить, — вы не управляете активацией. Вы управляете интерфейсом.

Модель Фогга применительно к онбордингу

BJ Fogg предложил формулу поведения: B = M × A × T. Behavior происходит, когда Motivation, Ability и Trigger совпадают одновременно. В контексте онбординга эта модель объясняет, почему улучшение туториалов так редко работает.

M (мотивация) — внутреннее желание пользователя достичь результата. Она падает с каждой минутой после регистрации. К моменту, когда пользователь видит ваш туториал, мотивация уже ниже, чем в момент клика на кнопку «Sign Up».

A (способность) — может ли пользователь выполнить требуемое действие? Это то, что SaaS-команды обычно оптимизируют: сокращают количество шагов, упрощают формы. Но способность — это не только когнитивная нагрузка интерфейса. Это весь контекст использования: время пользователя, его навыки, доступ к необходимым ресурсам.

T (триггер) — напоминание или стимул к действию. В SaaS онбординге триггеры обычно встроены в продукт: подсказки, уведомления, напоминания по email. Проблема в том, что триггер без мотивации и способности — это шум.

Когда вы добавляете ещё один туториал, вы увеличиваете A на миллисекунду. Но M падает экспоненциально с течением времени. T становится раздражителем, а не катализатором. Формула ломается.

Вывод: Оптимизация внимания (attention) в онбординге — это работа с самым слабым компонентом формулы. Фокус должен быть на M и T: поддержание мотивации через раннюю ценность и создание триггеров, которые срабатывают в момент готовности пользователя.

48-часовое окно активации

В большинстве B2B SaaS-продуктов существует структурное окно, в которое активация должна произойти. Это не эвристика и не «лучшая практика» — это паттерн, который повторяется в данных.

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

Это означает, что архитектура активации должна быть спроектирована вокруг 48-часового окна. Не «когда-нибудь пользователь доберётся до ценности», а «ценность случается в окно максимальной готовности».

Важно: 48 часов — это не универсальный закон. Для enterprise-продуктов с длительным циклом согласования окно может быть 2–3 недели. Для простых self-serve инструментов — 24 часа. Но принцип остаётся: окно конечно, и оно определяет архитектуру, а не UX.

Вывод: Архитектура активации должна быть построена вокруг окна готовности пользователя. Если ваш первый success milestone случается на 5-й день — архитектура сломана, и никакой UX не исправит.

Иерархия исправления

Когда команды обнаруживают проблему активации, они обычно начинают с того, что видят: UX. Переделывают туториал, упрощают форму регистрации, добавляют прогресс-бар. Это самый дорогой способ не решить проблему.

Правильная иерархия:

1. Персональные пути активации. Разные пользователи приходят с разными jobs-to-be-done. Инженер хочет увидеть API в первые минуты. Маркетолог — подключить источник данных. CEO — увидеть dashboard с метриками. Один онбординг для всех — это отсутствие онбординга для каждого.
2. Архитектура продукта. Может ли пользователь вообще получить ценность за разумное время? Это вопрос не UX, а структуры продукта. Нужна ли интеграция с CRM для базовой ценности? Нужен ли админ для настройки прав? Если базовая ценность требует действий, которые пользователь не контролирует, — архитектура сломана.
3. UX онбординга. Только после того, как персональные пути определены и архитектура обеспечивает достижимость ценности, имеет смысл работать над UX. До этого — это косметика.

В российском контексте есть дополнительный фактор: комплексные закупки с IT-согласованием. Продукт может требовать подключения к корпоративной инфраструктуре, настройки SSO, согласования с отделом информационной безопасности. Пользователь регистрируется, проходит онбординг, но для получения ценности нужны действия другого человека. Это командно-зависимая ловушка, и она не решается улучшением UX.

Вывод: UX — последний слой, который стоит трогать. Сначала — персональные пути. Потом — архитектура, обеспечивающая достижимость ценности. Потом — интерфейс.

Данные и наблюдения

Ловушка онбординга — не теоретическая конструкция. Это паттерн, который виден в данных продуктов, прошедших через нашу диагностику. Вот что мы наблюдаем.

Разрыв завершаемость — удержание

В типичном B2B SaaS-продукте завершаемость онбординга составляет 60–80%. Это означает, что 6–8 из 10 пользователей доходят до конца вашего onboarding flow. Через 90 дней остаётся 40–55%. Разрыв в 20–30 процентных пунктов — и это при том, что команды обычно не измеряют этот разрыв напрямую. Они измеряют завершаемость и удержание по отдельности, не связывая их причинно.

Когда мы проводим аудит активации, первый вопрос: «Что происходит между завершением онбординга и 90-м днем?» Ответ обычно один из двух: «Мы не знаем» или «Мы отправляем email-цепочку». Email-цепочка — это попытка решить архитектурную проблему через коммуникацию. Это не работает, потому что проблема не в информировании.

Почему данные из Яндекс.Метрики и Amplitude показывают одно и то же

Российские команды часто работают с Яндекс.Метрикой или ClickHouse вместо Amplitude и Mixpanel. Инструменты разные, но паттерн — одинаковый. Разрыв между завершаемостью и удержанием виден в любой системе, если вы правильно настроили события.

Проблема в том, что большинство российских SaaS-команд не настраивают события активации как отдельный класс. Они отслеживают регистрации, завершение шагов онбординга, первую сессию. Но не отслеживают момент получения ролевой ценности. Без этого события в данных вы не можете управлять активацией.

"Компании, которые определяют активацию как завершение шагов, систематически переоценивают свое удержание. Компании, которые определяют активацию как достижение ценности, видят реальную картину."

— Amplitude, Product Activation Research

Что мы видим после исправления архитектуры

Когда команды переходят от оптимизации UX к исправлению архитектуры, результаты меняются. Мы наблюдали случаи, когда изменение персональных путей активации — без единого изменения в интерфейсе — увеличивало конверсию из регистрации в активированного пользователя с 18% до 34%.

Это не магия. Это исправление структурной проблемы. Пользователь раньше получал ценность — потому что путь к ней перестал требовать действий, которые он не контролирует. Или потому что персональный путь стал релевантным его роли с первой минуты.

Что делать вместо этого

Если улучшение онбординга не решает проблему удержания, что решает? Конкретные действия, а не абстрактные принципы.

Определите активацию через ролевую ценность

Это первый и самый важный шаг. Сядьте с продуктовой командой и ответьте на вопрос: какую ценность получает пользователь в каждой роли, которую вы обслуживаете? Инженер получает ценность, когда впервые запускает рабочий процесс через API. Маркетолог — когда видит первые данные в dashboard. Продакт-менеджер — когда создаёт первую функцию и проверяет гипотезу.

Ценность должна быть конкретной и измеримой. Не «понимает продукт», а «запустил первый рабочий процесс». Не «освоил интерфейс», а «создал первый отчёт». Определение без измеримости — это wishful thinking.

Постройте путь к ценности вокруг 48-часового окна

После того как вы определили ролевую ценность, спросите: может ли пользователь получить эту ценность за 48 часов? Если для этого нужна интеграция с CRM, настройка SSO, согласование с админом — архитектура не работает. Варианты:

• Создайте упрощённый путь, который даёт базовую ценность без внешних зависимостей.
• Разделите активацию на этапы: сначала пользователь получает минимальную ценность сам, потом — расширенную с подключением интеграций.
• Измените порядок действий так, чтобы внешние зависимости случались после, а не до получения ценности.

Внедрите персональные пути

Один онбординг для всех — это компромисс, который не работает. Вместо этого:

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

Персональные пути — это не про персонализацию интерфейса. Это про то, чтобы пользователь сразу видел путь к ценности, релевантный его задаче. Инженер не хочет смотреть видео о том, как подключить источник данных. Он хочет увидеть код.

Измеряйте активацию, а не завершаемость

Уберите из своих дашбордов метрику «завершённость онбординга» как primary KPI. Замените её на метрику активации по ролям. Если у вас три роли — у вас три отдельных cohort analysis. Каждый показывает конверсию из регистрации в активированного пользователя.

Это не сложно технически. Это сложно культурно. Потому что завершаемость онбординга — это красивая цифра, которую легко показать на board deck. Активация — это честная цифра, которая может быть ниже, чем хочет руководство.