Монетизація ігор: чому доходи не зростають?
Гра вийшла, DAU зростає, доходи стоять на місці. Часто монетизацію вшивають постфактум — купівлі, події, рекламу додають без системи. Переписувати після релізу дорого й довго, а спроба виправити «на льоту» ламає прогрес і б'є ретеншн. Ми проектуємо ці шари з першого дня, щоб вони приносили гроші, а не перетворювалися на технічний борг.
Чому доходи стоять на місці? (H2)
Більшість проблем монетизації — технічні: втрачені транзакції, зламані підписки, невалідні події. Наприклад, клієнт із казуальною грою на Unity втрачав 30% IAP-доходу через відсутність серверної валідації — гравці отримували товари за перехоплені receipt. Ми замінили схему — дохід виріс на 40% за перший місяць.
IAP: архітектура внутрішньоігрових покупок
Unity IAP SDK виглядає тривіально: каталог продуктів, колбек. На практиці ламається більшість проєктів — дублювання транзакцій, втрата покупок, вразливість до злому.
Клієнтська vs. серверна валідація
Базова схема з клієнтським receipt працює, поки її не розкривають. Зломщик підміняє відповідь магазину — отримує предмет безкоштовно. Правильне рішення — відправляти receipt на бекенд для верифікації через Apple App Store API або Google Play Developer API. Тільки після цього видавати товар і зберігати transaction_id. Без серверної валідації м’яка валюта або battle pass стають мішенню для replay-атак.
Типи продуктів
| Тип | Приклад | Особливості |
|---|---|---|
| Споживаний | Пачка монет, енергія | Декілька покупок, кожного разу видається |
| Неспоживаний | Вимкнення реклами, контент | Одного разу, обов’язково Restore Purchases на iOS |
| Підписка | Battle Pass, VIP | Авто-продовження, grace period, S2S-сповіщення |
Підписки — найскладніший тип. Apple і Google по-різному рахують renewal, trial та скасування. Потрібен бекенд, який обробляє Server-to-Server сповіщення (App Store Server Notifications, Google Pub/Sub). Без цього до половини підписок втрачаються.
Відновлення покупок
На iOS без IStoreController.RestoreTransactions() магазин не пропустять. На Android відновлення необов’язкове, але підвищує довіру. Unity IAP робить це одним методом — тестувати обов’язково на реальному пристрої з TestFlight.
Рекламна монетизація
У гіперкежуалі та казуалі реклама — основне джерело доходу. Ключові SDK:
- AdMob — базовий, стабільний, але eCPM нижче середнього.
- IronSource (Unity LevelPlay) — медіатор, проводить аукціон між мережами в реальному часі.
- AppLovin MAX — альтернатива, часто виграє по eCPM у США та Європі.
Практичне правило: використовуйте медіатор (IronSource або MAX) з AdMob, Meta Audience Network та парою регіональних мереж. Пряма інтеграція одного SDK дає доходу на 30-60% менше при тому ж трафіку — перевірено на 20+ проєктах. Медіатор підвищує eCPM в середньому в 1.4 раза порівняно з одиночним SDK.
Як реклама впливає на ретеншн? (H3)
Rewarded video — найщадніший формат: гравець сам вирішує дивитися ролик за винагороду. Interstitial між рівнями ріже ретеншн, якщо показувати частіше ніж раз на 3-4 переходи. Новим гравцям у перші 24 години рекламу не показуємо — це знижує Day 1 retention на 15-25%. Для одного з клієнтів ми налаштували таймінги — Day 7 виріс на 18%.
Аналітика: архітектура подій
Тут найглибше. Більшість команд підключають Firebase Analytics, розкидають logEvent() і вважають, що аналітика готова. Через місяць даних немає або вони марні — схема подій не продумана.
Як спроектувати схему подій? (H3)
- Визначте ключові питання (наприклад, де гравці застрягають у навчанні, який LTV за джерелами трафіку).
- Для кожного питання складіть набір подій з параметрами.
- Узгодьте назви з командою (єдиний неймінг).
- Встановіть ліміти: не більше 500 унікальних типів подій (Firebase), 25 параметрів на подію.
- Протестуйте pipeline на тестовому акаунті до релізу.
Приклад поганої події:
logEvent("level_complete");
Приклад хорошої події:
logEvent("level_complete", {
level_id: "world_2_level_5",
attempts: 3,
time_spent_sec: 142,
boosters_used: ["shield", "bomb"],
session_id: "abc123",
user_segment: "payer"
});
Перша говорить тільки «рівень пройдено». Друга дозволяє будувати воронки, сегментувати гравців, корелювати поведінку з доходом.
Стандартні категорії подій
Прогрес: tutorial_step_complete (окремо на кожен крок онбордингу), level_start, level_complete, level_fail, chapter_unlock.
Монетизація: iap_initiated (відкрив магазин або тапнув офер), iap_complete (з revenue), iap_fail, ad_show_request, ad_show_complete, ad_reward_claimed.
Залученість: session_start/session_end (з тривалістю), feature_used, push_notification_open.
Firebase Analytics vs. GameAnalytics vs. AppsFlyer
| Інструмент | Призначення | Обмеження |
|---|---|---|
| Firebase Analytics | Поведінкова аналітика всередині гри | 500 унікальних типів подій, 25 параметрів на подію |
| GameAnalytics | Спеціалізована під ігри: прогресія, ресурси, дизайн | Менше гнучкості в кастомі |
| AppsFlyer | Атрибуція встановлень та рекламних кампаній | Не дає внутрішньоігрових даних |
У нормальному проекті стоять усі три. Без AppsFlyer ви витрачаєте бюджет на UA наосліп — він відстежує SKAdNetwork, рахує ROI по кампаніях, інтегрується з Facebook Ads та Google UAC. Для одного клієнта AppsFlyer допоміг знизити вартість встановлення на 25% завдяки точній атрибуції.
Хмарні збереження
Гравець, який втратив прогрес при зміні пристрою, з імовірністю 70% не повернеться. Варіанти:
- Unity Cloud Save (UGS) — швидко, key-value, безкоштовно до ліміту.
- PlayFab Player Data — гнучкіше, сегментація, умовний доступ.
- Firebase Firestore — для складних даних, реалтайм-синхронізація.
Синхронізуйте тільки критичне: рівень, куплені предмети, налаштування. Важкі файли (replay, скріншоти) зберігайте окремо. Наше рішення знижує втрату прогресу до 2% користувачів.
Що входить у вартість? (H2)
Після укладення договору отримуєте:
- Аудит поточної схеми монетизації та аналітики (якщо гра жива) або проектування з нуля.
- Архітектура IAP із серверною валідацією та підтримкою підписок.
- Інтеграція медіатора реклами (IronSource/MAX) та налаштування аукціону.
- Схема аналітичних подій з підключенням Firebase + GameAnalytics + AppsFlyer.
- Хмарні збереження та відновлення покупок.
- Документація по подіях, інструкція для геймдизайнерів.
- 2 тижні безкоштовної підтримки після релізу.
Додатково — доступ до дашбордів, навчання команди роботі з аналітикою.
Чому варто працювати з нами?
7+ років налаштовуємо монетизацію в мобільних іграх. 30+ проєктів — від гіперкежуалу до MMORPG. Стандарт подій, який ми розробили, збільшив конверсію в платіж на 20% у одного клієнта за місяць. Інший отримав зростання LTV на 35% після таргетованих оферів — це принесло додаткові $12 000 щомісяця. Гарантуємо прозорість даних: ви бачите, які події йдуть і скільки приносять. Сертифіковані партнери Unity, 5+ років на ринку.
Терміни орієнтовно
- IAP + серверна валідація: від 5 до 10 робочих днів.
- Рекламна монетизація з медіатором: від 3 до 7 днів.
- Повний цикл (аналітика + IAP + реклама): від 2 до 4 тижнів.
Вартість розраховується індивідуально — замовте безкоштовну оцінку проекту через форму зворотного зв’язку.
Типові помилки (без заголовка, як абзац)
Відсутність серверної валідації робить систему вразливою до злому. Події без параметрів — 50% часу аналітики витрачається на розшифровку. Запуск реклами в перші 24 години вбиває ретеншн: 80% гравців не повертаються. Пряма інтеграція одного рекламного SDK втрачає 30-60% доходу. Усі ці помилки ми виправляємо в межах одного проекту.
Зв’яжіться з нами — розберемо ваш проект і запропонуємо план. Напишіть нам, і ми підготуємо розрахунок за 1-2 дні. Отримайте консультацію вже сьогодні.