Сбор ответов · 26 августа 2026 г.

Опрос внутри мобильного приложения: как встроить, чтобы не раздражать

Опрос внутри мобильного приложения — короткая анкета, которая появляется прямо во время использования приложения: всплывающее окно, нижняя панель или отдельный экран после определённого действия. Это не то же самое, что системный запрос оценить приложение в сторе — тот собирает звёзды для магазина приложений, а внутренний опрос собирает содержательный ответ для команды продукта. Сила канала — точный момент показа сразу после релевантного события, слабость — ограниченное место на маленьком экране и риск раздражить активного пользователя лишним окном. Ниже разберём, чем встроенный опрос отличается от системного рейтинга, когда его показывать, как ограничить частоту и что реально можно сделать без отдельной интеграции SDK.

Чем встроенный опрос отличается от рейтинга в сторе

Системный запрос оценить приложение — стандартное окно операционной системы с просьбой поставить звёзды в App Store или Google Play. Оно управляется правилами платформы: показывается ограниченное число раз в год, и разработчик не может настроить в нём произвольный текст или вопросы — только момент вызова окна. Встроенный опрос устроен иначе: это собственный экран или всплывающее окно внутри приложения, где вопросы, шкалы и логику полностью определяет команда продукта, и показывать его можно так часто и так гибко, как позволяют собственные правила частоты.

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

Форматы: модальное окно, нижняя панель, отдельный экран

Модальное окно перекрывает весь экран и требует явного действия — ответить или закрыть — прежде чем продолжить пользоваться приложением. Это даёт высокую видимость и, соответственно, высокий отклик, но и раздражает сильнее других форматов, если появляется не вовремя или слишком часто. Нижняя панель, выезжающая снизу экрана и не блокирующая остальной интерфейс, мягче: пользователь может продолжить работу, не закрывая её явно, и отклик ниже, зато раздражение тоже меньше. Отдельный экран, доступный по ссылке из меню или уведомления, самый ненавязчивый вариант, но и самый низкий по отклику — пользователь должен сам решить туда перейти.

Выбор формата зависит от того, насколько критичен вопрос и насколько велик риск раздражения. Для короткого пульса из одного вопроса после завершённого действия подходит нижняя панель — она заметна, но не прерывает поток работы. Для более важного и редкого опроса, где нужна повышенная видимость, оправдано модальное окно, но использовать его стоит редко и точечно. Отдельный экран лучше всего подходит для добровольных, не привязанных к конкретному событию опросов — например, постоянной ссылки «оставить отзыв» в разделе настроек.

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

Когда показывать опрос

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

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

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

Как не раздражать активного пользователя

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

Ещё один практический приём — выборочный показ вместо показа всем подряд, кто подходит под триггер. Если событие происходит массово и часто, показывайте опрос не каждому сотому пользователю, а случайной доле, например каждому пятому или десятому, — этого обычно достаточно для устойчивой картины и заметно снижает совокупную нагрузку на аудиторию. Такой подход особенно важен для крупных приложений с миллионами активных пользователей, где даже редкий по замыслу опрос при показе всем подряд превращается в постоянный фоновый раздражитель для части базы.

Что можно без SDK: веб-опрос внутри приложения

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

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

Передача контекста через параметры ссылки — отдельная деталь, о которой стоит договориться заранее с разработчиками. Чтобы форма знала, какое именно событие вызвало показ и какому пользователю она открыта, приложение должно передать это в адресе ссылки: идентификатор пользователя, тип события, версию приложения. Без этого ответы приходят обезличенными и их нельзя сопоставить с остальными данными о пользователе внутри продукта, что резко снижает ценность собранной обратной связи для дальнейшего анализа.

Какие вопросы задавать

Место на экране телефона ограничено сильнее, чем на десктопе, поэтому встроенный опрос должен состоять из одного-двух вопросов, не больше. Первый вопрос — закрытый, с короткой шкалой из четырёх-пяти пунктов, чтобы ответ занимал одно касание. Второй, необязательный — открытый комментарий с ограничением по длине текста, который появляется только после ответа на первый и только для тех, кто готов написать больше. Разворачивать второй вопрос сразу для всех не стоит: это удлиняет форму и снижает завершаемость первого, самого важного вопроса.

• Спрашивайте о конкретном только что завершённом действии, а не о приложении в целом.
• Используйте шкалу из четырёх-пяти пунктов, а не десятибалльную — на маленьком экране она неудобна.
• Делайте кнопку закрытия такой же заметной, как кнопку ответа.
• Не показывайте открытый вопрос сразу — только после ответа на закрытый.
• Подписывайте крайние точки шкалы словами, а не только цифрами.

Ограничения

Встроенный опрос физически недоступен тем, кто использует продукт через браузер или другой канал, — выборка смещена в сторону активных пользователей мобильного приложения, и переносить выводы на всю клиентскую базу нельзя без оговорки. Второе ограничение — версия приложения: пользователи, не обновившие приложение до последней версии, не увидят опрос, добавленный в новом релизе, и на новых функциях доля устаревших версий бывает заметной, особенно в первые недели после выпуска. Учитывайте это при интерпретации ранних результатов: низкий охват в первую неделю после релиза чаще объясняется медленным обновлением приложения на устройствах пользователей, а не отсутствием интереса к самому опросу.

Третье ограничение касается самого формата ответа. Маленький экран и мобильный ввод плохо подходят для развёрнутых открытых вопросов — люди печатают на телефоне медленнее и неохотнее, чем на клавиатуре компьютера, и качество текстовых ответов внутри приложения обычно ниже, чем в форме, заполняемой с десктопа. Если нужен содержательный открытый ответ, разумнее использовать встроенный опрос как короткий фильтр, а развёрнутый вопрос вынести в отдельную ссылку на форму, которую можно открыть и на телефоне, и на компьютере.

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

Типичные ошибки

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

С чего начать

Начните с одного события с самым высоким риском ухода пользователя и одного закрытого вопроса — не пытайтесь сразу закрыть все сценарии продукта встроенными опросами. Сервис «До Сути» собирает ответы по ссылке на веб-форму, поэтому для встроенного опроса без отдельной разработки подойдёт именно вариант с открытием готовой формы внутри приложения через браузерный компонент — это не требует полноценного SDK и позволяет проверить формат до вложений в нативную интеграцию.

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

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