Push-сповіщення для мобільних додатків: APNs, FCM, сегментація, rich push
Сповіщення, яке приходить не вовремя, в неправильний сегмент або з неробочим deep link — гірше від відсутності сповіщення. Користувач або одразу їх вимикає, або видаляє додаток. За даними різних джерел, рейт відмови від дозволу 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 або кастомний backend. Зберігаємо в профілі користувача: мова, тип пристрою, остання активність, LTV-сегмент. Сповіщення йде тільки тим, у кого last_active < 7_days та plan = premium. OneSignal дозволяє будувати такі фільтри в інтерфейсі без коду.
Персоналізовані — по конкретному device_token. Тут важливо зберігати токени правильно: токен оновлюється при переустановці додатку, при відновленні з бекапу на новий телефон, при скиданні налаштувань. На iOS користуємо UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, зберігаємо на backend при кожному запуску, не тільки при першому. Інакше через 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 при відправці, але не гарантує callback про доставку — це by design. Для tracking відкриттів потрібна кастомна логіка: при тапі на сповіщення в onMessageReceived або через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), відправляємо подію в аналітику з notification_id.
OneSignal надає вбудовану аналітику доставки та CTR. Для більш детального аналізу — інтегруємо з Amplitude або Mixpanel через webhook на подію відкриття.
Процес внедрення
Починаємо з аудиту поточної реалізації: як зберігаються токени, є ли обробка оновлення токенів, які типи сповіщень потребуються. Якщо проект з нуля — проектуємо архітектуру з урахуванням платформ та обсягу.
Типовий стек: FCM + APNs на транспортному рівні, OneSignal або Firebase Notifications Composer для сегментації, кастомний backend для персоналізованих подійних сповіщень. Для великих додатків з >1M користувачів OneSignal має цінові обмеження — тоді Braze або власна реалізація на AWS SNS.
Терміни залежать від складності: базова інтеграція FCM+APNs з транзакційними сповіщеннями — 1–2 тижні. Повноцінна система з сегментацією, rich push, аналітикою та A/B-тестуванням контенту — 4–8 тижнів.