Проектування монетизації мобільної гри: IAP, реклама, підписки

Ми проектуємо систему монетизації мобільної гри, вбудовану в геймдизайн з першого коміту. Гарантуємо якість результатів та конфіденційність. Ігри, де монетизацію додавали заднім числом, легко впізнати: IAP-пропозиції з'являються без контексту, rewarded-кнопки висять на головному екрані без зв'язку з механікою, а конверсія в платника не перевищує 0.5%. Добре спроектована система — коли гравець сам шукає, де витратити гроші, тому що це вирішує його реальну ігрову проблему. У цій статті розбираємо ключові механіки та підводні камені, щоб ви не повторювали чужих помилок.

Ми маємо досвід монетизації понад 30 проектів — від гіперказуалів до хардкорних RPG. Наш підхід спирається на реальні кейси та A/B-тести, а не на шаблони. Кастомне рішення монетизації працює в 2 рази краще, ніж стандартні шаблони. Зв'яжіться з нами, щоб обговорити деталі вашого проекту.

Як вибрати модель монетизації для вашого жанру?

Перед тим як писати код, потрібно відповісти на три питання: який жанр, яка цільова аудиторія, який LTV очікується. Від відповідей залежить все.

• Free-to-Play з IAP — основна модель для казуальних та мідкор-ігор. Гра безкоштовна, дохід — через покупки всередині. Конверсія в платника: 2–5% для добре оптимізованих ігор. ARPPU — від $5 до $50+.
• Реклама (rewarded + interstitial) — добре працює в гіперказуальних та казуальних іграх з високим DAU. Rewarded дає $10–30 eCPM у хайпікових гіперкажах, interstitial — $2–8. Агресивна реклама без rewarded швидко вбиває retention.
• Підписка — зростаюча модель для ігор з регулярним контентом. Конверсія 3–8%, але retention значно вищий, ніж у разових IAP.
• Гібридна — комбінація кількох джерел. Правильна гібридна модель розподіляє аудиторію: безкоштовні гравці монетизуються через рекламу, платники — через IAP та підписку. Важно не показувати рекламу платникам — це дратує і збільшує churn. Гібридна монетизація збільшує LTV на 20–30% порівняно з чисто рекламною.

Порівняння моделей за жанром

Як спроектувати систему валют та IAP?

Створюємо IAP дизайн з урахуванням психології гравця. In-App Purchases поділяються на три типи — consumable, non-consumable та subscriptions. Неправильний вибір типу критичний: consumable не можна відновити через Restore Purchases, non-consumable — можна.

Типова помилка — занадто багато позицій. Дослідження App Store Review Guidelines показують, що оптимальна кількість IAP-пропозицій у магазині — 6–8 одночасно. Більше — когнітивне перевантаження, гірша конверсія.

Структура цінових тирів для мобільних ігор зазвичай виглядає так: starter pack, mid-range bundle, whale offer, VIP. Стартовий пакет з високою цінністю за низьку ціну — головний інструмент конверсії першого платежу.

М'яка та тверда валюта

Більшість мідкор-ігор використовують dual-currency систему:

• М'яка валюта (coins, gold) — заробляється в ігровому процесі, витрачається на базовий прогрес.
• Тверда валюта (gems, crystals) — купується за реальні гроші або заробляється через rewarded/події, витрачається на преміум-контент та прискорення.

Конвертація м'якої валюти в тверду повинна бути обмежена або відсутня — інакше втрачається сенс покупки твердої валюти. Зворотна конвертація допустима, але з невигідним курсом.

Battle Pass як стрижень монетизації

Battle Pass — сезонна механіка з двома треками нагород (безкоштовний та платний). Економічно працює так: гравець бачить привабливі нагороди на платному треку і платить авансом за очікуване отримання їх через активний геймплей.

Ключові параметри при проектуванні:

• Довжина сезону: 28–42 дні.
• Кількість рівнів: 50–100.
• Щоденний прогрес без платежів: повинен досягати 70–80 рівня за сезон при casual-активності.
• Вартість базового проходу — в нижньому ціновому сегменті, з бонусними рівнями — в середньому.

Rewarded реклама в ігровому контексті

Rewarded працює тільки там, де пропозиція органічно вписується в потребу. "Подивись рекламу, отримай 10 монет" на головному екрані — погано. "Тобі не вистачає 1 життя, хочеш продовжити безкоштовно?" в момент поразки — конверсія 30–50%. Rewarded-покази в момент поразки дають конверсію в 5 разів вищу, ніж пропозиція на головному екрані.

Placement точки, які працюють:

• Продовження після поразки (continue button).
• Подвоєння нагород за рівень.
• Відкриття щоденної бонусної скрині.
• Прискорення таймера будівництва/відновлення.

Кожен placement — окремий rewarded placement ID в AdMob/IronSource. Це дозволяє бачити в аналітиці, які пропозиції конвертуються, а які ігнорують.

Античит та верифікація транзакцій

Клієнтська видача нагород за IAP та rewarded — вразливість. Мінімальний набір захисту:

• Rewarded SSV — IronSource/AdMob роблять callback на ваш endpoint з ECDSA-підписом.
• IAP верифікація: Receipt validation через Apple Receipt Validation API або Google Play Developer API. Клієнт відправляє receipt на ваш backend, backend верифікує у Apple/Google, тільки потім видає товар. Це блокує replay-атаки з перехопленими receipts.
• Rate limiting: обмеження кількості rewarded на добу на рівні сервера, не тільки на клієнті. Клієнтський ліміт обходиться за 5 хвилин через Frida або просто скиданням SharedPreferences.

Чому важливий античит?

Злом монетизації може знизити дохід на 30–50%. Помилка у верифікації перетворює IAP на безкоштовний контент. При правильному підході можна заощадити до 50% бюджету на залучення користувачів, не втрачаючи дохід від платників.

Аналітика монетизації

Метрики, без яких не можна оптимізувати монетизацію:

• ARPU (average revenue per user) = загальний дохід / MAU.
• ARPPU (average revenue per paying user) = дохід від платників / кількість платників.
• Conversion rate = платники / всі користувачі.
• LTV (lifetime value) — когорт-аналіз за 7/14/30/90 днів.
• ROAS (return on ad spend) — якщо є UA-кампанії.

Порівняння метрик монетизації

Реалізуємо через Firebase Analytics (logEvent("purchase", ...)) + експорт у BigQuery для когортного аналізу. Impression-level revenue з AdMob/IronSource додаємо в ту ж аналітику для повної картини LTV.

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

Ми надаємо повний пакет документації:

• GDD з монетизації з описом моделей, валют, IAP-каталогу.
• Технічні специфікації для клієнтської та серверної реалізації.
• Сценарії A/B-тестів для ключових гіпотез.
• Інтеграція з аналітикою (Firebase, BigQuery) та налаштування подій.
• Рекомендації з античиту та безпеки.
• Підтримка на етапі запуску та перші 2 тижні після релізу.

Отримайте детальну пропозицію, що відповідає специфіці вашого проекту. Зв'яжіться з нами для консультації.

Етапи проектування

1. Аналіз жанру та конкурентів — вивчаємо топ-10 схожих ігор у сторі, їх IAP-каталог, відгуки користувачів про монетизацію.
2. Вибір моделі — на основі жанру, аудиторії, каналів залучення.
3. Проектування валютної системи — типи валют, джерела, стоки, коефіцієнти.
4. Каталог IAP — тири цін, пакети, стартові пропозиції.
5. Rewarded placements — точки інтеграції, механіка пропозицій.
6. Технічні вимоги — що реалізовувати на клієнті, що на сервері.
7. План A/B-тестів — які гіпотези перевіряємо в першу чергу.

Терміни проектування: 2–3 дні для базової моделі, 5–7 днів для комплексної системи з детальним GDD з монетизації та технічними специфікаціями. Вартість проектування: від $500 для базової моделі, від $2000 для комплексної системи. Оцінимо ваш проект безкоштовно. Замовте проектування монетизації вашої гри, і ми підготуємо рішення під ваш жанр та аудиторію.

In-App Purchase документація Apple та Play Billing бібліотека Google.

Монетизація мобільних додатків: IAP, підписки та рекламна медіація

Додаток з погано реалізованими покупками втрачає гроші не тому що користувачі не хочуть платити, а тому що StoreKit транзакція зависає, Receipt Validation падає з помилкою або restore purchases не працює — і користувач пише в підтримку або залишає 1 зірку. Наш досвід (більше 7 років у мобільній розробці) показує, що грамотна монетизація збільшує LTV на 30–60% вже в перші три місяці після впровадження. Отримайте консультацію з монетизації вашого додатка — проаналізуємо поточну модель і знайдемо точки зростання.

Чому StoreKit 2 — найкращий вибір для IAP?

StoreKit 2 (iOS 15+) — сучасний API з async/await та верифікованими транзакціями на стороні пристрою без сервера. Transaction.currentEntitlements повертає всі активні покупки. Ключова зміна порівняно з StoreKit 1: верифікація JWS-підпису на пристрої через VerificationResult<Transaction> — не потрібно надсилати receipt на сервер для базової перевірки.

Але сервер-сайд валідація все одно потрібна для consumable покупок та проти fraud. App Store Server API замінює старий /verifyReceipt endpoint. Вебхуки через App Store Server Notifications v2 дають real-time події: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — без поллінгу.

Типова помилка: не обробляють paymentQueue(_:updatedTransactions:) у фоні для незавершених транзакцій. Користувач купив consumable, додаток впав до finishTransaction — покупка висить у черзі, при наступному запуску відновлюється та вимагає повторної обробки на сервері. Без ідемпотентності сервера — подвійне нарахування.

Як не втратити дохід на підписках?

Підписочна модель вимагає відстеження станів: тріал → активна → grace period → expired → refunded. RevenueCat — фактичний стандарт для керування підписками в продакшні. Абстрагує StoreKit та Google Play Billing, дає unified API, webhooks, аналітику когорт та A/B тести paywall.

Альтернатива RevenueCat — власна реалізація з Adapty або Qonversion. Повністю кастомна — тільки якщо дані не повинні залишати інфраструктуру або є нестандартна логіка. Ми гарантуємо, що налаштування webhooks та обробка подій життя підписки виконується без втрат — перевірено на проектах з аудиторією понад 500 тис. DAU.

Google Play Billing Library 6+ вимагає обробки PurchasesUpdatedListener та явного виклику acknowledgePurchase() або consumePurchase() протягом 3 днів — інакше Google автоматично скасовує покупку та повертає гроші. Середня вартість такої помилки — втрата значної суми на користувача на місяць (за даними наших проектів).

Рекламна медіація: підвищення CPM через bidding

Показувати рекламу через одне джерело — означає втрачати дохід. Медіація (waterfall або bidding) запитує рекламу у декількох мереж і показує найкращу ставку. Google AdMob — основа для banner, interstitial, rewarded. Медіація через AdMob Mediation або MAX (AppLovin) — другий де-факто стандарт. MAX використовує In-App Bidding — real-time аукціон без водоспаду. На практиці MAX дає CPM на 15-30% вище класичного waterfall (залежить від гео та аудиторії). У США для rewarded відео CPM може перевищувати певну суму. При 100 000 показів rewarded відео на день перехід з waterfall на In-App Bidding може приносити додатково значну суму щоденно.

ironSource (Unity Ads) — сильна позиція в ігровому сегменті, особливо rewarded video. Mintegral — добре закриває азійську аудиторію.

Налаштування медіації вимагає ATT (App Tracking Transparency) на iOS 14+. Без requestTrackingAuthorization рекламний CPM падає в 3-5 разів для користувачів, які не погодилися. SKAdNetwork та Privacy Manifest (iOS 17) — обов'язкові вимоги, без яких рев'ю падає.

Як вибрати рекламні мережі для медіації?

Як ми впроваджуємо монетизацію: покроковий процес

1. Аудит поточної моделі — аналіз воронки, paywall, цінових тирів та виявлення вузьких місць.
2. Проектування моделі — вибір типу (subscription, consumable, non-consumable) та оптимізація цінових точок.
3. Інтеграція IAP — налаштування StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
4. Рекламна медіація — підключення 3-6 мереж, налаштування waterfall або In-App Bidding, тестування fill rate.
5. Аналітика та когорти — інтеграція RevenueCat, Amplitude або Firebase для відстеження LTV.
6. A/B тестування paywall — використання Remote Config для експериментів без релізу.
7. Запуск та моніторинг — 2 тижні безкоштовної підтримки після запуску, фікс багів по SLA 24 години.

Freemium: проектування моделі та paywall

Freemium працює коли межа між безкоштовним та платним проведена правильно. Занадто жорсткий paywall на старті — користувач видаляє. Занадто щедрий безкоштовний тир — немає стимулу платити.

Як проєктувати paywall для freemium?

Паттерн, який працює технічно: feature flags з сервера (Remote Config у Firebase або LaunchDarkly) керують доступом до фіч. Це дозволяє A/B тестувати paywall без релізу, змінювати умови тріалу, проводити акції.

Реалізація на рівні коду: EntitlementManager — єдина точка перевірки доступу до фіч, яка знає про статус підписки, флаги та промо. Жодних перевірок isPremium розкиданих по всьому коду. Досвід показує: такий підхід знижує кількість багів з paywall на 80% (підтверджено на 30+ проектах).

Обсяг робіт з монетизації

• Аудит поточної моделі — аналіз воронки, paywall, цінових тирів.
• Інтеграція IAP — StoreKit 2 / Google Billing 6, receipt-валідація, webhooks.
• Рекламна медіація — налаштування MAX / AdMob, підключення 3-6 мереж, тестування fill rate.
• Налаштування аналітики — RevenueCat, Amplitude / Firebase, когортний аналіз.
• Документація — опис ентайтлментів, процедура відновлення, чек-лист рев'ю.
• Навчання команди — розбір типових помилок, рекомендації з підтримки.
• Гарантія — безкоштовна підтримка 2 тижні після запуску, фікс багів по SLA 24 години.

Терміни орієнтовно

Вартість розраховується індивідуально. Ми працюємо в цій сфері більше 8 років і реалізували більше 40 проектів з монетизацією — багато з них пройшли App Store Review без жодного блокування. Зв'яжіться з нами для аудиту або замовте консультацію — розповімо, які точки зростання є у вашому додатку.

Джерела: Apple StoreKit 2 Documentation, RevenueCat Best Practices, Wikipedia: Freemium.