Push-уведомления: как устроены и зачем бизнесу

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

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

Разработка мобильных приложенийот 350 000 до 1 200 000 ₽сроки: 8-16 недель до релиза в сторах

Зачем бизнесу push уведомления в приложении

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

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

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

Разрешение: один вопрос и одна попытка

На iOS система спрашивает разрешение один раз. Пользователь нажал «Не разрешать» - всё, диалог больше не показать. Программно перезапросить нельзя, можно только отправить человека в системные настройки, куда он не пойдёт.

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

Android 13 и новее ведёт себя так же: разрешение POST_NOTIFICATIONS запрашивается явно. До Android 13 уведомления были включены по умолчанию, и приложения, собранные под старый target SDK, после обновления телефона внезапно теряли канал.

Как push попадает на телефон

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

Схема связей

Путь push-уведомления от события до экрана

Четыре звена. Ваш код управляет первыми двумя, дальше решает платформа и устройство.

Событие в системе

Заказ сменил статус Вебхук от платёжной системы или смена статуса админом
Наступило время напоминания Отложенная задача в очереди
Действие другого пользователя Комментарий, приглашение, подтверждение
Ручная рассылка Сегмент из админки, а не «всем сразу»

Ваш сервер

Токен устройства Получен приложением при первом запуске, живёт до переустановки
Настройки пользователя На какие типы сообщений он подписан
Сборка payload Заголовок, текст, данные для deep link, счётчик на иконке
Очередь и лимиты Не больше N сообщений в сутки на человека
Логи отправки Единственное место, где вы видите факт попытки

APNs и FCM

APNs для iOS Авторизация по ключу p8, HTTP/2, ответ с кодом ошибки
FCM для Android Отдельный проект Firebase и файл google-services.json
Приоритет доставки Высокий будит устройство, обычный ждёт удобного момента
Срок жизни сообщения Телефон офлайн дольше срока - сообщение исчезает

Устройство пользователя

Разрешение включено Иначе доставка есть, а показа нет
Режим экономии батареи Китайские прошивки режут фоновую активность жёстче всех
Обработка нажатия Deep link открывает нужный экран, а не главную
Тихий push Приложение обновляет данные без показа сообщения

Почему доставка не гарантирована

Ни Apple, ни Google не обещают доставку. Обещают попытку.

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

Практический вывод один: push не годится для критичных сообщений. Код подтверждения входа, одноразовый пароль, уведомление об оплате, без которого человек потеряет деньги, - всё это идёт по SMS или дублируется письмом. Push здесь работает как ускоритель, а не как канал доставки.

Транзакционные и маркетинговые

Разделять их надо на уровне архитектуры, а не в голове маркетолога.

Тип	Пример	Ожидание пользователя	Что происходит при злоупотреблении
Транзакционные	Заказ готов, оплата прошла, билет активирован	Ждёт и хочет	Не отключают почти никогда
Сервисные	Напоминание о записи, окончание подписки	Согласен, если по делу	Отключают при повторах
Маркетинговые	Скидка 20%, новая коллекция	Не просил	Отключают всё разом, включая первые два типа

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

Тихие push и фоновое обновление

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

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

Deep link: без него push бесполезен

Уведомление, которое открывает главный экран, теряет большую часть смысла. Человек нажал на «ваш заказ №4127 готов» и оказался на витрине, где надо самому искать раздел заказов. Половина в этот момент закрывает приложение.

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

Ещё одна деталь: если пользователь не авторизован, deep link должен пережить экран входа и сработать после него, а не потеряться.

Частота, время и сегментация

Массовая рассылка на всю базу - это способ разово поднять открытия и надолго уронить канал. Работает другое.

Сегменты. Купившим на прошлой неделе и не заходившим два месяца отправляются разные сообщения. Сегмент собирается по событиям аналитики, которые надо собирать с первого дня.
Лимит на человека. Не больше одного маркетингового сообщения в несколько дней, транзакционные не считаются.
Время. Ночная отправка стоит отписок. Часовой пояс берётся из профиля пользователя, а не из пояса вашего сервера. Ошибка на этом месте отправляет уведомление в четыре утра половине страны.
Текст. Заголовок до 40 символов, тело до 120, иначе система обрежет по своему усмотрению. Конкретика вместо интриги: «Заказ №4127 готов к выдаче до 21:00» работает лучше, чем «У нас для вас новость».
Проверка на устройствах. Как выглядит длинный текст на iPhone SE, что происходит с эмодзи, как отображается уведомление при заблокированном экране со скрытым содержимым.

Чем можно заменить

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

SMS доходит гарантированно и не требует приложения, но стоит денег за каждое сообщение и подходит только для коротких критичных вещей.

Email дешевле SMS и вмещает больше, но читается часами и требует работы с доставляемостью: SPF, DKIM, репутация домена.

Telegram-бот доставляет мгновенно, бесплатно, поддерживает кнопки и картинки, не требует установки приложения и стоит от 60 000 до 250 000 ₽ вместо стоимости приложения. Если весь смысл проекта в уведомлениях и простых действиях, я честно предлагаю начать с бота: сроки 1-3 недели вместо 8-16.

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