Как снизить отток на trial: кастомные события через JavaScript API для онбординга в SPA

Trial-пользователи SPA-приложений часто уходят до того, как успеют оценить ценность продукта, потому что стандартные туры и подсказки не адаптируются под их реальные действия. Встроенные триггеры большинства платформ онбординга работают только по URL или кликам на селекторы CSS, но в одностраничных приложениях с динамической маршрутизацией это ломается при каждом переходе. Вы не можете заставить онбординг стартовать именно после того, как пользователь загрузил CSV, создал первый проект или нажал кнопку в модалке, если нет соответствующего события. В этом гайде вы узнаете, как с помощью JavaScript API userStream создавать кастомные события и триггеры, которые точно отражают бизнес-логику вашего SPA, и настроить онбординг, который ведет к активации за первую сессию.

Мы разберем, почему шаблонные триггеры не справляются со сложными trial-сценариями, как правильно идентифицировать пользователей и передавать атрибуты для сегментации, и как спроектировать кастомные события под любой пользовательский путь. Особое внимание уделим SPA-роутингу: React, Vue и Angular не требуют дополнительных костылей, если API онбординга поддерживает history.pushState. Вы получите готовый пошаговый сценарий для trial-пользователя, от регистрации до первого ключевого действия, с полным кодом JavaScript. И наконец, узнаете, как отслеживать метрики активации и оттока на уровне кастомных событий, чтобы доказывать ROI онбординга.

Материал рассчитан на product-менеджеров и frontend-разработчиков, которые хотят ускорить time-to-value в trial и сократить churn. Все примеры даны на чистом JavaScript и работают в любом SPA-фреймворке. Мы не будем предлагать абстрактные советы, только конкретные шаги с кодом, которые вы можете взять и применить сегодня.

Почему встроенных триггеров недостаточно для сложных trial-сценариев

Встроенных триггеров недостаточно для сложных trial-сценариев, поскольку они ограничены поверхностными событиями, загрузкой страницы, кликом по элементу или изменением URL, и не способны отслеживать внутреннюю логику приложения, такую как асинхронные запросы, завершение процессов или состояние данных. Без возможности реагировать на бизнес-события онбординг в trial-сценариях срабатывает невпопад или пропускает ключевые моменты, когда подсказка была бы максимально полезной. Например, если пользователь создал проект, но ещё не загрузил первый файл, стандартный триггер по URL покажет тултип о следующем шаге, хотя пользователь всё ещё находится на этапе загрузки. Это приводит к разрыву контекста и снижает эффективность онбординга на 20, 30% по данным A/B-тестов в B2B SaaS-продуктах.

Для команд, которые работают со сложными бизнес-логиками, например, многошаговые регистрации, создание проектов с загрузкой файлов или настройка интеграций, таких триггеров недостаточно. Без кастомных событий через JavaScript API вы не сможете точно определить, на каком этапе пользователь застрял, и предпринять своевременное действие. Это особенно критично для SPA, где роутинг происходит на стороне клиента и стандартные проверки URL часто ломают последовательность онбординга. В результате пользователи получают подсказки, не соответствующие их текущему контексту, что увеличивает отток на trial в среднем на 15, 25%.

Типичная ошибка при использовании только встроенных триггеров, показ онбординга на основе URL, который не меняется при выполнении асинхронных действий. Например, в SPA-приложении на React после успешной регистрации URL остаётся тем же, а пользователь видит модальное окно с приветствием. Стандартный триггер по URL не отличит этот момент от простого обновления страницы, поэтому онбординг либо не покажется, либо покажется в неправильный момент. По данным userStream, команды, внедрившие кастомные события, сокращают время до первого key action (time-to-value) на 30, 40% и увеличивают активацию trial-пользователей на 25%.

• Стандартные триггеры работают только по URL, кликам и показам, они не отслеживают внутреннюю логику приложения, такую как ответ API или завершение асинхронной задачи. Это делает их бесполезными для сценариев, где ключевое действие происходит без изменения URL или видимого клика.

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

• Кастомные события через JavaScript API (identify, track, reset) позволяют передавать любые бизнес-действия: клик по кнопке «Отправить», успешный ответ сервера, завершение загрузки файла или выполнение цепочки шагов. Это даёт возможность привязать онбординг к реальному прогрессу пользователя, а не к поверхностным сигналам.

• В SPA на React, Vue или Angular стандартные триггеры часто срабатывают некорректно из-за client-side роутинга, это приводит к показу тултипов не в том контексте или к их полному отсутствию. userStream решает эту проблему из коробки благодаря встроенной поддержке SPA и возможности задавать триггеры на основе кастомных событий.

• Без кастомных событий вы теряете возможность персонализировать онбординг под конкретный сценарий trial: например, показывать разные подсказки пользователям, которые уже загрузили данные, и тем, кто только создал аккаунт. Это снижает релевантность онбординга на 30, 50% по сравнению с кастомными триггерами.

• Внедрение кастомных событий требует первоначальной настройки (определение ключевых событий, написание кода интеграции), но окупается за счёт сокращения оттока на trial: по опыту B2B SaaS-команд, переход на кастомные триггеры снижает churn на 10, 20% в первые 30 дней.

JavaScript API userStream: идентификация и передача атрибутов для сегментации

JavaScript API userStream, доступное через глобальный объект userStream или CDN, предоставляет метод userStream.identify(userId, traits), который является единственной точкой входа для привязки пользовательских данных к сессиям и событиям. Этот метод принимает строковый идентификатор userId (например, email или UUID из вашей базы данных) и объект traits, содержащий произвольные пар ключ-значение, от простых строк до вложенных структур. При первом вызове userStream создаёт профиль пользователя в облачной платформе, связывая с ним все последующие события (pageviews, clicks, custom events). При повторных вызовах с тем же userId атрибуты объединяются: новые поля добавляются, существующие перезаписываются, а удалённые, игнорируются. Это позволяет обновлять сегментацию в реальном времени без ручного вмешательства, например, при переходе пользователя на PRO-тариф по завершении trial.

После вызова identify сегменты, основанные на атрибутах, автоматически применяются к новым и существующим пользователям без перезагрузки страницы или дополнительного кода. В визуальном редакторе userStream вы создаёте правила сегментации, используя операторы сравнения: equals, not_equals, greater_than, less_than, contains, starts_with. Правило может комбинировать до 10 условий через логические И/ИЛИ, что позволяет строить сложные сегменты, например: (plan equals 'pro' AND role equals 'admin') OR (companySize greater_than 100 AND industry contains 'SaaS'). Каждый сегмент привязывается к конкретному онбординг-элементу, туру, чеклисту или подсказке. Когда пользователь загружает приложение, userStream проверяет, соответствует ли его профиль условиям сегмента, и, если условие истинно, запрашивает и отображает соответствующий контент. Это исключает загрузку нерелевантных подсказок и снижает задержки в интерфейсе, особенно в SPA с тысячами одновременных пользователей.

• Метод userStream.identify(userId, traits) принимает строковый идентификатор и объект traits с любыми кастомными атрибутами: тариф, роль, стадия активации, количество проектов. Вызов можно повторять при изменении данных, атрибуты обновятся без потери истории событий. Например, после обновления тарифа в личном кабинете достаточно вызвать identify с обновлённым traits.plan, и сегменты для PRO-пользователей активируются немедленно.

• Сегменты создаются на основе этих атрибутов с использованием операторов сравнения: equals, not_equals, greater_than, less_than, contains. Примеры: plan equals 'pro', companySize greater_than 50, daysActive less_than 7. Комбинации условий поддерживаются через логические И/ИЛИ, что позволяет строить сегменты с пересечением нескольких критериев. Например, сегмент для trial-администраторов: role equals 'admin' AND plan equals 'trial'.

• Автоматическая привязка сегмента к туру, чеклисту или подсказке: информация о контенте запрашивается только для подходящего сегмента. Это снижает нагрузку на клиентскую часть, так как неиспользуемые элементы не рендерятся, и гарантирует, что пользователь не увидит нерелевантные подсказки. В крупных SPA с десятками тысяч пользователей это уменьшает количество запросов к API на 40, 60%.

• Сегменты динамически обновляются при каждом вызове identify: если пользователь меняет роль или тариф, он мгновенно попадает в другой сегмент без перезагрузки страницы. Это особенно важно для trial-пользователей, которые проходят несколько стадий активации в рамках одной сессии. Например, после завершения первого проекта атрибут projectsCount обновляется с 0 на 1, и пользователь автоматически переходит из сегмента 'новички' в сегмент 'активные тестеры'.

• Пример: показываем чеклист «первый проект» только тем, у кого projectsCount equals 0 и role not_equals 'viewer'. Такой подход исключает показ онбординга для наблюдателей, которые не могут создавать проекты, и фокусируется на активных trial-пользователях. Это сокращает количество нецелевых показов на 30, 50% и повышает процент завершения чеклиста среди целевой аудитории.

• Практический кейс: сегментация trial-пользователей по стадии активации, регистрация, первый шаг, Aha Moment. Для каждой стадии назначается свой набор подсказок: на регистрации, приветственный тур, на первом шаге, подсказка по ключевой функции, на Aha Moment, чеклист завершения. Сегменты переключаются автоматически после вызова identify с обновлённой стадией. Например, после того как пользователь выполняет первое действие (firstStepCompleted: true), сегмент 'первый шаг' активируется и заменяет 'регистрация', без необходимости ручного обновления сегментации.

Кастомные события: как создать триггеры под любую бизнес-логику

Кастомные события создаются вызовом метода userStream.track(eventName, properties?), который записывает любое действие пользователя в SPA, от нажатия на кнопку до завершения асинхронной загрузки. Это позволяет вам выйти за рамки встроенных шаблонов и привязать онбординг к уникальным сценариям вашего продукта, будь то создание отчёта, импорт данных или первый запуск интеграции.

Каждое зафиксированное событие сразу попадает в аналитику и может быть использовано как условие для показа подсказок, тултипов или чеклистов. Например, вы отслеживаете, что пользователь открыл страницу настроек, но не сохранил изменения, через 30 секунд система показывает подсказку с вопросом «Нужна помощь?». Такие сценарии напрямую влияют на активацию и снижают риск оттока на trial.

• userStream.track(eventName, properties?), универсальный метод для записи любого действия: создание отчёта, нажатие на кнопку «Импорт», завершение загрузки файла.

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

• Пример: отслеживаем, что пользователь открыл страницу настроек, но не сохранил изменения, через 30 секунд показываем подсказку с вопросом «Нужна помощь?».

• Комбинация: событие + атрибут → триггер «показать чеклист, если user.plan equals trial И event.importCount equals 0», идеально для активации новых пользователей.

• userStream.reset() при logout, гарантирует, что события предыдущего аккаунта не повлияют на нового пользователя, что критично для SPA с общими сессиями.

SPA и маршрутизация: как онбординг работает в React, Vue и Angular без переподключения

В SPA онбординг работает без переподключения скрипта на каждом роуте благодаря автоматическому перехвату событий навигации: виджет userStream отслеживает history.pushState, replaceState и popstate, пересчитывая видимость подсказок и чеклистов при смене маршрута. Это значит, что вам не нужно вручную вызывать инициализацию после каждого перехода, достаточно одного подключения widget.js в корневом index.html. Такой подход критичен для SPA, где повторное подключение скрипта может сломать роутинг и привести к дублированию обработчиков.

При смене маршрута система обновляет URL-фильтры, перезагружает changelog-портал и корректирует отображение туров, всё это происходит без полной перезагрузки страницы. Например, в React после авторизации достаточно один раз вызвать userStream.identify(user.id, { plan: user.plan }) внутри useEffect, и онбординг будет корректно сопровождать пользователя по всем разделам приложения без лишних ререндеров.

• Виджет userStream перехватывает history.pushState, replaceState и popstate автоматически, не нужно подключать скрипт на каждом роуте.

• При смене маршрута пересчитываются URL-фильтры, обновляется видимость чеклистов и подсказок, перезагружается changelog-портал.

• Достаточно одного подключения widget.js в корневом index.html, это критично для SPA, где повторное подключение ломает роутинг.

• Пример на React: после авторизации вызываем userStream.identify(user.id, { plan: user.plan }) в useEffect, один раз, без лишних ререндеров.

• Сравнение с конкурентами: Appcues требует дополнительных настроек для SPA, Userpilot не всегда корректно обрабатывает popstate, userStream работает из коробки.

Пошаговый сценарий: автоматический онбординг trial-пользователя в SPA-продукте

Автоматический онбординг trial-пользователя в SPA-продукте строится на последовательности кастомных событий и сегментов, которые программируются через JavaScript API. Сценарий начинается с идентификации пользователя сразу после регистрации и заканчивается автоматическим отслеживанием ключевого действия, создания первого проекта. Такой подход позволяет адаптировать каждый шаг онбординга под реальное поведение пользователя, не полагаясь на фиксированные туры или ручные триггеры.

В SPA-приложениях, где страницы не перезагружаются, особенно важно, чтобы события и сегменты обновлялись динамически. Описанный ниже сценарий использует identify, track и сегментацию в реальном времени, что гарантирует показ правильных подсказок именно в тот момент, когда пользователь готов к следующему действию.

• После регистрации система вызывает identify с атрибутами plan: 'trial', role: 'admin', onboardingStage: 'registered'. Эти данные сохраняются в профиле пользователя и становятся основой для всех последующих сегментов.

• На основе атрибутов создаётся сегмент «Новый trial» с условием plan equals trial AND onboardingStage equals registered. В этот сегмент попадают только что зарегистрированные пользователи, которые ещё не проходили онбординг.

• К сегменту привязывается тур-знакомство, который показывается при первом входе в продукт. Условие показа, membership в сегменте «Новый trial», поэтому тур не повторяется при последующих визитах.

• После завершения тура через track('tour_completed') значение onboardingStage обновляется на 'toured'. Пользователь автоматически покидает сегмент «Новый trial» и переходит в следующую стадию онбординга.

• На основе события tour_completed создаётся триггерный чеклист «Создайте первый проект». Он запускается для тех, кто прошёл тур, но не создал проект в течение двух часов. Чеклист напоминает о следующем шаге и подсказывает, как его выполнить.

• Создание проекта отслеживается через track('project_created'). Как только событие появляется, чеклист автоматически отмечает задачу как выполненную, и пользователь переходит к полноценной работе с продуктом.

Аналитика кастомных событий: как измерить влияние на отток

Измерить влияние кастомных событий на отток можно через воронки конверсии, пути пользователей и прямое сравнение сегментов с разными онбординг-сценариями. Без кастомной аналитики вы видите только общий показатель оттока, но не понимаете, на каком бизнес-действии пользователь застревает. Кастомные события, переданные через JavaScript API, превращают онбординг в измеримый процесс: каждое нажатие, завершение тура или создание проекта становится точкой данных для анализа.

В разделе «Аналитика» userStream отображаются все переданные события: количество срабатываний, частота на пользователя и привязка к сегментам. Этого достаточно, чтобы построить воронку по ключевым шагам активации и увидеть, где пользователи массово отваливаются. Например, если 40% пользователей доходят до завершения тура, но только 10% создают проект, проблема именно в переходе между этими событиями, а не в регистрации.

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

• Пути пользователей (Sankey) с кастомными событиями визуализируют все возможные переходы между бизнес-действиями, от входа до покупки. Вы видите, какие маршруты ведут к конверсии, а какие, к оттоку.

• Сравнение конверсии в платящих: сегмент с кастомным онбордингом против сегмента без него. Разница может составлять 15, 25% в пользу группы, где онбординг адаптирован под реальные действия пользователя.

• Практический пример: после внедрения кастомного события «import_completed» конверсия trial → paid выросла на 18% за счёт своевременных подсказок на следующем шаге. Команда увидела, что пользователи, которые завершили импорт, в 2 раза чаще переходят к оплате.

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