Опросы при уходе с trial: как спросить «почему уходите?» и спасти конверсию

Exit-опрос при уходе с trial, это не просто вежливый вопрос «почему вы уходите?», а инструмент, который позволяет product-командам в реальном времени выявлять причины оттока и автоматически запускать retention-сценарии, спасая конверсию. Когда пользователь покидает пробный период, у вас есть буквально несколько минут, чтобы понять его мотивацию и предложить альтернативу. Без такого опроса вы теряете не только данные, но и возможность вернуть до 30% уходящих пользователей, тех, кто ушёл из-за мелких препятствий, а не из-за отсутствия ценности продукта. В этой статье вы узнаете, как настроить exit-опрос без кода, какие вопросы задавать и как на основе ответов строить персонализированные цепочки удержания.

Проблема в том, что большинство B2B SaaS-команд либо вообще не спрашивают причину ухода, либо делают это слишком поздно, через неделю после отписки, когда пользователь уже забыл детали. В результате retention-акции бьют вслепую: скидка на следующий месяц не поможет, если причина, сложный онбординг, а письмо с гайдом не сработает, если пользователю не хватило конкретной функции. В июле 2026 года, когда конкуренция за внимание trial-пользователей только растёт, умение задать правильный вопрос в нужный момент становится конкурентным преимуществом. Именно для российских команд, которые работают с рублёвыми платежами и русскоязычной аудиторией, критически важно иметь инструмент, который не требует долларовой подписки и сложной кастомизации.

В этом гайде мы разберём пошаговый процесс: от выбора триггеров показа опроса до автоматических retention-сценариев, которые запускаются сразу после ответа. Вы узнаете, как с помощью in-app опросов с условной логикой (например, в userStream) за час настроить систему спасения конверсии без привлечения разработчиков. Материал основан на реальных практиках российских B2B SaaS-продуктов и содержит конкретные метрики, шаблоны вопросов и примеры автоматизации. После прочтения вы сможете внедрить exit-опрос за один спринт и начать возвращать уходящих пользователей уже на следующей неделе.

Почему exit-опрос на trial, это не просто «сбор фидбека», а инструмент спасения конверсии

В традиционном понимании exit-опрос, это вежливое «почему вы уходите?», которое собирает данные для отчёта. Но в контексте trial-периода B2B SaaS этот опрос становится критическим рычагом управления конверсией. Когда пользователь кликает «отменить подписку» или удаляет аккаунт, он находится в пике разочарования, и именно в этот момент персонализированное вмешательство может переломить его решение. Exit-опрос не просто фиксирует причину, он даёт вам карту действий: зная, что именно спровоцировало уход, вы можете тут же предложить альтернативу, скидку, помощь онбордера, доступ к недостающей функции. Это превращает пассивный сбор фидбека в активный инструмент ретеншна.

Разница между обычным NPS и exit-опросом, во времени и контексте. NPS измеряет лояльность в спокойный момент, когда пользователь может дать общую оценку, но не указывает конкретный блокер, который привёл к уходу. Exit-опрос, напротив, замеряет боль в момент её возникновения. По данным ряда A/B-тестов в SaaS-продуктах, exit-опрос с retention-сценарием может увеличить trial-to-paid конверсию на 8, 12% относительно контрольной группы, где опрос не показывался. Этот эффект достигается за счёт того, что вы не просто собираете жалобы, а сразу предлагаете решение: для 40, 50% уходящих пользователей причиной является либо цена (и срабатывает скидка), либо недостаток знаний о продукте (и срабатывает помощь).

Важно понимать, что exit-опрос, это не единственное средство, а часть системы триггеров. Он работает в связке с in-app сообщениями, email-цепочками и сегментацией. Например, если пользователь указал «цена высока», система может показать ему промо-предложение прямо в опросе, а если «не хватает функции», перенаправить на страницу с роадмапом или предложить ранний доступ к разрабатываемой фиче. Без такого автоматического сценария опрос превращается в стресс для пользователя: его спросили, но не помогли, что только усиливает негатив. Поэтому инструмент спасения конверсии, это не сам опрос, а интеграция опроса с retention-цепочкой, где ответ становится триггером для конкретного действия.

• Exit-опрос фиксирует точную причину ухода в момент принятия решения, а не спустя неделю в email-рассылке, что позволяет реагировать до того, как пользователь окончательно ушёл.

• Ответы позволяют сегментировать уходящих пользователей и запускать разные retention-цепочки: для «дорого», скидка (конверсия возврата до 35%), для «сложно», персональный вебинар (конверсия до 20%), для «нет функции», роадмап или early access (конверсия до 15%).

• Метрики успеха: доля ответивших на опрос (цель, выше 20%, обычно 15, 30% в зависимости от дизайна), конверсия возвращённых пользователей в paid (цель, выше 10% от ответивших), снижение общего churn rate на trial-этапе (цель, минус 2, 5 процентных пунктов).

• Западные инструменты вроде Appcues и Userpilot требуют долларовой оплаты, не имеют готовых интеграций с российскими CRM (AmoCRM, RetailCRM) и заставляют писать кастомный код для простой логики «если ответ А, показать баннер Б», что удлиняет настройку до 2, 3 дней.

• Для российских команд userStream решает эти проблемы: рублёвый тариф, русскоязычный интерфейс, встроенные триггеры и сегменты без единой строки кода, exit-опрос настраивается за час, а retention-сценарий запускается автоматически по ответу, интегрируясь с AmoCRM через webhook.

Какие сигналы оттока ловить: 3 типа триггеров для показа exit-опроса

Чтобы опрос показался вовремя, отслеживайте три типа сигналов: пассивные (отсутствие активности), активные (действия по отмене или удалению платёжного метода) и поведенческие (застревание на этапе, не достижение Aha Moment). Каждый триггер настраивается в userStream без кода или через JavaScript API, что позволяет показывать опрос именно тем, кто действительно думает об уходе, а не случайно активным пользователям. По данным внутренних исследований B2B SaaS-продуктов, опрос, показанный в течение 24 часов после первого сигнала оттока, даёт на 40% больше заполняемости, чем опрос, показанный через неделю. При этом слишком ранний показ (например, на второй день trial) снижает конверсию в платящих на 12%, так как пользователь ещё не сформировал мнение о продукте. Поэтому выбор правильного момента, это баланс между скоростью реакции и зрелостью пользователя.

Ниже разберём, как конкретно настроить каждый тип триггера, добавим чек-лист, чтобы исключить показ опроса тем, кто активно пользуется продуктом, и рассмотрим типичные ошибки при настройке. Например, многие команды путают пассивный сигнал с «пользователь просто не активен в выходные», для этого стоит добавить условие «будний день» или проверять, что до этого была хотя бы одна сессия. Также важно помнить, что активный сигнал (нажатие «Отменить trial») может быть случайным, стоит добавить задержку в 5 секунд перед показом опроса, чтобы пользователь мог передумать. Поведенческий сигнал требует более тонкой настройки: если Aha Moment не определён чётко, опрос будет показываться всем подряд. Рекомендуется сначала провести когортный анализ и найти этап, после которого retention на 7-й день превышает 60%.

Для каждого типа триггера существуют свои метрики успеха: для пассивного сигнала, % пользователей, которые вернулись после опроса и совершили целевое действие; для активного, % отменённых отмен (пользователь отменил отписку после опроса); для поведенческого, % пользователей, которые после опроса всё же достигли Aha Moment. В userStream эти метрики можно отслеживать через воронки: создайте событие «Exit-опрос показан» и далее смотрите, какие действия совершает пользователь в течение следующих 7 дней. Типичная ошибка, не сегментировать аудиторию по типу триггера: если показывать один и тот же опрос и пассивным, и активным пользователям, вы получите смешанные данные, которые сложно интерпретировать. Лучше создать отдельные опросы для каждого типа сигнала с разными вопросами: для пассивных, «Что помешало вернуться?», для активных, «Почему решили отменить?», для застрявших, «Что было непонятно на этом этапе?».

• Пассивный сигнал: пользователь не заходил в продукт 5 и более дней. Настройте в userStream триггер на отсутствие события «Любое действие» за 5 дней, затем покажите опрос при следующем входе пользователя. Важно: исключите пользователей, которые уже получили опрос за последние 30 дней, чтобы не раздражать их повторными вопросами. Дополнительно можно добавить условие «количество предыдущих сессий > 3», чтобы опрос показывался только тем, кто уже успел познакомиться с продуктом, а не тем, кто зарегистрировался и сразу ушёл.

• Активный сигнал: пользователь нажал «Отменить trial» или удалил платёжный метод. Используйте кастомное событие из JavaScript API userStream, например userStream.track('cancel_trial'), и назначьте опрос как реакцию на это событие. Чтобы избежать ложных срабатываний при случайных кликах, добавьте задержку в 3-5 секунд после события, за это время пользователь может закрыть модалку отмены. Также полезно показывать опрос не сразу, а после подтверждения отмены (например, после второго клика), чтобы отсеять тех, кто передумал на первом шаге.

• Поведенческий сигнал: пользователь застрял на одном шаге, не достигнув Aha Moment. Создайте сегмент «Застрявшие на этапе X» по условию: количество событий перехода на этап X более 5 и событие «Aha Moment» равно 0. Покажите опрос при загрузке страницы этого этапа. Для точности определите Aha Moment через анализ данных: найдите действие, после которого 70% пользователей остаются на 14-й день. Например, для CRM-системы это может быть «первый импорт контактов», для аналитического инструмента, «создание первого отчёта». Если Aha Moment не достигнут после 5 попыток, вероятность оттока возрастает до 80%.

• Настройка триггера в userStream: выберите тип «По событию» или «По отсутствию события», укажите нужный сегмент пользователей и прикрепите exit-опрос. Для кастомных событий добавьте одну строку кода в нужное место вашего приложения. Например, для отслеживания клика по кнопке «Отменить» вставьте userStream.track('cancel_click') в обработчик этой кнопки. После этого в userStream создайте триггер с условием «Событие cancel_click произошло 1 раз за последние 24 часа» и привяжите опрос. Не забудьте также настроить исключение для пользователей, которые уже находятся в активной фазе (например, совершили более 10 действий за день), чтобы не показывать опрос тем, кто явно не собирается уходить.

• Чек-лист: убедитесь, что опрос не показывается активным пользователям. Добавьте сегмент «Не подходит» по условию «частота события «Любое действие» больше 3 за день» и исключите его из аудитории опроса. Также проверьте, что опрос не показывается чаще одного раза в 7 дней для одного пользователя, это можно настроить через «лимит показов» в userStream. Ещё один важный момент: если вы используете несколько триггеров, убедитесь, что они не конфликтуют, например, пассивный и поведенческий сигналы могут сработать одновременно. В таком случае приоритет отдайте активному сигналу, так как он указывает на более высокий риск оттока.

• Типичные ошибки при настройке триггеров: первая, показывать опрос всем подряд без сегментации по стадии trial. Например, пользователь на 2-й день trial ещё не сформировал мнение, и опрос будет бесполезен. Вторая, не учитывать часовые пояса: если вы показываете опрос в 3 часа ночи по местному времени, пользователь может проигнорировать его. Используйте userStream для настройки временных окон показа (например, с 9:00 до 21:00 по часовому поясу пользователя). Третья, слишком длинный опрос: если в нём больше 3 вопросов, заполняемость падает на 50%. Для exit-опроса достаточно 1-2 вопросов: «Почему уходите?» (с вариантами) и «Что мы могли бы сделать лучше?» (открытый).

Структура exit-опроса: какие вопросы задавать, чтобы получить actionable ответ

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

В userStream логика таких опросов настраивается без кода: вы создаёте опрос в редакторе, добавляете условия перехода по ответам и задаёте финальный экран благодарности. Например, если пользователь выбирает «Цена», система автоматически покажет шкалу комфортной суммы, а если «Сложность», текстовое поле. Это позволяет собирать структурированные данные, которые сразу готовы к запуску retention-сценариев.

• Правило 1, 3 вопросов: не более трёх, иначе пользователь закроет опрос до завершения. Идеальный вариант, два обязательных и один опциональный.

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

• Второй вопрос, conditional: если выбрал «Цена», спроси «Какая сумма была бы комфортной?» (шкала или диапазон); если «Сложность», «Что именно было непонятно?» (текстовое поле). Так вы получаете количественные и качественные данные для улучшения продукта.

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

Как на основе ответа запустить retention-сценарий: автоматические in-app цепочки

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

В userStream сегментация по ответу строится за пару кликов: каждый вариант вопроса становится триггером для отдельного сегмента (например, «Ответил_Цена» или «Ответил_Сложность»). Дальше вы выбираете тип сценария, баннер, тур, чеклист или письмо, и система сразу начинает показывать его пользователям из этого сегмента. Все сценарии работают на русском интерфейсе, без кода и без привязки к доллару.

• Сегментация по ответу: каждый вариант ответа в опросе автоматически создаёт отдельный сегмент пользователей. Например, если пользователь выбрал «Слишком дорого», он попадает в сегмент «Ответил_Цена», а если «Сложный интерфейс», в «Ответил_Сложность». Это позволяет адресовать retention именно под конкретную причину.

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

• Сценарий 2 (сложность): запускается персонализированный тур по ключевой функции, которая чаще всего вызывает вопросы. Дополнительно пользователю предлагается записаться на 15-минутное демо с менеджером, кнопка ведёт прямо в календарь.

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

• Сценарий 4 (нет времени): запускается email-серия из трёх писем с «5-минутными» видео-гайдами и in-app подсказками по быстрым победам. Первое письмо уходит через час после ответа, второе, через день, третье, через три дня.

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

Кейс: как exit-опрос + персонализированная скидка спасли 12% trial-пользователей

Exit-опрос в сочетании с персонализированной скидкой вернул 12% уходящих trial-пользователей за счет точного выявления причины оттока и немедленного предложения релевантного решения. Типичный B2B SaaS-продукт (аналитика для маркетплейсов) столкнулся с оттоком 68% на 10-й день 14-дневного trial. Внедрение опроса именно на этот день для пользователей, не выполнивших ключевое действие (загрузка данных), позволило перехватить момент ухода и запустить персонализированный retention.

Результаты оказались показательными: 22% пользователей ответили на опрос, из них 35% выбрали причину «Сложно разобраться» и получили приглашение на индивидуальный тур с демо, а 18% указали «Дорого» и мгновенно получили скидку 20%. За два месяца конверсия trial-to-paid выросла на 12%, именно за счет тех, кто без опроса просто ушел бы безвозвратно.

• Пример B2B SaaS-продукта (аналитика для маркетплейсов): 14-дневный trial, отток 68% на 10-й день, типичная ситуация, когда пользователи не доходят до ключевого действия.

• Внедрение exit-опроса: показ на 10-й день для пользователей, не выполнивших ключевое действие (загрузка данных). Вопросы появлялись только в момент ухода, не отвлекая активных юзеров.

• Результат: 22% ответили на опрос, из них 35% выбрали «Сложно разобраться» → получили тур + демо; 18% выбрали «Дорого» → получили скидку 20%. Остальные причины (не подходит функционал, нет времени) обрабатывались другими сценариями.

• Общий эффект: конверсия trial-to-paid выросла на 12% за 2 месяца. Спасли именно тех, кто без опроса ушел бы без шанса на возврат.

• userStream vs альтернативы: в Appcues аналогичная связка стоила бы $900/мес + разработка кастомной логики; в userStream, всё no-code в рублях с русским интерфейсом, настройка заняла 2 часа.

Как измерять эффективность exit-опросов: метрики и аналитика в userStream

Эффективность exit-опросов измеряется через три ключевые метрики: доля пользователей, ответивших на опрос, конверсия в оплату среди тех, кто прошёл retention-сценарий, и общий прирост trial-to-paid конверсии по сравнению с периодом без опросов. В userStream эти метрики доступны в дашборде без дополнительной настройки, система автоматически связывает ответы пользователя с его последующими действиями.

Для более детального анализа вы можете настроить кастомные события через JavaScript API: событие exit_survey_answered фиксирует факт и содержание ответа, а retention_action_taken, момент, когда пользователь кликнул по персонализированному баннеру или выполнил целевое действие. Эти события затем отображаются в Sankey-диаграмме, где видно, сколько людей после ответа перешли к retention-сценарию и дошли до оплаты.

• % ответивших на опрос, показывает, насколько релевантно сформулирован вопрос и не перегружен ли интерфейс; нормой для B2B SaaS считается 15, 25%.

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

• Общий lift trial-to-paid, сравниваете конверсию за месяц с exit-опросом и за предыдущий месяц без него; если прирост менее 5%, опрос не даёт бизнес-эффекта.

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

• A/B-тест без кода: создайте два сегмента пользователей, с exit-опросом и без него. Через месяц сравните конверсию в оплату. userStream позволяет запустить такой тест за 10 минут через сегментацию по признаку «участвовал в опросе».

• Sankey-диаграмма в userStream покажет пути пользователей: после ответа «дорого» retention-сценарий со скидкой может вести к оплате, а после «не подошёл функционал», к демо с менеджером. Визуально видно, какие сценарии работают.

Регулярный мониторинг этих метрик позволяет не просто собирать обратную связь, а превращать exit-опросы в измеримый инструмент роста конверсии. Если через месяц после внедрения опроса trial-to-paid вырос на 8, 12%, значит, вы правильно выбрали вопросы и retention-сценарии. Если нет, пересмотрите формулировки или механики удержания.