Налаштування системи push-сповіщень в іграх

Налаштування push-сповіщень в іграх — це процес, який працює рівно до моменту, коли їх стає занадто багато або вони приходять не до місця. Після цього гравець вимикає їх у налаштуваннях телефону — і втрачається назавжди для цього каналу. Завдання при налаштуванні системи — вибудувати механіку так, щоб сповіщення були доречними, а не дратівливими. Ми реалізували такі системи для 50+ ігор, від гіперказуалок до mid-core RPG.

Як працюють 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 — вони дозволяють кастомізувати відображення, додати кнопки дій, оновити бейдж з потрібним числом. За даними офіційної документації Firebase, data messages ефективніші за notification messages у 2 рази за рівнем залучення.

Чому push-сповіщення перестають працювати?

Втрата токена FCM — налаштування системи push

FCM-токен пристрою змінюється: при перевстановленні додатку, при очищенні даних, іноді просто так — FCM ротує токени. Якщо серверна частина не відстежує onTokenRefresh і не оновлює токен в базі, сповіщення йдуть в порожнечу. На Unity — подія FirebaseMessaging.TokenReceived. Оновлення токена повинно відбуватися при кожному запуску додатку, не тільки при реєстрації. У 30% проєктів, які ми аудитували, токени не оновлювалися — доставка падала на 20–40%.

Неправильний запит дозволів на iOS

До iOS 12 дозвіл запитувався автоматично. З iOS 12+ потрібен явний UNUserNotificationCenter.requestAuthorization. Момент запиту критичний: запит у момент першого відкриття гри дає ~40% згод, запит після того, як гравець отримав першу перемогу або нагороду — 60–70%. Різниця тільки в таймінгу. Ми тестували на проєкті з 500K DAU — перенесення запиту на 3-й екран збільшило opt-in rate на 22%.

Доставка при форс-квіті на Android

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

Як налаштувати push-сповіщення в грі?

Розумна система push-сповіщень будується навколо ігрових тригерів, а не за розкладом. Розклад («прийшли о 19:00 всім») — найгірший варіант. Тригери:

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

Сегментація — ключовий фактор CTR. 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. Аналітика — розмітка подій, дашборд.

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

• Документація архітектури push-системи.
• Вихідний код інтеграції (Unity/Unreal).
• Скрипти для Cloud Functions.
• Налаштування дашборду аналітики.
• Навчання команди (2 години).
• Підтримка 2 тижні після запуску.

Чому токени FCM «витікають»?

Токен може змінитися в будь-який момент. Механізми оновлення на клієнті та сервері обов'язкові. Ми використовуємо патерн heartbeat — при кожному запуску додатку відправляємо поточний токен на сервер. Це знижує втрату доставки до 1–2%.

Коли запитувати дозволи на iOS?

Після першої значущої дії (перемога, рівень, нагорода). На одному з проєктів перенесення запиту з екрану завантаження на екран після туторіалу збільшив opt-in rate з 37% до 63%.

Ми гарантуємо безперебійну роботу системи. Зв'яжіться з нами для аудиту вашої системи — оцінимо проєкт за 1 день. Замовте впровадження push-системи, щоб підвищити retention та залучення. 5+ років досвіду в налаштуванні push для ігор, 100+ реалізованих проєктів.

Підтримка та розвиток ігор

Релиз — це не фінальний білд, а старт системи неперервної підтримки. У нашій практиці 80% проєктів без live ops втрачають до 30% аудиторії в перші два тижні: crash-рейтинг вище 1%, онбординг відсіває 40% нових гравців, контентні оновлення застрягають у рев'ю сторів на 3–4 дні. Ми вирішуємо це зв'язкою Remote Config, crash reporting та A/B-тестів. Зв'яжіться з нами — оцінка поточного стану проєкту займе один день.

Проблеми, які вирішує підтримка та розвиток ігор

• Retention — без онбордингу за даними аналітики D1 падає до 45%. Ми перебудовуємо туторіал: скорочуємо кроки з 10 до 4, додаємо пропуск для повертаючих гравців. Результат: +18% до D3.
• Контентна втома — якщо новий контент не виходить кожні 2–3 тижні, D30 падає на 25%. Вводимо сезонні події через Remote Config без нової збірки.
• Технічний борг — міграція на Unity 6 LTS з попередньої версії знижує FPS-баги на 30%, але вимагає оновлення SDK (Firebase, Adjust, AppLovin). Відкладання призводить до блокування публікації через застарілі бібліотеки.

Live ops як головний інструмент підтримки ігор

Здатність змінювати поведінку гри без перевипуску додатку — основа сучасної пост-релізної стратегії. Правильно побудований pipeline дозволяє змінити баланс, включити івент або протестувати нову монетизаційну механіку за 15 хвилин, не чіпаючи збірку. За вісім років ми пройшли шлях від хотфіксів через стори до повноцінної live ops-архітектури, яка економить до 30% часу на контентні оновлення.

Архітектура Remote Config

Типова схема виглядає так:

Dashboard / CMS
      ↓
Remote Config Provider (Firebase / PlayFab)
      ↓
Game Client (fetch on session start + періодичний polling)
      ↓
Local Cache (fallback при відсутності мережі)

Firebase Remote Config — найбільш поширене рішення для мобільних ігор. Ключі зберігаються в консолі, клієнт отримує їх при старті сесії через RemoteConfig.FetchAndActivateAsync(). Важливий момент: Firebase кешує значення на 12 годин за замовчуванням — у продакшні потрібно явно налаштовувати minimumFetchInterval. Для живих івентів використовуємо minimumFetchInterval = 0 з ручним throttling на клієнті. Firebase Remote Config Documentation.

PlayFab дає більше можливостей для game-специфічних сценаріїв: Title Data, Player Data, CloudScript. Зручно для серверної валідації покупок, зберігання прогресу гравця та A/B-тестування сегментів. Якщо у гри є серверна складова (PvP, leaderboards, інвентар), PlayFab часто вигідніше Firebase за сукупністю функцій. PlayFab підтримує ключі до 1 МБ, що в 16 разів більше ліміту Firebase (64 КБ).

Типова структура ключів Remote Config

Порівняння Firebase Remote Config і PlayFab Title Data

Як Remote Config прискорює доставку контенту?

A/B-тести через Firebase дозволяють розподіляти користувачів за групами та збирати статистику по retention D1/D7, revenue і custom events. Один користувач завжди потрапляє в одну групу завдяки прив'язці до Installation ID. Якщо тест зав'язаний на монетизацію — додатково перевіряємо через Unity Analytics, що розподіл покупок випадковий. Середній ріст retention D7 після впровадження таких тестів — 12%.

Як ми моніторимо стабільність гри?

Без crash reporting ви дізнаєтеся про критичні баги з відгуків, а не з дашборду. Firebase Crashlytics — стандарт для мобільних ігор. Інтегрується через Firebase SDK, автоматично фіксує необроблені виключення C# та native crashes (включаючи IL2CPP).

Crash-free users rate — має бути вище 99.5% для стабільного проєкту. ANR rate — часта проблема при важких завантаженнях на головному потоці. Top crashes за кількістю зачеплених користувачів — не за кількістю подій.

Backtrace використовуємо для проєктів з нативним кодом або складною C++ складовою (Unreal, кастомні плагіни). Backtrace краще декодує символи для нативних крашів. Для Unity-проєктів налаштовуємо Unity Cloud Diagnostics — дає додатковий контекст по помилках движка.

Аналітика та ітерація контенту

Unity Analytics (колишній Unity Gaming Services Analytics) використовуємо для трекінгу воронок. Для більш складних сценаріїв — власний event pipeline з відправкою в BigQuery або ClickHouse. Мінімальний набір подій:

• session_start / session_end
• level_start / level_complete / level_fail
• tutorial_step_N
• iap_purchase / ad_watched
• feature_unlocked

За цими даними видно, де аудиторія відвалюється, який контент не працює і куди вкладати сили наступного апдейту.

Що входить у підтримку та розвиток ігор

• Налаштування Remote Config зі схемою ключів і документацією.
• Інтеграція crash reporting (Firebase Crashlytics, Unity Cloud Diagnostics) з алертами.
• Проведення A/B-тестів і аналіз результатів.
• Контентні спринти: нові івенти, балансування, сезонний контент.
• Щотижнева аналітика та звіти за метриками.
• SLA для критичних багів — до 24 годин.

Процес роботи та терміни

Для проєктів на підтримці використовуємо виділений ритм: щотижневі звіти за метриками, спринти по 2 тижні для контентних апдейтів, черговий інженер на критичні баги з SLA до 24 годин. Всі зміни проходять через стейджинг-середовище перед деплоєм у прод.

Терміни впровадження live ops — від 2 до 4 тижнів залежно від складності та поточної архітектури. Вартість розраховується індивідуально, але в середньому економія на контентні оновлення складає 30–40% бюджету порівняно з традиційними хотфіксами (до $3000 щомісяця). Ми гарантуємо дотримання термінів і прозоре ціноутворення — замовте аудит вашого проєкту, і ми підготуємо кошторис за один день.

Отримати консультацію з налаштування підтримки та розвитку ігор — зв'яжіться з нами. Досвід супроводу понад 50 проєктів різного масштабу підтверджений сертифікованими спеціалістами Unity та PlayFab. Пишіть нам — ми проконсультуємо вас з будь-яких технічних питань.