Один заказ доставки легко превращается в 5-7 пуш-уведомлений между статусами “подтверждён” и “доставлен”. Умножьте на пару заказов в неделю, и приложение начинает выглядеть как спам-канал. Средний пользователь смартфона уже получает 46 пуш-уведомлений в день; 43% отключают их, когда приложения присылают всего 2-5 пушей в неделю.
Пользователи хотят знать, что происходит в любой момент, а не получать пять перебивок по пути. Разница между вовлечением и opt-out в одном: понять, какие моменты действительно требуют пуш-уведомления, а какие достаточно просто держать на виду.
Этот гайд разбирает, когда пуш-уведомление оправдано, а когда работу лучше доверить Live Activities, даёт правило трёх сообщений для любого real-time сценария и показывает, как адаптировать подход под вашу вертикаль без рефакторинга стека. По ходу вы увидите, как Pushwoosh помогает оркестрировать push + Live Activities в одном customer journey.
Alerts vs live state: единственное важное различие
Большинство команд используют пуш-уведомления как дефолтный канал для всего, что связано с real-time. Заказ подтверждён - пуш. Курьер назначен - пуш. Курьер едет - пуш. Курьер подъезжает - пуш. Доставлен - пуш. Пять перебивок на одно событие, которое пользователь сам инициировал и которого уже ждёт.
Каждое из этих обновлений важно, но не каждое должно быть пуш-уведомлением. В real-time сценариях есть 2 принципиально разных коммуникационных задачи:
Alerts говорят “Что-то произошло! Посмотрите сейчас”. Они перебивают и требуют внимания. Их место - в моментах, которые действительно требуют решения или изменения поведения: у вашего рейса сменился гейт, платёж отклонён, такси приехало.
Live state говорит “Вот что происходит прямо сейчас, загляните, когда удобно”. Это амбиентная информация, которая обновляется непрерывно. Live state покрывает то, что пользователи хотят отслеживать без необходимости реагировать: локация курьера, время приготовления, ETA доставки, счёт в матче, пройденная дистанция на тренировке.
Пуш-уведомления создавались под alerts. Live Activities создавались под live state. Использовать пуш для отслеживания состояния - значит перебивать пользователя ради информации, которую он не просил ему приносить.
Правило трёх сообщений
Для любого real-time сценария вам нужно максимум 3 пуш-уведомления.
Start. Подтверждает, что процесс начался. “Ваш заказ подтверждён”. “Платёж инициирован”. “Ваше такси едет”. Это задаёт ожидания, даёт пользователю уверенность и активирует Live Activity, которая возьмёт на себя всё остальное.
Exception. Что-то пошло не так или требует внимания. “Товара нет в наличии”. “Курьер не может найти вход”. “Платёж отклонён, обновите карту”. “Рейс задерживается на 2 часа”. Это настоящие перебивки, потому что они требуют действия.
Finish. Процесс завершён. “Ваш заказ доставлен”. “Платёж получен”. “Вы на месте”. Это закрывает цикл и завершает Live Activity.
Всё, что между Start и Finish, живёт на lock screen как Live Activity: обратный отсчёт времени приготовления, движение курьера по карте, обновление счёта, пересчёт ETA. Обновляется автоматически, с нулём перебивок.
Как это выглядит на практике: заказ доставки еды
Возьмём стандартный flow доставки, до и после.
До (только пуши), 5 уведомлений за ~45 минут:
- “Ваш заказ подтверждён”
- “Ваш заказ готовится”
- “Курьер забрал ваш заказ”
- “Курьер рядом”
- “Ваш заказ доставлен”
Пять перебивок на один обед. Умножьте на два-три заказа в неделю - и одно приложение присылает 10-15 пушей. Это тот порог, на котором пользователи начинают полностью отключать уведомления.
После (правило трёх пушей + Live Activity):
- Push: “Ваш заказ подтверждён” -> стартует Live Activity
- Live Activity обновляется молча: готовится -> забран -> локация курьера -> обратный отсчёт ETA
- Push (только при необходимости): “Курьер не может попасть в здание, проверьте телефон”
- Live Activity: обратный отсчёт ETA продолжается
- Push: “Ваш заказ доставлен” -> Live Activity завершается
Пользователь получает 2 перебивки вместо 5, или три, если возникает проблема. Lock screen остаётся чистым, а real-time видимость становится лучше. Вместо пяти несвязанных пингов пользователь видит живой непрерывный трекер с локацией курьера и ETA, который обновляется каждые несколько секунд.
Результат: меньше opt-out, меньше тикетов “где мой заказ” в саппорте, и приложение остаётся видимым на lock screen 30-45 минут подряд вместо того, чтобы моргнуть пять раз и исчезнуть.
Адаптируйте правило под своё приложение
Та же схема работает везде, где пользователи отслеживают что-то в real-time. Примеры ниже отражают вертикали, которые чаще всего запускают русскоязычные команды на международных рынках - от мобильности в ЕС до fintech в Дубае и глобальных gaming-студий.
| Приложение | Push: Start | Live Activity | Push: Exception | Push: Finish |
|---|---|---|---|---|
| Мобильность / такси (Bolt, Gett) | Водитель назначен | Локация, ETA, марка машины | Водитель отменил / перестроил маршрут | Поездка завершена + стоимость |
| E-commerce (глобальный маркетплейс) | Заказ отправлен | Упаковка -> в пути -> курьеру на выдачу -> рядом | Задержка или неудачная попытка | Доставлен |
| FinTech (Revolut, Wise, крипто-кошельки) | Транзакция инициирована | Статус обработки (cross-border, верификация) | Платёж отклонён / подозрительная активность | Транзакция завершена |
| Gaming (live ops, мидкор, казуалки) | Турнир начался / энергия полная | Позиция в лидерборде, таймер босса, прогресс | Найден оппонент / серия под угрозой | Результат матча |
| Новости и медиа | Breaking news / live-событие | Live-тикер: счёт, голоса, заголовок | Значимое развитие | Событие завершено |
В каждом случае пуш отмечает переходы, которые действительно важны. Live Activity несёт состояние между ними.
Как начать без рефакторинга стека
Типичное возражение: “Чтобы добавить Live Activities, нужен серьёзный рефакторинг”. На практике трёхшаговый подход укладывается в один спринт.
-
Проведите аудит текущего push-потока
Выберите один real-time journey (отслеживание заказа, поездка, матч) и выпишите каждый пуш, который он триггерит. Пометьте каждое уведомление: требует ли оно от пользователя сделать что-то или узнать что-то новое, или это просто обновление статуса, которое пользователь мог бы проверить сам? Обычно после такого фильтра из 5-7 пушей выживают 2-3.
-
Уберите лишнее и замените
Отключите пуши со статусными обновлениями. Запускайте Live Activity на Start-пуше и завершайте её на Finish-пуше. Обновляйте её через API в каждой точке, где раньше отправляли пуш-уведомление.
-
Измеряйте
Отслеживайте три метрики в течение 2-4 недель. Opt-out rate должен упасть. Объём тикетов по теме 'где мой заказ' снижается, потому что Live Activities дают пользователям self-serve видимость. А частота сессий чаще растёт, чем падает: пользователи с активной Live Activity обычно чаще открывают приложение, потому что lock screen превращается в точку входа.
Запустите первый real-time сценарий с Pushwoosh
Работа с пуш-уведомлениями - это не про то, чтобы присылать больше сообщений. Это про то, чтобы присылать правильные сообщения в правильном канале и оставлять lock screen полезным, а не шумным.
Pushwoosh помогает оркестрировать push-уведомления и Live Activities в одном canvas Customer Journey Builder: триггеры на ключевых событиях, real-time обновления состояния через API, exception-ветвление для edge-кейсов. Один SDK, один API, один дашборд для iOS, Android и web - с enterprise-grade безопасностью (SOC 2 Type I, ISO 27001:2022, GDPR).
