Как вернуть неактивных trial-пользователей: playbook реактивации in-app

В этой статье, пошаговый playbook для product-команд B2B SaaS, которые хотят вернуть неактивных trial-пользователей с помощью in-app реактивации. Вы узнаете, как сегментировать «холодных» пользователей, настроить поведенческие триггеры, выбрать форматы сообщений (баннеры, центр ресурсов, подсказки) и измерить возврат конверсии. Это не теория, а готовые к внедрению шаги без привлечения разработчиков.

Большинство команд фокусируются на удержании активных trial-пользователей, но те, кто перестал заходить в продукт на 5, 10 дней, часто остаются без внимания. Рассылка писем работает всё хуже из-за спам-фильтров, а точечные in-app сообщения требуют ручной настройки. В результате холодные пользователи превращаются в churn, хотя могли бы вернуться при правильном воздействии.

Этот playbook построен на реальных практиках B2B SaaS и учитывает особенности российского рынка, отсутствие дорогих CDP и необходимость быстрого запуска без кода. Вы сможете применить описанные шаги в userStream или любом другом инструменте in-app воронок. После прочтения у вас будет готовая схема реактивации, метрики для отслеживания и понимание, как итерировать кампании.

Почему реактивация trial, отдельная тактика, а не «дожимание» в конце срока

Реактивация trial, отдельная тактика, потому что она нацелена на пользователей с нулевой или минимальной активностью за последние 7, 14 дней, а не на тех, кто ещё взаимодействует с продуктом в рамках триала. Prevention (снижение оттока) работает с активными пользователями, которые могут уйти, через онбординг, подсказки, вовлечение. Reactivation же возвращает тех, кто уже «холоден»: не заходил в приложение, не отвечал на письма, не выполнил ключевое действие. Для этих двух групп нужны разные сценарии, метрики и каналы касания. Смешивать их в одну воронку, значит тратить ресурсы на нерелевантные сообщения и снижать эффективность обоих подходов. Согласно исследованиям, компании, которые разделяют prevention и reactivation, достигают на 20, 30% более высокого возврата trial-пользователей по сравнению с теми, кто использует единую кампанию, так как каждое сообщение точно соответствует текущему состоянию пользователя.

Критический порог неактивности зависит от цикла сделки и сложности продукта. Для B2B SaaS с недельным trial порогом может быть 3, 4 дня без входа, для месячного триала, 7, 10 дней. Однако определение порога должно опираться на анализ исторических данных: когда пользователи перестают возвращаться естественным образом. Например, если 80% пользователей, не заходивших 5 дней, больше не возвращаются, то порог реактивации, 5 дней. Типичная ошибка, установить порог слишком рано (например, 1 день), когда пользователь ещё может вернуться сам, или слишком поздно (14 дней), когда интерес уже угас. Для сложных B2B-продуктов с длительным циклом сделки (например, ERP) порог может быть 14, 21 день, но реактивация должна начинаться с лёгкого напоминания, а не с агрессивной продажи. Также важно учитывать сезонность: в конце квартала активность может падать, и порог стоит временно увеличить.

Типичные ошибки при реактивации, отправка одинаковых спам-писем всем ушедшим, игнорирование поведенческих сегментов (например, пользователь, который не зарегистрировал платёжные данные, и тот, кто не завершил интеграцию, требуют разных сообщений). Без анализа прошлых действий команда рискует не только не вернуть пользователя, но и усилить негативное впечатление. Ещё одна ошибка, использовать только email, когда in-app-сообщения могут быть эффективнее для пользователей, которые ещё иногда заходят, но не выполняют ключевые действия. Также часто забывают про временной контекст: отправка сообщения в нерабочее время снижает открываемость на 30%. Наконец, отсутствие A/B-тестирования тем и текстов приводит к тому, что кампания не оптимизируется, и результаты остаются низкими. Кроме того, многие команды не отслеживают повторную реактивацию: пользователь может вернуться, снова уйти, и тогда нужно начинать цикл заново, а не считать его потерянным.

Платформы вроде userStream позволяют строить реактивацию без кода, в отличие от Appcues или Userpilot, где сложные сценарии требуют участия разработчиков. Это особенно важно для российских B2B-команд, где время на запуск кампаний ограничено, а CDP-решения часто недоступны. userStream предоставляет готовые сегменты по последней активности, поведенческие триггеры и центр ресурсов для хранения обучающих материалов. Например, можно настроить сценарий: если пользователь не заходил 7 дней, показать ему баннер с предложением завершить онбординг, а через 3 дня, отправить push-уведомление с ссылкой на кейс. Appcues и Userpilot требуют ручной настройки таких цепочек через API, что замедляет запуск. Кроме того, userStream интегрируется с популярными CRM и базами данных, что позволяет обогащать сегменты данными из внешних систем, например, информацией о роли пользователя или размере компании. Это даёт возможность ещё точнее настраивать сообщения.

Рассмотрим типичный B2B SaaS-продукт с 14-дневным trial. После внедрения раздельной тактики реактивации команда настроила сегмент «холодных» пользователей (не заходили 7+ дней) и запустила двухшаговую кампанию: первый шаг, in-app-баннер с напоминанием о ключевой функции, второй, email с персональным предложением демо. В результате 25% пользователей из этого сегмента вернулись и завершили trial, а 10% конвертировались в платящих. До этого единая кампания возвращала лишь 8% пользователей. Ключевым фактором успеха стала персонализация сообщений на основе поведения: тем, кто не завершил онбординг, показывали подсказки, а тем, кто не интегрировался, инструкции по интеграции. Важно отметить, что реактивация не должна быть одноразовой: после возврата пользователя нужно сразу перевести в prevention-сценарий, чтобы удержать его до конца trial.

Выделение реактивации в отдельную тактику также влияет на распределение ресурсов внутри команды. Маркетинг и продукт могут параллельно работать над prevention и reactivation, не конфликтуя за приоритеты. Например, команда онбординга фокусируется на активации новых пользователей, а отдельный специалист или группа занимается реактивацией «холодных». Это позволяет быстрее тестировать гипотезы: для reactivation можно использовать более агрессивные сообщения, не боясь испортить опыт активных пользователей. Кроме того, разделение упрощает отчётность: метрики реактивации (re-engagement rate, reactivation rate) не смешиваются с метриками удержания, что даёт прозрачную картину эффективности каждого направления.

• Prevention и reactivation имеют разные цели: первая удерживает активных пользователей, вторая возвращает тех, кто уже перестал взаимодействовать. Смешивание приводит к нерелевантным сообщениям и снижает эффективность обеих кампаний.

• Порог неактивности должен определяться на основе данных продукта, а не интуиции. Для большинства B2B SaaS с месячным trial оптимальный порог, 7, 10 дней без входа, но он может варьироваться в зависимости от частоты использования продукта.

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

• In-app-каналы (баннеры, центр ресурсов) эффективнее email для первого касания реактивации, так как пользователь уже знаком с интерфейсом. Email лучше использовать как второй шаг, если in-app не сработал, или для пользователей, которые отключили уведомления.

• A/B-тестирование сообщений обязательно: тема, текст, призыв к действию и время отправки влияют на конверсию. Без тестов кампания не оптимизируется, и результаты остаются на уровне 5, 10% возврата.

• userStream позволяет запускать реактивацию без кода за 1 день, в то время как конкуренты требуют привлечения разработчиков, что увеличивает срок до 1, 2 недель. Это особенно важно для команд с ограниченными ресурсами.

• Использование единого шаблона сообщения для всех неактивных пользователей без учёта их предыдущего поведения. Это игнорирует разные причины ухода и снижает релевантность.

• Установка порога неактивности без анализа исторических данных. Слишком ранний порог (1, 2 дня) приводит к беспокойству активных пользователей, слишком поздний (14+ дней), к потере интереса.

• Отправка сообщений только по email, игнорируя in-app-каналы. Пользователи, которые ещё изредка заходят, могут не увидеть email, но отреагируют на баннер в приложении.

• Неучёт временных зон и рабочего времени. Отправка сообщения в 3 часа ночи по местному времени пользователя снижает открываемость и может вызвать раздражение.

• Отсутствие повторной реактивации. Если пользователь вернулся, но снова ушёл, кампания должна продолжиться, а не считаться завершённой.

• Игнорирование метрик реактивации: команда не отслеживает re-engagement rate, time-to-reactivation и конверсию в платящих, поэтому не может оценить эффективность и оптимизировать сценарии.

Шаг 1: Настройка сегмента «холодных» trial-пользователей в userStream

Чтобы отделить пользователей, которые действительно потеряли интерес, от тех, кто ещё изучает продукт, нужно задать жёсткое условие по времени бездействия. В userStream сегмент строится на комбинации атрибута lastActivityAt и порогового значения (например, 7 дней без активности). Это автоматически выделяет тех, кто не выполнил ни одного целевого действия за указанный период.

• Создайте сегмент с условием: атрибут lastActivityAt больше N дней назад. Для trial-продуктов B2B SaaS типичное значение, 5, 7 дней, но вы можете скорректировать его по своей когортной аналитике.

• Передавайте атрибуты trialEndsAt и дату последнего входа через метод identify(), без них сегмент не сможет отличить «холодного» trial-пользователя от того, кто просто зашёл вчера.

• Добавьте фильтр по стадии онбординга: регистрация пройдена, но Aha Moment (например, первый запуск отчёта или создание проекта) не достигнут. Это отсекает тех, кто уже получил ценность, но временно не активен.

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

• Перед запуском кампании протестируйте сегмент во встроенном предпросмотре: выберите одного-двух пользователей из сегмента и проверьте, что их данные (lastActivityAt, trialEndsAt) отображаются корректно.

Шаг 2: Триггерные сценарии, когда и как показывать сообщение

Триггерные сценарии определяют точный момент и условие показа реактивационного сообщения: без них кампания либо не сработает вовремя, либо превратится в спам. Для неактивных trial-пользователей используют три типа триггеров, загрузка страницы с задержкой, пользовательское событие при возврате и поведенческую цепочку после клика по баннеру.

• Триггер «Загрузка страницы» с задержкой 10, 15 секунд, первое реактивационное касание для пользователя, который открыл приложение после долгого отсутствия. Сообщение появляется только после того, как пользователь успел осмотреться, и не перекрывает критический интерфейс.

• Триггер «Пользовательское событие», например, залогинился или нажал кнопку «Создать проект». Если пользователь сам вернулся в trial, показывать общий баннер уже поздно; лучше сразу предложить конкретный следующий шаг, который он не завершил.

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

• Настройка частоты показа: не чаще 1 раза в 3 дня для одного и того же пользователя. Если проигнорировал первое сообщение, повторное показывают только через 72 часа, иначе риск получить жалобу на навязчивость.

• Пример кастомного триггера: userStream.trigger('trial_user_returned'), отправляется, когда пользователь с lastActivityAt > 7 дней заходит в приложение. Такой подход позволяет точно привязать кампанию к моменту возврата, не полагаясь на общие правила.

Шаг 3: Баннеры и центр ресурсов как главные форматы реактивации

Для реактивации неактивных trial-пользователей баннеры и центр ресурсов, два наиболее эффективных формата in-app-коммуникаций, каждый из которых решает свою задачу. Баннер с конкретным призывом действует как прямой триггер: он появляется в интерфейсе в момент входа и напоминает о незавершённых действиях. Центр ресурсов, наоборот, работает как постоянная точка входа, где пользователь сам может найти ответы на вопросы и пошаговые инструкции. Вместе они покрывают оба сценария, реактивное напоминание и самостоятельное изучение продукта.

Оба формата не требуют написания кода и настраиваются через визуальный редактор. Это позволяет product-командам запустить кампанию реактивации за один день, а не ждать спринта разработки. Главное, не смешивать форматы в одном визите и чётко разделять цели: баннер для срочного возврата к ключевому действию, центр ресурсов, для долгосрочного вовлечения.

• Баннер «Вернитесь и завершите настройку» с конкретным CTA (ссылкой на чеклист). Текст должен называть действие, которое пользователь не закончил, например: «Осталось добавить первый проект, вернитесь к настройке». CTA ведёт прямо на страницу чеклиста, а не на главную. Такой баннер повышает шанс завершения trial-воронки на 20, 30% по данным A/B-тестов в B2B SaaS.

• Центр ресурсов, «панель спасения»: соберите там видео-гайд, чеклист, FAQ одной кнопкой. В userStream центр ресурсов открывается как боковая панель без перезагрузки страницы. Разместите в нём три элемента: короткое видео (до 2 минут), чеклист из 5 шагов и ответы на 3 самых частых вопроса. Пользователь, который зашёл в центр ресурсов, возвращается к продукту в 2 раза чаще, чем тот, кто его не открывал.

• А/Б тест: баннер vs подсказка vs центр ресурсов, что лучше возвращает в вашем продукте. Запустите три сегмента с одинаковой аудиторией неактивных trial-пользователей. Измеряйте процент тех, кто выполнил ключевое действие (например, создал первый объект) в течение 7 дней. В большинстве B2B-продуктов центр ресурсов даёт более высокий retention, а баннер, более быстрый конверсионный всплеск. Подсказка (tooltip) обычно проигрывает обоим форматам из-за низкой заметности.

• Как избежать перегруза: один формат за визит, не более двух сообщений за кампанию. Если показать баннер и сразу после этого открыть центр ресурсов, пользователь воспримет это как спам. Лучшее правило: за один визит, только один in-app-формат. Вся кампания реактивации должна состоять максимум из двух касаний: первое, баннер или центр ресурсов, второе (через 3, 5 дней), напоминание в другом формате. Иначе пользователь скроет уведомления или отпишется.

• Почему центр ресурсов в userStream не требует интеграции с CRM, в отличие от Appcues. Appcues использует внешний CDP для персонализации контента в центре ресурсов, что добавляет точку отказа и лишние расходы. userStream хранит сегменты и поведенческие данные внутри платформы, центр ресурсов автоматически показывает материалы, соответствующие статусу пользователя (например, «не завершил онбординг» или «не использовал функцию X»). Это сокращает время настройки с двух недель до одного дня.

Шаг 4: Подсказки и туры для возврата к Aha Moment

Подсказки и туры в приложении, это самый быстрый способ вернуть неактивного пользователя к его первому успешному опыту (Aha Moment), не заставляя его вспоминать интерфейс с нуля. Вместо общей инструкции они показывают конкретно то, ради чего пользователь когда-то зарегистрировался, и убирают когнитивную нагрузку. Для B2B SaaS, где ценность часто раскрывается только после нескольких действий, такой подход сокращает время до повторного осознания ценности с нескольких дней до нескольких минут.

• Подсказка на странице логина: «Продолжите с того места, где остановились». После входа пользователь видит всплывающий баннер с кратким резюме последнего сеанса, например, «Вы создали отчёт по клиентам, осталось загрузить данные». Это снижает барьер входа и напоминает контекст, особенно если прошло больше недели.

• Тур-реактиватор за 30 секунд: трёхшаговый тур, который показывает самую ценную функцию, а не все подряд. Первый шаг, выделить ключевой элемент (например, кнопку «Запустить анализ»), второй, короткое описание выгоды, третий, призыв к действию. Такой тур не перегружает и даёт быструю победу.

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

• Настройка «показать один раз» с очисткой истории просмотра: чтобы тур или подсказка не показывались при каждом входе, используйте флаг dismissed. При повторной реактивации (например, через 30 дней б��здействия) этот флаг сбрасывается, и пользователь видит тур снова, как свежее напоминание, а не надоедливый повтор.

• Чеклист с прогресс-баром: покажите пользователю, сколько шагов из его прерванного пути он уже выполнил (например, 3 из 5), а оставшиеся выделите ярким цветом. Прогресс-бар создаёт эффект незавершённого действия (эффект Зейгарник) и мотивирует дойти до конца, особенно если последний шаг ведёт к Aha Moment.

Шаг 5: Измерение и итерация, метрики реактивации

Для измерения реактивации отслеживайте воронку от показа in-app сообщения до конверсии в paid. Основные этапы: показ кампании, клик, следующий визит в продукт, активация (достижение ключевого действия) и конверсия в платящего пользователя. На каждом шаге фиксируйте процент отсева, чтобы понять, где теряете возвращённых trial-пользователей.

В userStream визуализируйте эти пути с помощью Sankey-диаграммы: она покажет, откуда приходят возвращённые пользователи (например, из центра ресурсов, из баннера на панели навигации или из push-уведомления). Это поможет определить, какие каналы реактивации работают лучше, и перераспределить усилия.

• Воронка реактивации: показ → клик → следующий визит → активация → конверсия в paid. Сравнивайте конверсию в paid между реактивированными пользователями и «тёплыми» trial, которые не уходили. Это покажет, стоит ли вообще заниматься реактивацией или лучше сосредоточиться на онбординге новых.

• Пути пользователей (Sankey) в userStream: визуализация, откуда приходят возвращённые. Настройте фильтр по сегменту реактивированных и смотрите, какие страницы и элементы интерфейса они посещают после возврата.

• Сравнение конверсии в paid между реактивированными и «тёплыми» trial. Если конверсия реактивированных ниже на 30% и более, возможно, сегмент нежизнеспособен. В таком случае попробуйте изменить триггеры или оффер (например, продлить trial на 7 дней).

• Как настроить событие reactivation_completed через trigger() и смотреть в аналитике. В userStream добавьте поведенческий триггер, который отправляет событие, когда пользователь выполнил ключевое действие после возврата. Затем в дашборде постройте отчёт по этому событию в разрезе кампаний.

• Что делать, если реактивация не сработала: следующие шаги (email + in-app, скидка). Если in-app кампания не дала результатов, подключите email-канал с тем же предложением, а затем предложите персональную скидку. Замеряйте прирост по каждой итерации и отключайте неэффективные каналы.