Реализация уведомлений об истечении подписки в мобильном приложении

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

Почему одного push-уведомления недостаточно?

Одно уведомление — плохая стратегия. Пользователь может проигнорировать или отложить. Исследования показывают: каскад из 3-4 напоминаний повышает конверсию в продление на 30%. Используем цепочку: за 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 самостоятельно отправляет некоторые системные уведомления, но полагаться только на них нельзя — бизнес-логику напоминаний строить нужно самостоятельно.

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

App Store Server Notifications

Локальные уведомления подходят только если сервера нет совсем, или для офлайн-сценариев. UNUserNotificationCenter с UNCalendarNotificationTrigger — планируем уведомление на дату expiresDate - 3 days. Проблема: если пользователь продлил подписку через веб или другое устройство, локальное уведомление всё равно сработает. Без синхронизации с сервером это даёт ложные срабатывания.

Серверные push лучше локальных в 3–4 раза по точности доставки и гибкости настройки.

Цепочка напоминаний

Работающая схема для B2C:

• За 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 в локальное дневное время. Реализуйте логику повторной отправки с ручным триггером.

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

Пользователь с месячной подпиской и пользователь с годовой — разные ситуации. Для месячной 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 недели.

Потеря одного пользователя с годовой подпиской обходится в среднем в $300–$500, а каскад уведомлений возвращает 15–20% из них. Внедрение цепочки уведомлений увеличивает LTV на 20–30% и снижает затраты на привлечение новых пользователей на 15%.

Получить консультацию по вашему проекту — свяжитесь с нами, оценим объём работ и предложим решение. Закажите бесплатный аудит текущей системы подписок.

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 или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через 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 на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.

Как мы внедряем 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.

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