Налаштування системи 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. Аналітика — розмітка істей, дашборд

Вартість розраховується індивідуально після аналізу поточної архітектури та платформ.