TL;DR
- Push - это не бесплатная реклама. Это permission-based канал, который легко потерять.
- Retention начинается с продукта. Push только напоминает о пользе, статусе, риске или следующем шаге.
- На iOS нужен явный permission flow. На Android 13+ тоже есть runtime permission
POST_NOTIFICATIONS. - Хороший push всегда имеет сегмент, причину, timing, frequency cap, deep link и метрику результата.
- Если push ведет на главный экран или шлется всей базе каждый день, вы сжигаете канал.
1. Что такое retention в мобайле
Retention - это способность продукта вернуть пользователя к полезному действию. Для приложения это важнее install.
Push notifications - один из инструментов retention. Но если продукт не дает ценность, push превращается в шум. Пользователь отключает уведомления, а иногда удаляет приложение.
2. Как работает push-канал
Упрощенно:
- Приложение получает permission.
- Устройство получает push token.
- Token уходит на ваш backend / CRM / push provider.
- Маркетинг или система отправляет message.
- FCM/APNs доставляют notification на устройство.
- Пользователь открывает push.
- Deep link ведет в нужный экран.
- Analytics фиксирует результат.
| Платформа | Что важно |
|---|---|
| iOS | APNs, UserNotifications, permission, notification settings |
| Android | FCM, notification channels, Android 13+ permission |
| Cross-platform | Firebase Cloud Messaging, OneSignal, Braze, Customer.io, custom backend |
FCM может быть удобным cross-platform слоем, но iOS все равно опирается на Apple Push Notification service и iOS notification rules.
3. Permission: где чаще всего теряют канал
Просить push permission на первом экране - плохая привычка. Пользователь еще не понял пользу и чаще нажимает deny.
Лучше:
Примеры хорошего момента:
- доставка: "Разрешите уведомления, чтобы узнать, когда курьер подъедет";
- банк: "Получайте подтверждения переводов и security alerts";
- EdTech: "Напомним о занятии за 30 минут";
- travel: "Сообщим об изменении рейса";
- marketplace: "Сообщим, когда цена снизится".
Android 13+ тоже требует runtime permission для обычных уведомлений. Поэтому стратегия "на Android все разрешено" уже не работает.
4. Типы push-уведомлений
| Тип | Пример | Риск |
|---|---|---|
| Transactional | "Заказ передан курьеру" | Низкий, если полезно |
| Security | "Вход с нового устройства" | Низкий, важно не задерживать |
| Lifecycle | "Продолжите урок" | Средний, нужен timing |
| Abandoned cart | "Товар все еще в корзине" | Средний, нужен frequency cap |
| Promo | "Скидка 20%" | Высокий, быстро становится спамом |
| Winback | "Мы давно вас не видели" | Высокий, нужен сильный повод |
Самый здоровый push-канал обычно начинается с transactional и lifecycle, а не с скидок.
5. Сегментация и триггеры
Broadcast push всей базе почти всегда слабый инструмент.
| Segment | Trigger | Message idea |
|---|---|---|
| New user, no activation | 24h after install | Помочь завершить первый шаг |
| Cart abandoned | 1-3h after cart | Вернуть к конкретному товару |
| Lesson missed | До занятия / после пропуска | Напомнить о расписании |
| Price watcher | Price drop | Сообщить о снижении цены |
| Loyal buyer | Category restock | Персональная причина вернуться |
| Dormant user | 30 days inactive | Сильный new value, не просто "вернитесь" |
Триггер должен быть связан с намерением пользователя. Если он искал билет в Стамбул, push про Астану-Москва выглядит случайным.
6. Deep links обязательны
Push без deep link - потеря контекста.
| Push | Куда должен вести |
|---|---|
| "Ваш заказ у курьера" | Экран конкретного заказа |
| "Цена на товар снизилась" | Карточка товара |
| "Урок начнется через 30 минут" | Экран урока |
| "Платеж не прошел" | Экран оплаты / retry |
| "Друг отправил бонус" | Referral reward screen |
Главный экран допустим только если push не имеет конкретного объекта. В большинстве retention-сценариев объект есть.
7. Метрики push retention
Не оценивайте push только по open rate.
| Метрика | Что показывает |
|---|---|
| Opt-in rate | Сколько пользователей разрешили канал |
| Delivery rate | Дошли ли уведомления технически |
| Direct open rate | Сколько открыли push |
| Influenced open | Сколько открыли app вскоре после push |
| Conversion rate | Сколько выполнили целевое действие |
| Unsubscribe / opt-out | Сколько потеряли permission |
| D1/D7/D30 retention | Влияет ли lifecycle на возвращаемость |
| Revenue / LTV uplift | Есть ли деньги, а не только клики |
Push может иметь низкий open rate, но высокий business value, если это security или transactional notification. Поэтому metric должен соответствовать типу push.
8. Frequency cap
Если пользователь получает 5 push в день, он не различает важные от рекламных. Нужны лимиты.
Пример правил:
- transactional не считаются в marketing cap;
- promo не чаще 2-3 раз в неделю;
- abandoned cart не больше 1-2 раз на корзину;
- no nighttime pushes без критической причины;
- учитывать timezone;
- останавливать цепочку после conversion;
- suppress users with recent complaints/uninstalls where possible.
Важно: не все push должны конкурировать. Security alert важнее скидки. Курьер важнее weekly digest.
9. Локальный контекст СНГ/РК
В Казахстане push часто экономит деньги, потому что SMS и paid retargeting стоят дороже. Но это не значит, что можно слать все в push.
Полезные локальные сценарии:
- статус доставки;
- напоминание о записи или уроке;
- Kaspi/payment status;
- price drop;
- arrival of courier;
- security alert;
- loyalty balance;
- localized city offers.
Анти-сценарий: ежедневный "СКИДКИ" всей базе. После месяца такого поведения канал становится слабым: пользователи отключают уведомления, а важные сообщения не доходят.
10. Практический чеклист
- Permission запрашивается после value moment, не на первом экране.
- Android 13+ notification permission учтен.
- Push token связан с
customer_user_id. - Есть segment, trigger, message, deep link и goal для каждого push.
- Transactional и marketing pushes разделены.
- Есть frequency cap и quiet hours.
- Push open и downstream events трекаются.
- Отдельно считаются opt-out и uninstall после кампаний.
- A/B tests проверяют не только текст, но и timing.
- Support и product получают feedback из push complaints.
11. Видео
12. Главный совет
Push должен быть продолжением пользы, а не заменой продукта. Отправляйте уведомление только тогда, когда можете честно закончить фразу: "пользователю полезно узнать это сейчас, потому что..."
Sources / Notes
- Firebase: Firebase Cloud Messaging
- Apple Developer: User Notifications
- Apple Developer: Generating a remote notification
- Apple Human Interface Guidelines: Notifications
- Android Developers: Notification runtime permission
- OneSignal: Push notification best practices 2026