Push-уведомления как инструмент экономии на SMS: почему нативные пуши не работают и как это исправить

Стоимость SMS-трафика в России с 2022 года выросла более чем на 100%, и операторы продолжают менять схемы тарификации. В этом контексте push-уведомления — очевидная альтернатива: они в разы дешевле SMS и приходят напрямую в мобильное приложение. Однако большинство компаний, которые пробовали переводить трафик в push, сталкивались с одной и той же проблемой: стандартные нативные уведомления через Apple и Google не дают главного — уверенности в доставке.

Почему нативные push не работают как инструмент гарантированной доставки

Стандартная механика push-уведомлений через публичные облака Apple (APNs) и Google (FCM) не возвращает статусов доставки по каждому отправленному уведомлению. Это означает: нельзя достоверно знать, получил ли конкретный клиент сообщение. Следовательно — нельзя выстроить каскад «push → SMS при недоставке». Push остаётся вспомогательным каналом для некритичного контента, а все важные уведомления идут через дорогой SMS.

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

Как работают push-уведомления с возвратом статусов

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

Доставляемость push-уведомлений через платформу — от 80%. При нативной интеграции этот показатель со временем падает из-за устаревших токенов.

Безопасные push для чувствительных данных

Отдельный сценарий — передача чувствительных данных: паролей, транзакционных сообщений. Стандартный push передаёт весь текст через публичное облако — это неприемлемо для финансовых организаций. Решение — двухэтапная схема: через облако передаётся только заголовок уведомления (short push), который видит пользователь в шторке. При открытии приложения полный текст скачивается с сервера платформы по защищённому HTTPS. Чувствительные данные через публичные облака не проходят.

Формула расчёта экономии

Экономия зависит от двух параметров: процента проникновения мобильного приложения в базе и объёма SMS-трафика. Расчёт: количество сообщений × % проникновения приложения × % доставки push = количество сообщений, которые можно перевести в push-канал.

Пример для 1 млн сообщений при проникновении приложения 50%: 1 000 000 × 0,5 × 0,8 = 400 000 push-уведомлений. Стоимость push — около 144 000 рублей. Стоимость тех же 400 000 SMS объёмом 2 сегмента по 4 рубля — 3 200 000 рублей. Разница — более чем в 20 раз. При проникновении приложения от 40% и выше перевод трафика в push даёт значимую экономию.

Этапы запуска

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