iOS дает вам ровно один шанс запросить разрешение на push-уведомления с помощью нативного запроса. Если пользователь нажимает «Не разрешать», это решение скрывается в настройках приложения, куда почти никто не заходит, чтобы его изменить. Этот единственный факт должен определять всю вашу стратегию получения разрешений на push-уведомления в iOS — и именно поэтому приложения с лучшими показателями согласия почти никогда не показывают запрос Apple без предварительной подготовки.
В этом руководстве рассказывается о том, как на самом деле работает разрешение в iOS, о шаблоне предварительного уведомления, который защищает ваш единственный шанс, и о том, как реализовать весь процесс с помощью нескольких строк кода SDK.
Как на самом деле работает разрешение на push-уведомления в iOS
Каждое приложение находится в одном из трех состояний разрешения: пользователю еще не задавали вопрос, пользователь предоставил разрешение или пользователь отказал в нем. Нативный системный запрос — тот, который отображает Apple, с формулировкой, которую вы не можете изменить — навсегда выводит пользователя из первого состояния. Второго нативного запроса не существует. После отказа единственный путь назад лежит через приложение «Настройки», а показатели восстановления из «Настроек» настолько низки, что отказ следует рассматривать как окончательный.
Сравните это с Android, где разрешение на уведомления исторически по умолчанию было включено. Это основная причина, по которой уровень согласия в iOS составляет около 51%, а в Android — около 81%, как мы освещали в руководстве по маркетингу push-уведомлений в приложениях. В iOS согласие зарабатывается. Преимущество: подписчик, который сознательно сказал «да», ценнее, активнее взаимодействует и реже уходит, чем подписчик с включенным по умолчанию согласием. Ваша задача — подготовить почву до того, как будет задан вопрос.
Почему время важнее текста
Самая распространенная ошибка с разрешениями в iOS носит структурный, а не вербальный характер: показ нативного запроса при первом запуске, до того, как пользователь поймет, что делает приложение или почему уведомления могут ему помочь. В этот момент честный ответ на вопрос «следует ли мне позволить этому приложению прерывать меня?» — нет, у пользователя нет никаких доказательств в ту или иную сторону, а «нет» — это безопасный вариант по умолчанию.
Решение состоит в том, чтобы запрашивать разрешение в момент ценности — в точке сеанса, когда польза от уведомления конкретна и очевидна:
- Покупатель в интернет-магазине добавляет товар в список желаний → «Хотите знать, когда цена упадет?»
- Покупатель завершает покупку → «Хотите получать обновления о доставке этого заказа?»
- Читатель заканчивает вторую статью → «Хотите получать уведомления, когда мы публикуем материалы на эту тему?»
- Пользователь завершает онбординг и достигает первого успеха → «Хотите, чтобы мы сообщали вам, когда произойдет X?»
Тот же запрос, та же формулировка от Apple — но ответ кардинально отличается, потому что вопрос наконец получил контекст.
Шаблон предварительного уведомления: мягкий запрос перед настоящим запросом
Предварительное уведомление означает показ собственного экрана внутри приложения — диалогового окна перед запросом разрешения, которое вы полностью контролируете, — перед запуском запроса Apple. У этого шаблона есть одно правило, которое делает его эффективным: запускайте нативный запрос только после того, как пользователь согласится на ваш.
Если пользователь принимает ваш мягкий запрос, он уже принял решение; нативный запрос — это формальность, и конверсия в нем очень высока. Если он отклоняет ваш мягкий запрос, вы ничего не теряете — нативный запрос так и не был показан, однократный показ все еще активен, и вы можете повторно запустить мягкий запрос в более подходящий момент через несколько недель. Мягкий запрос можно повторять бесконечно; запрос Apple — нет.
Хороший мягкий запрос указывает на конкретную ценность («оповещения о снижении цен на сохраненные товары»), показывает, как будет выглядеть уведомление, и предлагает реальный вариант отказа, который не вызывает чувства вины. Те же принципы, что и для высококонверсионных запросов на подписку на веб-push, применимы и здесь — конкретика конвертирует, неопределенность — нет.
Реализация потока с помощью PushEngage SDK
SDK iOS SDK 1.0 предоставляет два вызова, необходимых для этого потока: один для проверки текущего состояния, другой для запуска нативного запроса в выбранный вами момент.
// 1. Check state before deciding what UI to show
let status = PushEngage.getNotificationPermissionStatus()
switch status {
case "notYetRequested":
showSoftAskScreen() // your own UI — the native prompt is untouched
case "denied":
showSettingsNudgeIfEarned() // deep link to Settings, only at a high-value moment
case "granted":
break // already subscribed — get out of the way
default:
break
}
// 2. Only after the user accepts YOUR screen:
PushEngage.requestNotificationPermission { granted, error in
if granted {
// subscribed — thank them with value, not a welcome blast
}
}Обратите внимание, что enforces код: нативный запрос срабатывает только из обработчика принятия вашего мягкого запроса и ниоткуда больше. Никаких неожиданностей при запуске, никаких потраченных показов.
Возвращение пользователей, которые сказали «нет»
Для пользователей в состоянии отказа нативный запрос недоступен, но игра еще не окончена. Способ восстановления — глубокая ссылка на Настройки — UIApplication.openNotificationSettingsURLString перенаправляет пользователя прямо к переключателю уведомлений вашего приложения. Используйте ее в моменты, когда пользователь активно запрашивает что-то, что могут доставить уведомления («получить уведомление, когда товар снова появится в наличии» → «уведомления для этого приложения отключены — включите их в Настройках?»). Напоминание о Настройках в случайный момент воспринимается как назойливость; то же напоминание в момент «хочу сейчас» воспринимается как помощь.
Измеряйте это как метрику роста, которой она является
Коэффициент подписки — это множитель для каждой push-кампании, которую вы когда-либо запустите, поэтому ее стоит правильно инструментировать: отслеживайте принятие мягкого запроса и конверсию нативного запроса отдельно, сегментируйте по моменту запуска, который вызвал запрос, и проверяйте состояние подписки с помощью getSubscriptionNotificationStatus — которая проверяет как подписку, так и разрешение — прежде чем считать кого-либо достижимым. Десять пунктов улучшения коэффициента подписки накапливаются по всем кампаниям, каждую неделю, в течение всего срока службы приложения.
Разрешение — это ворота. Как только пользователь прошел через них, все остальное — триггерные кампании, сегментация, последовательные рассылки — запускается с панели PushEngage без единой строки кода приложения. Руководство по настройке iOS поможет вам от установки SDK до вашей первой кампании за полдня.
