SMS как резерв для push: архитектура доставки в мобильном приложении
SMS как резерв для push — это не одновременная отправка одного текста по двум каналам. Приложение сначала пытается доставить push, ждёт подтверждение по заданному правилу и только затем решает, нужно ли SMS. Такой каскад подходит для ограниченного числа важных событий: входа, оплаты, изменения бронирования или срочного статуса заказа.
Эта статья посвящена именно технической архитектуре резервирования и не повторяет общий материал об использовании SMS, когда push отключён.
Когда резерв действительно нужен
Событие должно одновременно отвечать трём условиям:
- Пользователь ожидает уведомление в рамках выполненного действия.
- Пропуск приведёт к заметной проблеме или дополнительному обращению.
- Информация ещё будет полезна к моменту переключения на SMS.
Новость продукта, скидка или совет по функции обычно не соответствуют этим условиям. Для них достаточно push, email или центра уведомлений.
Что означает «push не доставлен»
Ответ сервиса push о принятии запроса не гарантирует, что человек увидел уведомление. С другой стороны, отсутствие открытия не означает недоставку: текст мог быть прочитан на экране блокировки.
Поэтому правило переключения зависит от события. Возможные сигналы:
- токен устройства недействителен;
- пользователь запретил уведомления;
- push-провайдер вернул финальную ошибку;
- приложение не подтвердило получение за допустимое время;
- бизнес-действие не выполнено к контрольной точке.
Последний вариант часто надёжнее. Например, резервное SMS о записи отправляется не потому, что push не открыт, а потому, что пользователь не подтвердил изменение времени.
Срок полезности события
Каждому уведомлению задают expires_at. Если срок истёк, резерв уже не отправляется. SMS с кодом входа через двадцать минут бесполезно, а сообщение о завтрашней встрече может сохранять смысл несколько часов.
Также задают fallback_after — момент, когда разрешено переключение. Слишком короткий интервал создаёт дубли, слишком длинный оставляет пользователя без важной информации.
Пример каскада
Для переноса бронирования цепочка может выглядеть так:
- Система создаёт событие версии 2.
- Push отправляется на все активные устройства пользователя.
- Приложение или бизнес-система фиксирует подтверждение.
- Через 15 минут проверяется актуальность версии.
- Если подтверждения нет и срок не истёк, отправляется SMS.
- После подтверждения все оставшиеся задания отменяются.
Время бронирования №418 изменено на 24 июля, 16:30. Подтвердите или выберите другое: [ссылка].
SMS должно быть самодостаточным: пользователь может не иметь доступа к приложению именно сейчас.
Дедупликация между каналами
У события должен быть единый идентификатор для push, SMS, email и внутреннего центра. Каналы записываются как попытки одной коммуникации, а не независимые кампании.
Идемпотентный ключ включает пользователя, событие и версию. Если данные изменились, создаётся новая версия, а старая закрывается. Повтор worker или webhook не должен создавать второе SMS.
Несколько устройств и номеров
Пользователь может иметь два телефона, несколько push-токенов и рабочий номер в корпоративном аккаунте. Определите приоритет контактов и способ подтверждения номера. Недействительные токены очищайте, а номер после смены проверяйте заново.
В B2B-продукте получателем иногда является не пользователь действия, а администратор аккаунта. Роль должна задаваться сценарием, иначе технические уведомления уйдут всей команде.
Безопасность
Не переносите в SMS весь текст push, если там есть персональные данные. Для резервного канала используйте отдельный сокращённый шаблон и защищённую ссылку. OTP-коды живут в собственном сценарии с ограничением частоты; подробнее — в статье про OTP SMS.
Подключение QUICKTEL
Сервис уведомлений вызывает HTTP API QUICKTEL только после выполнения fallback-условия. Идентификатор SMS связывается с общим событием. Финальный статус доставки помогает решить, нужен ли следующий резервный канал.
Не используйте недоставку как команду немедленно повторить сообщение. Установите максимальное число попыток и общий срок жизни события.
Пользовательские настройки каналов
Настройка «не присылать push» не всегда означает согласие на SMS, а отключение рекламных SMS не должно ломать ожидаемый код входа. В профиле разделяйте категории коммуникации и показывайте, какой канал используется для каждой.
Для критичного события пользователь может выбрать SMS основным каналом. Тогда система не ждёт push-fallback, а сразу создаёт одну попытку SMS. Решение сохраняется вместе с версией настроек, чтобы можно было объяснить выбор маршрута.
Изменение номера требует подтверждения. Пока новый номер не проверен, нельзя незаметно перенаправлять на него уведомления безопасности.
Наблюдаемость каскада
Для диагностики недостаточно общего процента доставки. В журнале нужны время создания события, попытки push, причина переключения, версия данных, запрос SMS и финальное бизнес-действие. Все записи связывает один correlation ID.
Настройте сигналы на резкий рост fallback, задержку очереди и SMS после закрытого события. Первый может означать проблему push-провайдера или релиз приложения с повреждёнными токенами; второй — перегрузку; третий — ошибку отмены.
Тестируйте каскад с управляемыми часами: push вовремя, финальная ошибка, запоздалое подтверждение, новая версия события и истёкший срок. Это помогает воспроизводить гонки без ожидания реальных минут.
Метрики каскада
Отслеживайте долю событий, закрытых push, долю переключений на SMS, время до подтверждения, дубли между каналами и стоимость завершённого действия. Отдельно смотрите случаи, когда SMS ушло после уже выполненного действия: это главный сигнал ошибки задержки или синхронизации.
Начните с одного критичного события и сравните результаты с простой одновременной отправкой. После отладки общей модели подключайте другие сценарии, задавая им собственные сроки и условия fallback.
