При запуску мобільного додатку з підписками типова ситуація: платіж не пройшов, користувач навіть не помітив, додаток мовчить. Іде до 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 | Локальні сповіщення |
|---|---|---|
| Точність | Висока | Низька (хибні спрацьовування) |
| Залежність від сервера | Обов'язкова | Не потрібна |
| Підтримка deeplink | Так | Так |
| Гнучкість ланцюжка | Максимальна | Обмежена |
| Канал | APNs / FCM | UNUserNotificationCenter |
Серверні 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 маршрутизуємо.
Деталі реалізації на Android (FCM)
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, нормально. Мобільні підписки потребують особливої уваги до таймінгу сповіщень.
| Тип підписки | Вікно нагадування | Агресивність |
|---|---|---|
| Місячна | 3-5 днів | Висока |
| Річна | 7-14 днів | Низька |
| Тижнева | 1-2 дні | Середня |
Часовий пояс користувача критичний: push о 3 ночі — роздратування та відписка. Firebase FCM дозволяє задавати delivery_time з урахуванням локального часу пристрою. Для APNs це робиться на рівні сервера через планувальник завдань з урахуванням timezone користувача.
Процес роботи
- Аудит поточної системи підписок: StoreKit / серверні / гібрид.
- Налаштування App Store Server Notifications V2 або серверних вебхуків для тригерів завершення.
- Реалізація ланцюжка push-сповіщень з deeplink на потрібний екран.
- Тестування на sandbox-середовищі StoreKit та бойовою перевіркою FCM.
- Моніторинг та коригування таймінгів на основі аналітики.
Що входить у роботу
- Налаштування 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.
Отримати консультацію щодо вашого проєкту — зв'яжіться з нами, оцінимо обсяг робіт та запропонуємо рішення. Замовте безкоштовний аудит поточної системи підписок.