Настройка системы push-уведомлений в играх

Настройка системы push-уведомлений в играх

Push-уведомления в играх работают ровно до момента, когда их становится слишком много или они приходят невпопад. После этого игрок отключает их в настройках телефона — и теряется навсегда для этого канала. Задача при настройке системы — выстроить механику так, чтобы уведомления были уместными, а не раздражающими.

Техническая база: FCM и APNs

Firebase Cloud Messaging — де-факто стандарт для мобильных игр на Android и iOS. На iOS под FCM работает APNs (Apple Push Notification service) как транспорт. Это важно: сертификаты APNs имеют срок жизни, при истечении push-уведомления на iOS тихо перестают доходить. Типичная ситуация: команда не отслеживает expiry, через год после запуска iOS-игроки перестают получать нотификации, причину находят случайно.

FCM поддерживает два типа сообщений: notification message (отображается системой автоматически, даже если приложение закрыто) и data message (обрабатывается только кодом приложения). Для игр почти всегда нужны data messages — они позволяют кастомизировать отображение, добавить кнопки действий, обновить бейдж с нужным числом.

Самые частые проблемы интеграции

Потеря токена. FCM-токен устройства меняется: при переустановке приложения, при очистке данных, иногда просто так — FCM ротирует токены. Если серверная часть не отслеживает onTokenRefresh и не обновляет токен в базе, уведомления уходят в пустоту. На Unity — FirebaseMessaging.TokenReceived событие. Обновление токена должно происходить при каждом запуске приложения, не только при регистрации.

Неправильный запрос разрешений на iOS. До iOS 12 разрешение запрашивалось автоматически. С iOS 12+ нужен явный UNUserNotificationCenter.requestAuthorization. Момент запроса критичен: запрос в момент первого открытия игры даёт ~40% согласий, запрос после того как игрок получил первую победу или награду — 60–70%. Разница только в тайминге.

Доставка при форс-квите на Android. Некоторые производители (Xiaomi, Huawei, OnePlus) агрессивно убивают фоновые процессы. FCM-уведомления через Google Play Services работают в обход этого, но если у пользователя нет GMS (Huawei HarmonyOS), нужен отдельный канал через HMS Core (Huawei Mobile Services). Для игр с аудиторией в Китае или на Huawei-устройствах это обязательно.

Проектирование уведомлений для игры

Умная система push-уведомлений строится вокруг игровых триггеров, а не по расписанию. Расписание («пришли в 19:00 всем») — худший вариант. Триггеры:

• Таймерные события: «твоё здание достроится через 5 минут» — scheduled notification, ставится локально через UNUserNotificationCenter (iOS) или AlarmManager / WorkManager (Android), без сервера. Это важно: такие уведомления не требуют серверного пуша и работают без интернета.
• Реактивные события: «друг побил твой рекорд» — серверный push через FCM.
• Retention-триггеры: «ты не заходил 2 дня, твои ресурсы заканчиваются» — scheduled server-side через Cloud Scheduler или cron.

Сегментация. FCM поддерживает Topics (подписка на категорию) и отправку по списку токенов. Для retention-кампаний правильнее использовать Firebase Cloud Functions + Firestore: функция срабатывает по расписанию, выбирает сегмент игроков по критериям из Firestore, отправляет через Admin SDK. Это масштабируется на миллионы пользователей без написания собственного бэкенда.

A/B тест текстов. Firebase A/B Testing позволяет тестировать тексты push-уведомлений напрямую из консоли. Вариант A: «Ваши ресурсы заканчиваются», вариант B: «Гоблины разграбят склад через 3 часа». Второй вариант стабильно показывает CTR в 1.5–2 раза выше на casual-аудитории.

Аналитика и оптимизация

Без метрик система пушей — чёрный ящик. Минимальный набор событий:

• push_received — уведомление доставлено (FCM delivery receipt)
• push_opened — пользователь тапнул
• push_dismissed — смахнул без открытия
• push_opt_out — отключил уведомления после получения

CTR ниже 3% для retention-пушей — сигнал пересмотреть тексты или тайминг. Оптимальное время для мобильных игр: 19:00–21:00 по локальному времени пользователя (не серверному).

Этапы работы

1. Аудит текущей интеграции — токены, разрешения, сертификаты.
2. Проектирование триггеров — карта событий, сегменты, частота.
3. Серверная часть — Cloud Functions / собственный бэкенд, шаблоны сообщений.
4. Клиентская интеграция — обработка foreground/background/terminated состояний.
5. Локальные уведомления — таймерные события без сервера.
6. Аналитика — разметка событий, дашборд.

Стоимость рассчитывается индивидуально после анализа текущей архитектуры и платформ.