Push-уведомления для мобильных приложений: APNs, FCM, сегментация, rich push
Уведомление, которое приходит не вовремя, в неправильный сегмент или с неработающим deep link — хуже отсутствия уведомления. Пользователь либо отключает их сразу, либо удаляет приложение. По данным разных источников, rate отказа от push-разрешений на iOS доходит до 40% в первую неделю после установки — и причина почти всегда в нерелевантности, а не в самой механике.
Как работает инфраструктура: APNs и FCM
Apple Push Notification service (APNs) — единственный канал доставки на iOS. Всё остальное — OneSignal, Braze, Airship — обёртки поверх него. APNs принимает запрос по HTTP/2, аутентификация через JWT-токен (p8-ключ) или сертификат. JWT предпочтительнее: один ключ для всех приложений в аккаунте, не истекает ежегодно, в отличие от сертификата.
Критический момент: APNs различает apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно указанный тип на iOS 13+ приводит к тому, что background-уведомление не разбудит приложение. Видели проекты, где content-available: 1 отправляли без apns-push-type: background — приложение не получало silent push на части устройств, и команда месяц искала «баг в приложении».
Firebase Cloud Messaging (FCM) на Android работает через Google Play Services. Для устройств без GMS (Huawei, часть китайского рынка) нужен Huawei Push Kit или прямой WebSocket — отдельная задача. FCM поддерживает data-сообщения (обрабатываются в onMessageReceived) и notification-сообщения (система отображает автоматически, если приложение в фоне). Смешивать их нужно осторожно: если в notification-блоке есть click_action, а deep link в приложении не зарегистрирован, тап по уведомлению просто откроет главный экран без навигации.
Сегментация и таргетинг
Отправлять всем подряд — значит быстро исчерпать лояльность пользователей. Нормальная сегментация строится на нескольких уровнях.
Топики (FCM topics / APNs push-to-topic через OneSignal) — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается на топик через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, но нет гибкой фильтрации.
Сегменты по атрибутам — через OneSignal, Braze или кастомный бэкенд. Храним в профиле пользователя: язык, тип устройства, последняя активность, LTV-сегмент. Уведомление уходит только тем, у кого last_active < 7_days и plan = premium. OneSignal позволяет строить такие фильтры в интерфейсе без кода.
Персонализированные — по конкретному device_token. Тут важно хранить токены правильно: токен обновляется при переустановке приложения, при восстановлении из бэкапа на новый телефон, при сбросе настроек. На iOS используем UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, сохраняем на бэкенд при каждом запуске, не только при первом. Иначе через 3 месяца 30% токенов в базе устаревшие.
Rich push: изображения, кнопки, прогрессбары
Стандартное уведомление с заголовком и текстом кликают значительно реже, чем rich push с картинкой и кнопками действий. Но реализация rich push — отдельная работа на каждой платформе.
На iOS rich content требует UNNotificationServiceExtension (для модификации payload, например расшифровки или загрузки медиа) и UNNotificationContentExtension (кастомный UI). Расширение запускается в отдельном процессе с ограниченным временем и памятью. Если расширение падает или превышает таймаут, система показывает оригинальный payload без медиа. Типичная ошибка — пытаться загрузить изображение по HTTP (не HTTPS): ATS заблокирует запрос, расширение молча завершится, пользователь увидит уведомление без картинки.
На Android с API 26+ уведомления привязаны к NotificationChannel. Если канал создан с IMPORTANCE_LOW, звук и вибрация недоступны, даже если в payload указаны — это решение пользователя, изменить его можно только через системные настройки приложения. Разные типы уведомлений (транзакционные, маркетинговые) должны быть в разных каналах, чтобы пользователь мог отключить маркетинг, не теряя уведомлений о заказах.
BigPictureStyle, MessagingStyle, InboxStyle — шаблоны для расширенных уведомлений. MessagingStyle с Person и аватарками — лучший выбор для чатов, система правильно группирует и отображает историю.
Аналитика доставки и конверсии
Отправить уведомление — полдела. Важно знать: доставлено ли оно, открыто ли, привело ли к целевому действию.
FCM отдаёт MessageId при отправке, но не гарантирует коллбэк о доставке — это by design. Для tracking открытий нужна кастомная логика: при тапе на уведомление в onMessageReceived или через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) отправляем событие в аналитику с notification_id.
OneSignal предоставляет встроенную аналитику доставки и CTR. Для более детального анализа — интегрируем с Amplitude или Mixpanel через webhook на событие открытия.
Процесс внедрения
Начинаем с аудита текущей реализации: как хранятся токены, есть ли обработка обновления токенов, какие типы уведомлений нужны. Если проект с нуля — проектируем архитектуру с учётом платформ и объёма.
Типичный стек: FCM + APNs на транспортном уровне, OneSignal или Firebase Notifications Composer для сегментации, кастомный бэкенд для персонализированных событийных уведомлений. Для крупных приложений с >1M пользователей OneSignal имеет ценовые ограничения — тогда Braze или собственная реализация на AWS SNS.
Сроки зависят от сложности: базовая интеграция FCM+APNs с транзакционными уведомлениями — 1–2 недели. Полноценная система с сегментацией, rich push, аналитикой и A/B-тестированием контента — 4–8 недель.