Регистрация в SaaS завершена, а работа не началась: что измерять

Измеряйте активацию SaaS по первому подтверждённому полезному сценарию, а не по регистрации или закрытым подсказкам интерфейса. Выберите единицу анализа — человека либо организацию — и одинаковое окно наблюдения. Иначе новые регистрации без времени на работу занизят показатель, а действия нескольких сотрудников одной компании будут посчитаны как несколько клиентов.

Какую пользу обещает продукт

Для начала опишите результат со стороны клиента: какую работу он сможет завершить после подключения. Вход, заполнение профиля и приглашение коллег могут готовить этот результат, но не обязательно дают его сами. Не выбирайте событие только потому, что его проще записать в аналитику.

В документации PostHog об активации отдельно отмечено, что регистрация и вход ещё не означают использования ценности продукта. События активации различаются у разных сервисов. Ниже — собственная гипотеза для вымышленного SaaS согласования документов, а не реальные показатели наших платформ.

Одна организация, несколько ролей

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

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

Что именно должно попасть в событие

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

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

Повтор одного технического события не должен повторно активировать компанию. Но и общий идентификатор пользователя без связи с организацией не годится, если человек работает в нескольких пространствах. Проверьте обе ситуации до использования показателя в отчёте руководителя.

Почему одинаковое окно меняет знаменатель

Для примера выберем окно первых семи суток после создания организации. Это учебная договорённость, а не рыночная норма. На дату среза зарегистрировано 40 организаций, но полный срок наблюдения прошёл только у 30. Из этих тридцати восемь выполнили выбранный сценарий в пределах окна.

Доля активации среди организаций с полным окном равна 8 / 30, то есть примерно 26,7%. Если разделить те же восемь на все 40, получится 20%, но это другой знаменатель: десять новых организаций ещё не получили одинакового времени. Их будущий исход пока неизвестен, а не доказанно отрицателен.

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

Как разбирать незавершённые шаги

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

Успешное прохождение обучения тоже не заменяет результат. Человек может закрыть все подсказки и не понимать, как выполнить собственную работу. Вместо добавления ещё одного обязательного тура сначала проверьте, можно ли пройти основной путь и увидеть итог без помощи команды продукта.

Для проверки интерфейса используйте учебные документы и разрешённые наблюдения. Не нужно читать рабочую переписку клиента или раскрывать его файлы всем аналитикам. Когда причины не установлены, так и отмечайте их, не называя каждое незавершение неудобством интерфейса.

Когда пересматривать саму метрику

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

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

1. Опишите первый полезный результат клиента.
2. Выберите человека или организацию как единицу анализа.
3. Согласуйте роли, успешные события и исключения демоданных.
4. Задайте одинаковое окно и точку его начала.
5. Проверьте повторные события и работу человека в разных организациях.
6. Показывайте полный знаменатель и незавершённое окно отдельно.
7. Разбирайте препятствия и пересматривайте гипотезу по дальнейшей работе.

Для разработки SaaS-платформы передайте маршрут первой пользы вместе с определением события. В веб-приложении согласуйте роли и подтверждение результата. При автоматизации отчётов проверьте учебные 40, 30 и восемь организаций: отчёт должен объяснять разницу 20% и 26,7%, а не скрывать её округлением.