Customer Health Score для trial: предсказываем отток и адаптируем онбординг

Каждый месяц десятки trial-пользователей регистрируются в вашем B2B SaaS-продукте, но лишь малая часть доходит до оплаты. Вы тратите ресурсы на демо-звонки и письма, а отток остаётся высоким, до 80% на пробном периоде. Проблема в том, что вы не видите, кто из пользователей действительно вовлечён, а кто просто «замёрз» после первого входа. Customer health score (CHS) для trial решает эту задачу: он превращает сырые данные о поведении в понятный сигнал, насколько вероятно, что пользователь конвертируется в платящего клиента. В этой статье вы узнаете, как построить такую систему с нуля, какие метрики учитывать и как автоматизировать онбординг на основе сегментов здоровья, без привлечения разработчиков.

Мы разберём практический кейс: от сбора поведенческих данных (активация ключевых функций, частота логинов) и опросов NPS до интеграции с CRM и построения скоринговой модели. Вы поймёте, почему health score для trial отличается от аналогичной метрики для платящих клиентов, и как адаптировать онбординг под каждый сегмент риска. В конце, конкретные метрики для оценки эффективности системы и советы по её оптимизации в условиях, когда каждая минута пользователя в trial имеет значение.

Почему health score, ключевой инструмент для trial

Health score становится ключевым инструментом для trial, потому что он превращает разрозненные сигналы поведения, обратной связи и данных CRM в единый прогностический показатель, который позволяет предсказывать отток за 7, 14 дней до фактического ухода пользователя. В отличие от простых метрик вроде MAU или процента завершения чеклиста, health score учитывает комплекс факторов: частоту ключевых действий, время до первого value, ответы на NPS и активность в поддержке. Это даёт возможность не просто констатировать проблему, а вмешиваться до того, как пользователь потеряет интерес. Например, если health score падает ниже 40, система автоматически запускает сценарий с персональным приглашением на вебинар, и конверсия в платящих клиентов у таких пользователей вырастает в среднем на 18%. Без health score команда узнаёт об оттоке только постфактум, когда пользователь уже удалил аккаунт или не заходил 10 дней подряд.

Для B2B SaaS, где trial часто длится 14, 30 дней, каждый день промедления с корректировкой онбординга снижает конверсию в платящих клиентов на 3, 5%. Health score позволяет сегментировать пользователей по уровню риска и запускать адаптивные сценарии, например, персональный вебинар для «спящих» или скидку для колеблющихся, без участия продакт-менеджера. В июле 2026 года такой подход уже стал стандартом для продуктов, которые хотят удерживать trial-пользователей в условиях растущей конкуренции. Типичная ошибка, использовать только один сигнал, например количество входов в систему. Но пользователь может заходить каждый день, но так и не совершить ключевое действие (first value), что делает MAU ложноположительным индикатором. Health score, объединяя 5, 7 разнородных сигналов, даёт точность предсказания оттока до 85%, тогда как отдельные метрики, не более 60%.

Третья причина, почему health score незаменим для trial, он позволяет выявить скрытые паттерны, которые не видны при ручном анализе. Например, пользователи, которые открывают документацию более 3 раз за первый день, но не пробуют функционал, имеют в 2 раза выше вероятность оттока, чем те, кто сразу начинает работу. Health score фиксирует такие корреляции и автоматически корректирует онбординг: предлагает интерактивный тур вместо текстовой документации. Без него команда тратит недели на анализ логов и всё равно упускает 30, 40% сигналов. Кроме того, health score даёт единый язык для обсуждения между продакт-менеджерами, саппортом и сейлзами: вместо «пользователь какой-то неактивный» появляется конкретная цифра и порог срабатывания.

Наконец, health score критичен для trial, потому что он масштабирует экспертизу онбординга. В молодых SaaS-продуктах онбординг часто строится на интуиции продакт-менеджера, но при росте до 100+ trial-пользователей в месяц ручное управление становится невозможным. Health score автоматизирует приоритизацию: пользователи с низким скором получают максимальное внимание (персональные письма, звонки), а высокие, только автоматические подсказки. Это позволяет команде из 2, 3 человек обрабатывать до 500 trial-пользователей в месяц, не теряя качества. По данным обобщённых кейсов B2B SaaS, внедрение health score сокращает time-to-value для «спящих» пользователей на 40% и увеличивает конверсию в платных клиентов на 15, 25% в течение первых двух месяцев после запуска.

• Отток на trial остаётся высоким (в среднем 60, 80% для B2B SaaS), несмотря на стандартные тактики онбординга, приветственные письма и туториалы перестали работать как дифференциатор. Персонализированный онбординг на основе health score может снизить отток на 20, 30% уже в первые 14 дней за счёт своевременного вмешательства.

• Простые метрики, MAU, завершение чеклиста, количество входов, не предсказывают отток, потому что не отражают качество взаимодействия с продуктом и субъективное восприятие ценности. Например, пользователь может завершить чеклист на 100%, но так и не понять, какую проблему решает продукт, и уйти после trial.

• Health score объединяет поведенческие данные (частота ключевых действий, время до активации), опросные (NPS, CSAT) и CRM-сигналы (тикетов в поддержку, статус контрагента) в единый числовой показатель от 0 до 100. Взвешенная модель с коэффициентами, подобранными на исторических данных, даёт точность прогноза оттока до 85%.

• Своевременное выявление «групп риска» (health score ниже 40) позволяет менять онбординг до ухода: например, предложить помощь консультанта или упростить первый сценарий использования. В одном обобщённом кейсе B2B SaaS после внедрения такого подхода конверсия в платных клиентов среди «спящих» выросла с 8% до 22%.

• Автоматические сценарии на основе health score, например, триггерное письмо с кейсом при падении показателя ниже порога, сокращают время реакции с 2, 3 дней до нескольких минут. Это особенно важно для trial длительностью 14 дней, где каждый час промедления снижает вероятность конверсии.

• Внедрение health score в trial повышает конверсию в платных клиентов на 15, 25% за счёт того, что продукт подстраивается под реальные паттерны поведения каждого пользователя. При этом затраты на разработку модели окупаются в течение 1, 2 месяцев за счёт снижения оттока и роста LTV.

Какие данные нужны для health score и как их собрать без кода

Для расчёта health score trial-пользователей нужны три категории данных: поведенческие метрики, опросные показатели и CRM-атрибуты. Собрать их без программирования позволяют готовые интеграции с CRM, встроенные формы опросов и JavaScript-API, которые передают события в единую аналитическую платформу. Например, userStream объединяет эти источники в одной воронке и автоматически рассчитывает health score в реальном времени. Без такого объединения типичная B2B SaaS-команда тратит до 40% времени на ручной экспорт из 3, 5 разных систем, что задерживает реакцию на отток на 2, 3 недели.

Поведенческие данные дают картину реального взаимодействия пользователя с продуктом. Опросные метрики фиксируют субъективное восприятие. CRM-атрибуты уточняют контекст (размер команды, источник трафика, оставшееся время trial). Комбинируя их, можно построить надёжный предиктор оттока уже на второй неделе пробного периода. Исследования показывают, что модели, использующие все три типа данных, предсказывают отток с точностью 85, 92%, тогда как модели только с поведенческими метриками дают 60, 70%.

Ключевая ошибка, пытаться собрать все возможные метрики без приоритизации. В B2B SaaS с длинным trial (14, 30 дней) достаточно 5, 7 ключевых индикаторов: 3, 4 поведенческих, 1, 2 опросных и 1, 2 CRM-атрибута. Например, для платформы управления проектами достаточно отслеживать: создание первого проекта, приглашение хотя бы одного участника, выполнение первого задания, частоту входов (минимум 3 раза за первую неделю), NPS после 7-го дня и размер команды (команды из 3+ человек конвертируются на 25% чаще).

• Поведенческие: частота входов в систему (минимум 3 раза за первую неделю), количество выполненных шагов онбординга (например, заполнение профиля, создание первого проекта, загрузка файлов), использование ключевых функций (активация фичи, которая коррелирует с удержанием, для CRM это может быть импорт контактов, для аналитики, создание первого отчёта). Эти данные собираются автоматически через JavaScript-API при каждом действии пользователя, latency передачи, до 2 секунд.

• Опросные: NPS и CSAT после первой активации продукта (например, через 24 часа после создания первого проекта), микроопросы при попытке уйти (почему churn?, выбор из 3, 4 вариантов: сложно, дорого, не подходит). Встраивание таких опросов без кода поддерживают большинство low-code платформ, достаточно вставить ссылку или виджет, настройка занимает 15 минут. Конверсия ответов на микроопросы, 8, 12%, что даёт качественную обратную связь для уточнения health score.

• CRM-атрибуты: дата окончания trial (для расчёта оставшихся дней), текущий тариф (бесплатный, пробный, платный), источник трафика (реклама, органика, реферал, партнёрская ссылка, пользователи из рефералов имеют на 30% более высокий health score), размер команды (1, 2, 3, 10, 10+ человек) и роль пользователя (администратор, редактор, читатель). Эти поля синхронизируются через готовые коннекторы к amoCRM или Bitrix24, обновление данных, раз в час.

• Сбор без кода: userStream предоставляет JavaScript-API для отправки кастомных событий (достаточно вставить скрипт на сайт, настройка 10 минут), встроенные шаблоны опросов (NPS, CSAT, микроопросы, выбираете из библиотеки) и готовые интеграции с популярными CRM (amoCRM, Bitrix24, HubSpot). Все данные агрегируются в дашборде, где health score рассчитывается по заданным правилам (например, вес каждого показателя настраивается слайдерами) без написания SQL или Python. Время от установки до первого health score, 2, 3 часа.

Типичная ошибка при сборе данных, игнорирование временных меток. Например, если пользователь выполнил 5 шагов онбординга, но все за один день, а потом не заходил неделю, это хуже, чем 3 шага, распределённые равномерно. Поэтому в health score важно учитывать не только факт действия, но и его равномерность: для trial длиной 14 дней оптимально минимум 2, 3 активности в неделю. В userStream это настраивается через правило «равномерность активности»: если активность падает ниже порога, health score снижается на 15, 20 пунктов.

Ещё одна распространённая проблема, дублирование данных из-за нескольких источников. Например, событие «создание проекта» может передаваться и через JavaScript-API, и через CRM-интеграцию. В результате health score получает двойной вес для одного действия. Решение, настроить дедупликацию на уровне платформы: в userStream есть правило «уникальное событие по ID пользователя и типу события», которое автоматически отбрасывает дубликаты. Это повышает точность health score на 10, 15%.

Для быстрого старта без кода рекомендуется начать с трёх источников: JavaScript-API для поведенческих данных (5, 7 ключевых событий), встроенный опрос NPS после 7-го дня trial и CRM-синхронизация для даты окончания trial и источника трафика. Этого достаточно, чтобы построить первую версию health score с точностью 70, 80% уже через неделю. По мере накопления данных (через 2, 3 цикла trial) можно добавить микроопросы и расширить поведенческие метрики.

Построение модели health score для B2B SaaS

Модель health score для trial-пользователей строится на взвешенной комбинации поведенческих метрик, обратной связи и данных из CRM, где каждый фактор получает вес, пропорциональный его влиянию на конверсию в платящих клиентов. В B2B SaaS с длинным циклом сделки такой подход позволяет не просто фиксировать активность, а количественно оценивать вероятность успешного завершения trial. Веса можно определить двумя способами: через логистическую регрессию на исторических данных (если накоплено хотя бы 200 завершённых trial) или экспертно, опираясь на опыт команды продакт-менеджеров и Customer Success.

На практике рабочая модель часто выглядит как три блока факторов с разными весами. Поведенческие сигналы (частота входов, использование ключевых функций, завершение действий в онбординге) получают 50% влияния, так как они напрямую отражают вовлечённость. NPS или CSAT, собранный на второй неделе trial, добавляет 30%, это субъективная, но важная оценка ценности продукта. Оставшиеся 20% приходятся на CRM-атрибуты: размер компании, должность контактного лица, источник лида и количество участников команды.

• Выбор факторов и взвешивание: начните с корреляционного анализа, отберите 5-7 метрик с наибольшей связью с конверсией, затем присвойте веса через регрессию или методом экспертных оценок (например, по шкале от 1 до 5).

• Пример распределения: поведенческие сигналы (50%), завершение ключевого действия, частота сессий, время в продукте; NPS/CSAT (30%), опрос на 14-й день trial; CRM-атрибуты (20%), должность, размер компании, источник трафика.

• Определение порогов: зелёная зона (>80 баллов), пользователь активно осваивает продукт, высокая вероятность конверсии; жёлтая (50-80), требуется точечная поддержка, например, персональный демо-звонок; красная (<50), высокий риск оттока, нужен автоматический сценарий реактивации.

• Анализ исторических данных: соберите данные по 300-500 завершённым trial за последние 6-12 месяцев, рассчитайте health score для каждого и проверьте, как часто пользователи из зелёной зоны конвертировались (целевой уровень, выше 70%), а из красной, отваливались (ниже 20%).

• Валидация модели: после разметки исторических данных проведите A/B-тест на новой когорте trial, сравните точность предсказания оттока с текущим подходом (например, по метрике AUC или precision/recall).

Сегментация по health score в userStream

Чтобы сегментировать trial-пользователей по health score в userStream, создайте три сегмента на основе числового атрибута health_score: «Healthy» (>70 баллов), «At Risk» (40, 70 баллов) и «Critical» (<40 баллов). Каждый раз при получении нового события, например, логина, выполнения ключевого действия или спада активности, JavaScript API userStream пересчитывает health score и автоматически обновляет принадлежность пользователя к сегменту. Это позволяет в реальном времени видеть распределение trial-пользователей по уровню риска и мгновенно реагировать на изменения.

• Создайте сегменты «Healthy», «At Risk» и «Critical» в userStream, используя условия на числовой атрибут health_score: например, «Healthy», health_score > 70, «Critical», < 40.

• Автоматическое обновление health_score происходит через JavaScript API при каждом значимом событии: отправка данных о прогрессе онбординга, частоте входов или заполнении профиля, userStream пересчитывает атрибут и перераспределяет пользователя по сегментам за секунды.

• Пример полезного динамического сегмента: пользователи, которые стали «At Risk» за последние 3 дня. Такой сегмент позволяет сфокусироваться на тех, чьё здоровье резко ухудшилось, и запустить срочные сценарии удержания.

• Готовые сегменты используйте для персонализации контента в приложении: «Healthy» показывайте расширенные чеклисты, «At Risk», подсказки и призывы к действию, «Critical», специальное предложение продлить триал со скидкой.

• Сегменты, построенные на health score, легко интегрировать с email-рассылками и push-уведомлениями: например, для сегмента «Critical» настроить автоматическую отправку письма с контактом менеджера.

Автоматические сценарии онбординга в зависимости от health score

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

• Для сегмента «Healthy»: отправляйте углублённые туры по продвинутым функциям и реферальные приглашения, чтобы укрепить лояльность и стимулировать вирусный рост.

• Для сегмента «At Risk»: выводите персонализированный чеклист с пропущенными шагами онбординга и приглашайте на тематический вебинар по ранним успехам.

• Для сегмента «Critical»: показывайте срочную подсказку с контактом поддержки и предлагайте скидку на первый месяц, чтобы снизить барьер для конверсии.

• Переходы между сегментами триггерят смену сценария: например, улучшение health score до «Healthy» автоматически заменяет кризисные сообщения на развивающие туры.

Метрики и оптимизация системы health score

Метрики системы health score показывают, насколько точно модель предсказывает отток и конверсию trial-пользователей, а её оптимизация строится на регулярном A/B-тестировании и пересчёте весов на свежих данных. Главный показатель точности, доля «красных» пользователей, которые действительно ушли (churn rate в сегменте high risk), и доля «зелёных», которые конвертировались в платящих. Если «красные» уходят в 80% случаев, а «зелёные» конвертируются в 60%, модель работает эффективно; если расхождения велики, требуется корректировка порогов и весов.

A/B-тестирование позволяет проверять гипотезы: например, изменяя вес события «просмотр документации» с 0,1 до 0,2, можно увидеть, улучшилась ли предиктивная сила для сегмента small business. Итеративное обновление модели раз в месяц на основе новых данных trial-потоков гарантирует, что health score не устаревает вслед за изменением пользовательского поведения. В одном из B2B SaaS-сервисов после внедрения такой системы и двух циклов оптимизации отток на trial снизился на 18% за квартал, а конверсия «зелёных» выросла на 12 процентных пунктов.

• Отслеживайте точность классификации: процент «красных», которые действительно ушли, и «зелёных», которые стали платящими, это базовые метрики качества health score.

• Проводите A/B-тесты порогов и весов: например, разделите trial-пользователей на две группы, примените разные веса для события «завершение онбординга» и сравните ROC-AUC через 14 дней.

• Обновляйте модель раз в месяц: пересчитывайте веса на основе свежих данных за последние 30 дней, чтобы health score отражал текущие паттерны поведения.

• Используйте lift-анализ: сравнивайте churn rate в сегментах с разными health score до и после оптимизации, рост разницы между «красными» и «зелёными» указывает на улучшение модели.

• Фиксируйте бизнес-эффект: после внедрения health score измеряйте снижение оттока и рост конверсии в сегменте medium risk, чтобы оценить ROI системы.