Как использовать дату окончания trial для автоматических in-app сообщений: сегменты и сценарии в userStream

Дата окончания trial, один из самых ценных атрибутов пользователя в B2B SaaS: она позволяет предсказывать момент, когда пользователь примет решение о покупке или уйдёт. Если правильно подключить этот атрибут к платформе коммуникаций, можно автоматически отправлять in-app сообщения ровно тогда, когда они нужны: напоминания за 3 дня, спецпредложение за день, благодарность после конверсии. userStream упрощает эту задачу, позволяя передать trialEndsAt через один вызов identify и сразу строить на его основе динамические сегменты и триггеры без дополнительного кода.

Без привязки к дате окончания trial большинство команд действуют вслепую: рассылают одинаковые напоминания всем пользователям на второй неделе или вовсе не напоминают. Это ведёт к потерям, до 40% пользователей покидают product tour, так и не осознав ценности. Сегментация по времени до окончания trial решает эту проблему: вы обращаетесь к пользователю в его индивидуальный момент принятия решения, а не по календарю регистрации. userStream даёт готовые условия «меньше/больше даты» и относительные даты прямо в интерфейсе, что особенно важно для русскоязычных команд, где разработчик не всегда доступен для обновления сегментов вручную.

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

Почему дата окончания trial, ключевой атрибут для онбординга

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

В userStream атрибут trialEndsAt передаётся единственным вызовом identify, после чего сразу становится доступен для построения временных сегментов и автоматических триггеров. Для российских B2B SaaS это означает, что менеджер по продукту может самостоятельно настроить цепочку сообщений на отрезке «осталось 7 дней, последний день» без привлечения разработчика для обновления условий каждый день.

• Пользователи на trial часто забывают о скором завершении тестового периода, автоматические напоминания повышают конверсию в платящих в среднем на 15, 30% в B2B SaaS.

• Атрибут trialEndsAt позволяет строить временные сегменты по принципу «3 дня до конца» и «последний день» без ручного отслеживания календарей или экспорта данных.

• В userStream атрибут передаётся через identify и сразу доступен для сегментов и триггеров, не требуются webhook, скрипты или промежуточные интеграции.

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

• Для компаний с ежемесячными планами атрибут trialEndsAt помогает точнее таргетировать предложения скидки, например, показать промокод только тем, кто провёл в продукте менее 3 часов за весь trial.

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

Как передать атрибут trialEndsAt в userStream: техническая инструкция

Для передачи даты окончания триала в userStream достаточно вызвать метод identify с объектом, содержащим ключ trialEndsAt в формате ISO 8601. Например, строка '2026-07-01' или полная дата с временем. После вызова атрибут автоматически появляется в интерфейсе сегментов и триггеров, никаких дополнительных действий со стороны разработчика не требуется. Если пользователь продлил триал, просто вызовите identify повторно с новым значением. Рекомендуется передавать trialEndsAt при каждой идентификации пользователя, чтобы сегменты всегда оставались актуальными.

Пример кода на JavaScript: userStream.identify('user_id', { plan: 'trial', trialEndsAt: '2026-07-01', role: 'admin' }). Атрибут может быть передан как строка, так и число (timestamp). userStream автоматически распознаёт формат и позволяет строить условия «меньше даты», «больше даты» и относительные диапазоны (например, «осталось меньше 3 дней»). Это избавляет от необходимости писать кастомные скрипты или webhook для обновления сегментов.

• Используйте метод userStream.identify с объектом, содержащим trialEndsAt в формате ISO 8601, например '2026-07-01'.

• Пример кода: userStream.identify('user_id', { plan: 'trial', trialEndsAt: '2026-07-01', role: 'admin' }).

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

• Если дата окончания меняется (пользователь продлил trial), достаточно повторно вызвать identify с новым значением.

• Рекомендуется передавать trialEndsAt при каждой идентификации, чтобы сегменты всегда были актуальны.

Создание сегментов по времени до окончания trial

Создание сегментов по времени до окончания trial начинается с выбора условия на атрибут trialEndsAt: в разделе «Аудитория» вы указываете, что trialEndsAt меньше или больше определённой даты. Это базовый фильтр, который отсекает пользователей за рамками нужного периода. Например, для сценария «Напоминание за 3 дня» берётся условие «trialEndsAt меньше, чем текущая дата + 3 дня». В некоторых инструментах такое динамическое условие требует ежедневного обновления кода, но в userStream оно работает как готовый пресет относительных дат.

В userStream для создания динамических сегментов используются относительные условия без дат «от» и «до». Вместо жёсткой даты (например, 15 июля 2026) вы указываете «trialEndsAt меньше, чем текущая дата + 3 дня», сегмент автоматически обновляется каждый день. Это особенно важно для команд, которые не могут выделять разработчика на пересборку аудитории: все временные отрезки считаются относительно момента проверки.

• В разделе «Аудитория» выберите условие: атрибут trialEndsAt меньше или больше определённой даты. Так вы создаёте статичный сегмент, который можно использовать для разовой рассылки или теста гипотезы.

• Для динамических сегментов используйте относительные условия: «trialEndsAt меньше, чем текущая дата + 3 дня». Это гарантирует, что пользователь с триалом ровно на 7 дней попадёт в сегмент за 3 дня до окончания, а не выпадет из него из-за смещения дат.

• userStream поддерживает вычисляемые сегменты на основе дат, не нужно вручную обновлять условия каждый день. Атрибут trialEndsAt сравнивается с системной датой, и membership пользователей пересчитывается автоматически при каждой синхронизации.

• Примеры сегментов: «Trial заканчивается через 7 дней» (trialEndsAt между currentDate+7 и currentDate+10), «Trial закончился сегодня» (trialEndsAt = currentDate), «Trial закончился 3 дня назад» (trialEndsAt = currentDate-3). Эти сегменты покрывают основные точки касания: предупреждение, конверсия и возврат спустя несколько дней.

• Проверьте сегмент через предпросмотр: выберите тестового пользователя с известной датой окончания. Если в системе сохранён пользователь с trialEndsAt = 2026-07-14, а сегодня 2026-07-11, сегмент «заканчивается через 3 дня» должен его включить. В случае ошибки проверьте часовой пояс и формат атрибута (ISO 8601 или Unix timestamp).

5 сценариев in-app сообщений на основе trialEndsAt

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

• Напоминание за 7 дней: покажите баннер «Осталось 7 дней, завершите настройку, чтобы не потерять данные» с прямой ссылкой на чеклист онбординга. Это снижает риск, что пользователь забудет о триале и уйдет без попытки.

• Предложение продления за 3 дня: вставьте чеклист «Что вы успеете сделать за 3 дня» с прогресс-баром (например, «Вы завершили 4 из 8 ключевых шагов») и кнопкой «Перейти на тариф». Прогресс-бар создает ощущение незавершенности и мотивирует действовать.

• Последний день триала: запустите тур по функциям, которые пользователь еще не открыл. Акцент на ценности: «Вы не пробовали автоматические отчеты, они экономят 2 часа в неделю». Тур должен быть коротким (3, 4 шага) и заканчиваться предложением продлить доступ.

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

• Ретриггер через 7 дней после окончания: покажите баннер «Мы сохранили ваши данные, вернитесь и продолжите с того же места». Это работает, если пользователь ушел из-за срочных дел, а не из-за отсутствия ценности. Баннер должен вести на страницу восстановления с тем же окружением.

Настройка триггеров для автоматического показа сообщений

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

В userStream триггеры настраиваются без скриптов: достаточно выбрать событие «Вход на сайт» для сообщений-напоминаний, пользователь видит их сразу после логина. Для сообщений после окончания trial используйте триггер «Пользователь вошёл в сегмент», сообщение покажется один раз при попадании в сегмент, что исключает повторный показ. Важно добавить исключение по атрибуту plan != 'trial', чтобы не отправлять сообщения тем, кто уже продлил триал. В аналитике отслеживайте конверсию каждого сценария: сколько пользователей перешли по CTA и сколько в итоге продлили подписку.

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

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

• Для сообщений после окончания trial настройте триггер «Пользователь вошёл в сегмент», сообщение покажется один раз при попадании в сегмент, не повторяясь при каждом входе.

• Проверьте, чтобы сообщения не показывались тем, кто уже продлил trial, добавьте исключение по атрибуту plan != 'trial'. Это предотвращает показ рекламных сообщений платящим пользователям.

• В аналитике отслеживайте конверсию каждого сценария: сколько пользователей перешли по CTA и сколько продлили триал. Эти данные помогут оптимизировать текст и время показа.

Как измерить эффективность сценариев с trialEndsAt

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

Начните с построения пути пользователей (Sankey) для каждого сегмента, вы увидите, какая доля переходит к оплате после просмотра сообщения. Затем сравните конверсию в платящих между теми, кто видел напоминание, и контрольной группой (пользователи, которым сообщения не отправлялись). Если разница статистически значима, сценарий работает.

• Используйте Sankey-диаграммы в userStream, чтобы визуализировать, как сегментированные пользователи доходят до оплаты после показа сообщения, это покажет узкие места воронки.

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

• Отслеживайте метрику time-to-pay, если после получения сообщения пользователи оплачивают быстрее, сценарий ускоряет принятие решения.

• Анализируйте опросы после окончания trial: какие причины оттока самые частые, это поможет улучшить онбординг и скорректировать тексты сообщений.

• Регулярно обновляйте сегменты и тексты сообщений на основе данных, userStream позволяет менять контент без привлечения разработчиков, что ускоряет итерации.