Процесс запуска

Как просить разрешение на уведомления в приложении и не получить отказ

Практический сценарий запроса разрешения: момент пользы, предварительное объяснение, настройки и воронка аналитики.

Sergei Gorelov CTO, Appfyl Обновлено 2026-07-16

Пассажир включает полезное уведомление о задержке после сохранения поездки

Короткий ответ

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

Найдите момент доказанной пользы

Составьте список триггеров продукта. Для каждого ответьте: какую неопределённость снимает уведомление и может ли человек обойтись без него?

Продукт	Подходящий момент	Честное объяснение
Доставка	После оформления заказа	«Сообщим о сборке и приезде курьера»
Запись	После выбора времени	«Напомним о приёме и предупредим об изменении»
Обучение	После создания расписания	«Напомним о выбранных занятиях»
Транспорт	После сохранения маршрута	«Предупредим о задержке и изменении платформы»
Магазин	После добавления товара в избранное	«Сообщим о наличии выбранного размера»

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

Предварительное объяснение не должно имитировать систему

Покажите обычный экран приложения с одной пользой и двумя понятными действиями: продолжить запрос или оставить на потом. Не рисуйте поддельное системное окно и не прячьте отказ. На iOS после системного запрета нельзя просто повторить тот же запрос; вернуть доступ человек сможет через настройки устройства. Apple описывает системный процесс разрешения в документации.

На Android поведение зависит от версии системы и настроек устройства. Актуальный порядок нужно проверять по руководству Android для разрешения уведомлений. Команда должна тестировать чистую установку, обновление старой версии и сценарий повторного входа.

Постройте воронку, а не один счётчик

Минимальный набор событий:

пользователь дошёл до момента пользы;
увидел предварительное объяснение;
выбрал «включить» или «позже»;
получил системный запрос;
разрешение стало доступно приложению;
токен зарегистрирован на сервере;
тестовое или первое полезное сообщение доставлено;
человек открыл его и выполнил действие;
категория или весь канал были отключены.

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

Настройки важнее красивого запроса

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

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

Есть идея приложения и нужен трезвый следующий шаг?

Разобрать идею приложения

Что тестировать

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

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

Путь от полезного действия через объяснение и настройки до сообщения и аналитики

Как Appfyl проектирует запрос

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

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Связанные материалы Appfyl

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Превратите исследование в план запуска

Appfyl поможет превратить идею в понятный план приложения, список функций первой версии и план первых работ.

Обсудить план приложения

Главные выводы

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

Полезные ссылки

Частые вопросы

Нужно ли спрашивать разрешение при первом запуске?

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

Можно ли ещё раз показать системное окно после отказа?

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

Какой процент согласий считается хорошим?

Без контекста такой показатель бесполезен. Сравнивайте сегменты собственного продукта и смотрите, приводят ли сообщения к полезному действию без роста отключений.

Нужны ли отдельные настройки внутри приложения?

Да. Системное разрешение включает канал целиком, а внутренние настройки позволяют выбрать темы, частоту и время.