Реалізація сповіщень про завершення підписки в мобільному додатку

При запуску мобільного додатку з підписками типова ситуація: платіж не пройшов, користувач навіть не помітив, додаток мовчить. Іде до 60% клієнтів при першому збої автоплатежу. Без ланцюжка сповіщень відновити підписку майже неможливо. Грамотна система push-сповіщень утримує до 40% користувачів на межі відписки. Розберемо, як налаштувати сповіщення про завершення підписки за допомогою StoreKit 2, FCM та правильної сегментації. Наш досвід — 5+ років та 50+ проєктів у сфері підписок. Ми гарантуємо якість інтеграції та надаємо підтримку після запуску.

Чому одного push-сповіщення про завершення підписки недостатньо?

Одне сповіщення — погана стратегія. Користувач може проігнорувати або відкласти. Дослідження показують: каскад із 3-4 нагадувань підвищує конверсію в продовження в 1.5 раза. Використовуємо ланцюжок: за 7 днів → за 1 день → у день завершення → через 3 дні. Кожен крок — новий заклик із конкретним deeplink.

Серверні події vs. локальні сповіщення

Перше питання: звідки знати, коли підписка завершується? Для In-App Purchase (StoreKit) Apple надсилає події на сервер через App Store Server Notifications V2. Для власних серверних підписок — логіка на вашому боці.

StoreKit 2 / App Store Server Notifications V2: Apple шле RENEWAL та EXPIRED події на ваш сервер. При отриманні DID_FAIL_TO_RENEW — перший сигнал, що потрібно відправити push. При GRACE_PERIOD_EXPIRED — останній шанс. Apple самостійно відправляє деякі системні сповіщення, але покладатися лише на них не можна — бізнес-логіку нагадувань будувати потрібно самостійно. StoreKit сповіщення через App Store Server Notifications V2 дозволяють отримувати події про підписки. FCM підписки інтегруються через Firebase Cloud Messaging.

// Серверна нотифікація V2 (декодований payload)
{
  "notificationType": "DID_FAIL_TO_RENEW",
  "subtype": "GRACE_PERIOD",
  "data": {
    "bundleId": "com.example.app",
    "transactionInfo": { ... }
  }
}

App Store Server Notifications Apple Developer Documentation

Локальні сповіщення підходять тільки якщо сервера немає зовсім, або для офлайн-сценаріїв. UNUserNotificationCenter з UNCalendarNotificationTrigger — плануємо сповіщення на дату expiresDate - 3 days. Проблема: якщо користувач продовжив підписку через веб або інший пристрій, локальне сповіщення все одно спрацює. Без синхронізації з сервером це дає хибні спрацьовування.

Серверні push в 3-4 рази кращі за локальні за точністю доставки та гнучкістю налаштування.

Ланцюжок сповіщень про завершення підписки

Працююча схема для B2C: схема нагадувань складається з 4 етапів.

• За 7 днів до завершення: «Підписка завершується 15 квітня — продовжте, щоб не втратити дані»
• За 1 день: конкретний заклик із deeplink на екран керування підпискою
• У день завершення: сповіщення з обмеженою за часом пропозицією (якщо є)
• Через 3 дні після: реактивація зі знижкою (опціонально)

Deeplink у сповіщенні обов'язковий. Push без дії втрачає конверсію. На iOS: UNNotificationAction з foreground — відкриває додаток і передає userInfo. На Android: PendingIntent з потрібним Intent.

Автоподовження підписки може зірватися через помилку оплати, тому важливі сповіщення.

// iOS: обробка tap по сповіщенню про підписку
func userNotificationCenter(_ center: UNUserNotificationCenter,
    didReceive response: UNNotificationResponse) async {
    let info = response.notification.request.content.userInfo
    if info["type"] as? String == "subscription_expiry" {
        NavigationRouter.shared.navigate(to: .subscriptionManagement)
    }
}

На Android через FCM аналогічно: в data payload передаємо type: subscription_expiry, в FirebaseMessagingService.onMessageReceived маршрутизуємо.

class MyFirebaseMessagingService : FirebaseMessagingService() {
    override fun onMessageReceived(message: RemoteMessage) {
        val type = message.data["type"]
        if (type == "subscription_expiry") {
            // Відкрити екран підписок
            val intent = Intent(this, SubscriptionActivity::class.java)
            startActivity(intent)
        }
    }
}

Що робити, якщо push не доставлений?

Перевірте дозволи на сповіщення (ATT на iOS, налаштування на Android), статус device token та правильність deeplink. Враховуйте часовий пояс користувача — відправляйте push у локальний денний час. Реалізуйте логіку повторної відправки з ручним тригером. Деоптимізація push-сповіщень, як-от неправильний таймінг або відсутність deeplink, знижує конверсію.

Сегментація та таймінг

Користувач із місячною підпискою та користувач із річною — різні ситуації. Для місячної 7-денне вікно — це 25% залишкового терміну, що агресивно. Річна — 7 днів із 365, нормально. Мобільні підписки потребують особливої уваги до таймінгу сповіщень.

Часовий пояс користувача критичний: push о 3 ночі — роздратування та відписка. Firebase FCM дозволяє задавати delivery_time з урахуванням локального часу пристрою. Для APNs це робиться на рівні сервера через планувальник завдань з урахуванням timezone користувача.

Процес роботи

1. Аудит поточної системи підписок: StoreKit / серверні / гібрид.
2. Налаштування App Store Server Notifications V2 або серверних вебхуків для тригерів завершення.
3. Реалізація ланцюжка push-сповіщень з deeplink на потрібний екран.
4. Тестування на sandbox-середовищі StoreKit та бойовою перевіркою FCM.
5. Моніторинг та коригування таймінгів на основі аналітики.

Що входить у роботу

• Налаштування App Store Server Notifications V2 / серверних вебхуків
• Розробка ланцюжка push-сповіщень (до 4 етапів)
• Інтеграція deeplink на екран керування підпискою
• Логування подій для аналітики
• Документація та інструкція для вашої команди
• Підтримка 1 місяць після запуску

Орієнтири за термінами

Інтеграція з готовим сервером сповіщень та StoreKit 2 — 2–3 дні. Реалізація серверної логіки з нуля, планувальником завдань та сегментацією користувачів — до 1 тижня. Налаштування push-сповіщень включає вибір каналів (APNs/FCM) і налаштування дозволів.

Втрата одного користувача з річною підпискою обходиться в середньому в $300–$500, а каскад сповіщень повертає 15–20% з них. Впровадження ланцюжка сповіщень збільшує LTV на 20–30% та знижує витрати на залучення нових користувачів на 15%. Наприклад, для додатку з 10 000 передплатників впровадження системи сповіщень може збільшити річний дохід на $45 000.

Отримати консультацію щодо вашого проєкту — зв'яжіться з нами, оцінимо обсяг робіт та запропонуємо рішення. Замовте безкоштовний аудит поточної системи підписок.

Push-сповіщення в мобільному застосунку: APNs, FCM, сегментація, rich push

Ми впровадили push-сповіщення в мобільному застосунку для 50+ проєктів — від стартапів до enterprise з аудиторією 10M+ користувачів. Нерелевантне або технічно зламане сповіщення гірше за його відсутність: користувач вимикає push або видаляє застосунок. Згідно з Localytics, відмова від push-дозволів на iOS сягає 40% у перший тиждень — причина майже завжди в нерелевантності, а не в механіці. Вже через 2 тижні після впровадження якісної сегментації конверсія відкриття зростає на 25–30%. Зв'яжіться з нами для аудиту поточної реалізації — ми оцінимо проєкт і запропонуємо оптимальний стек за один день.

Як працює інфраструктура: APNs та FCM

APNs — єдиний канал доставки на iOS. Все інше (OneSignal, Braze, Airship) — обгортки поверх нього. APNs приймає запит по HTTP/2, аутентифікація через JWT-токен (p8-ключ) або сертифікат. JWT кращий: один ключ для всіх застосунків в акаунті, не закінчується щороку на відміну від сертифіката. (Докладніше — Wikipedia)

Критичний момент: APNs розрізняє apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно вказаний тип на iOS 13+ призводить до того, що background-сповіщення не розбудить застосунок. Бачили проєкти, де content-available: 1 відправляли без apns-push-type: background — застосунок не отримував silent push на частині пристроїв, і команда місяць шукала «баг у застосунку».

FCM на Android працює через Google Play Services. Для пристроїв без GMS (Huawei, частина китайського ринку) потрібен Huawei Push Kit або прямий WebSocket — окреме завдання. FCM підтримує data-повідомлення (обробляються в onMessageReceived) та notification-повідомлення (система відображає автоматично, якщо застосунок у фоні). Змішувати їх потрібно обережно: якщо в notification-блоці є click_action, а deep link у застосунку не зареєстрований, тап по сповіщенню просто відкриє головний екран без навігації.

Чому сегментація — основа ефективних push-сповіщень?

Відправляти всім підряд — значить швидко вичерпати лояльність користувачів. Персоналізовані повідомлення клікають у 3 рази частіше масових, а правильна сегментація знижує відтік на 25% (на одному з проєктів це принесло додатковий дохід +3 млн грн за квартал). Вартість налаштування сегментації в 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 із картинкою та кнопками дій — у 3 рази. Але реалізація rich push — окрема робота на кожній платформі.

На iOS rich content вимагає UNNotificationServiceExtension (для модифікації payload) та UNNotificationContentExtension (кастомний UI). Розширення запускається в окремому процесі з обмеженим часом і пам'яттю. Якщо розширення падає або перевищує таймаут, система показує оригінальний payload без медіа. Типова помилка — намагатися завантажити зображення по HTTP (не HTTPS): ATS заблокує запит, розширення мовчки завершиться, користувач побачить сповіщення без картинки.

На Android з API 26+ сповіщення прив'язані до NotificationChannel. Якщо канал створений з IMPORTANCE_LOW, звук і вібрація недоступні. Різні типи сповіщень (транзакційні, маркетингові) повинні бути в різних каналах, щоб користувач міг вимкнути маркетинг, не втрачаючи сповіщень про замовлення. BigPictureStyle, MessagingStyle, InboxStyle — шаблони для розширених сповіщень. MessagingStyle з Person та аватарками — найкращий вибір для чатів.

Як відстежити доставку та конверсію push-сповіщень?

Відправити сповіщення — половина справи. Важно знати: доставлено воно, відкрито, чи привело до цільової дії.

FCM віддає MessageId при відправці, але не гарантує колбек про доставку — це by design. Для tracking відкриттів потрібна кастомна логіка: при тапі на сповіщення в onMessageReceived або через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) відправляємо подію в аналітику з notification_id.

OneSignal надає вбудовану аналітику доставки та CTR. Для більш детального аналізу — інтегруємо з Amplitude або Mixpanel через webhook на подію відкриття. Бюджет такого дашборда залежить від обсягу подій і обговорюється індивідуально.

Як ми впроваджуємо push-сповіщення: типовий процес

1. Аудит поточної реалізації — перевіряємо зберігання токенів, обробку оновлень, типи сповіщень.
2. Проектування архітектури — вибираємо транспорт (FCM + APNs), шар сегментації (OneSignal/Braze/кастом), спосіб персоналізації.
3. Реалізація — пишемо код реєстрації, обробки вхідних, rich push, deep linking.
4. Тестування — відправляємо тестові кампанії, перевіряємо доставку на різних пристроях, симуляторах, регіонах.
5. Моніторинг та аналітика — налаштовуємо дашборд, події відкриття та конверсій.
6. Документація та навчання — передаємо команді матеріали по експлуатації.

Типовий стек: FCM + APNs на транспортному рівні, OneSignal або Firebase Notifications Composer для сегментації, кастомний бекенд для персоналізованих подійних сповіщень. Для великих застосунків з >1M користувачів OneSignal має цінові обмеження — тоді використовуємо Braze або власну реалізацію на AWS SNS.

Що входить у роботу (deliverables)

• Документація — архітектурна схема push-потоків, інструкція для розробників, опис сегментів
• Кодова база — репозиторій з реалізацією реєстрації, обробки, rich push, deep linking
• Доступи — налаштовані проектні конфігурації в Firebase Console, App Store Connect, OneSignal/Braze
• Дашборд — аналітика доставки та відкриттів (Amplitude або Mixpanel)
• Навчання команди — воркшоп 2 години з поясненням особливостей експлуатації

Типові помилки, яких варто уникнути

• Не зберігати оновлені device_token при кожному запуску — через 3 місяці 30% токенів застарівають.
• Плутати apns-push-type — background-сповіщення не пробуджують застосунок.
• Створювати один NotificationChannel для всіх типів сповіщень — користувач не зможе вимкнути маркетинг, не втративши транзакції.
• Завантажувати медіа в rich push по HTTP — ATS блокує запит на iOS.
• Не перевіряти deep link у таргетингу — переходи йдуть на головний екран.

Терміни та вартість

Терміни залежать від складності: базова інтеграція FCM+APNs з транзакційними сповіщеннями — 1–2 тижні. Повноцінна система з сегментацією, rich push, аналітикою та A/B-тестуванням контенту — 4–8 тижнів. Вартість розраховується індивідуально після аудиту.

Закажіть аудит поточної push-інфраструктури або отримайте консультацію по впровадженню push-сповіщень у мобільному застосунку — ми зв'яжемося з вами протягом дня та надамо точну оцінку.