Реалізація механіки Battle Pass у мобільній грі

Ми розробляємо механіку Battle Pass як один із найбільш технічно об'ємних елементів монетизації. В одному з проєктів по мобільній RPG з 500 тис. DAU ми впровадили Battle Pass з п'ятирівневою прогресією. Перша версія призвела до того, що 30% гравців пройшли його за перший тиждень, що вимагало перерахунку XP кривої. На основі цього досвіду ми виробили архітектуру, яка повторно використовується та масштабується.

Наша реалізація охоплює не просто список нагород — це сезонна система з прогресією, двома треками, таймером, покупкою через IAP та синхронізацією прогресу між пристроями. Ми гарантуємо стабільну роботу навіть при високих навантаженнях та надаємо повну документацію.

Як збалансувати прогресію Battle Pass?

Одне з ключових питань — вибір між flat та scaling XP. Flat XP простіше реалізувати, але створює ситуацію, коли хардкор-гравець проходить весь Battle Pass за перший тиждень і втрачає мотивацію платити. Scaling XP утримує інтерес, але може стати занадто агресивним.

Добре працює linear scaling with plateau: перші 20 рівнів дешево, рівні 21–80 рівномірно зростають, 81–100 — фіксована висока вартість для «перфекціоністів». Casual-гравець без покупки skip-levels доходить до 70–75 рівня до кінця сезону — це правильний баланс. Таблицю XP проєктуємо в spreadsheet: задаємо очікувану кількість XP за різні активності (проходження рівня, дейлі-квест, івент) і рахуємо, скільки днів потрібно casual-гравцю для проходження кожного рівня Battle Pass.

Архітектура даних

Модель Battle Pass на сервері включає мінімум три сутності:

Season — поточний сезон з датами start/end, список рівнів (50–100) з нагородами для free- та premium-треку.

PlayerSeasonProgress — прогрес конкретного гравця: поточний рівень, накопичений XP, прапорець isPremium, список claimedRewards.

SeasonXPTransaction — лог нарахувань XP: джерело (level_complete, daily_quest, mission), кількість, timestamp. Потрібен для аудиту та anti-cheat.

struct BattlePassLevel: Codable {
    let level: Int
    let xpRequired: Int
    let freeReward: Reward?
    let premiumReward: Reward?
}

struct PlayerSeasonProgress: Codable {
    let seasonId: String
    let currentLevel: Int
    let currentXP: Int
    let isPremium: Bool
    let claimedRewards: [String] // "level_\(n)_free", "level_\(n)_premium"
}

Як інтегрувати IAP для Battle Pass?

Battle Pass продається як non-consumable або auto-renewable subscription — залежно від моделі:

• Разова покупка на сезон (non-consumable) — простіше для гравця, легше реалізувати
• Підписка з авторенью — стабільний дохід, але вимагає грамотного управління через StoreKit 2 (iOS) або Google Play Billing Library 6+

Згідно з документацією StoreKit 2, валідація транзакції на сервері обов'язкова для premium-контенту. Клієнт передає transactionId, сервер верифікує через App Store Server API або Google Play Developer API.

На iOS з StoreKit 2:

let products = try await Product.products(for: ["battle_pass_season_1"])
guard let battlePass = products.first else { return }
let result = try await battlePass.purchase()
switch result {
case .success(let verification):
    let transaction = try verification.payloadValue
    await transaction.finish()
    await unlockPremiumTrack(for: transaction.id)
case .pending:
    break
case .userCancelled:
    break
}

Механіка Battle Pass описана в Wikipedia, але наша реалізація включає ряд додаткових фіч.

Коли використовувати підписку замість разової покупки?

Разова покупка на сезон підходить для класичної моделі. Підписка з авторенью збільшує LTV в 2 рази порівняно з разовою покупкою, але вимагає ретельної реалізації: необхідно грамотно обробляти скасування, поновлення та повернення. Наш досвід показує, що підписка дає більш передбачуваний дохід.

Skip Levels та Gifting

Skip levels (пропуск рівнів за тверду валюту) — додаткове джерело доходу. Зазвичай 1 рівень = 100–150 gems, пакет з 10 рівнів з невеликою знижкою. Технічно: consumable IAP або списання gems з гаманця з серверною верифікацією.

Подарувати Battle Pass другу — фіча, яку запитують часто, але реалізують рідко. Вимагає підтримки Gift Purchase від платформи: iOS підтримує через StoreKit, Android — частково через Google Play Gifting API (в beta з 2023).

UI Battle Pass

Стандартний UI — горизонтальний скрол з рівнями, поточний рівень по центру, нагороди вище/нижче для free/premium треків. Кнопка «Отримати» активна тільки для зароблених та не отриманих нагород.

Ключові UI-стани для кожного рівня:

• Locked (ще не досягнуто)
• Earned, not claimed (досягнуто, нагорода не забрана)
• Claimed (забрана)
• Premium locked (тільки для premium, гравець не купив)

Анімація отримання нагороди — повноекранна, з партиклами. Це retention-момент: гравець повинен відчувати задоволення від прогресу.

Сезонний таймер та закінчення сезону

Таймер зворотного відліку нагнітає urgency. Відображається в головному меню та на екрані Battle Pass. За 3 дні до кінця — push-повідомлення: «До кінця сезону 3 дні, тобі залишилося X рівнів».

Після закінчення сезону: прогрес архівується, не отримані нагороди згоряють (з попередженням за 7 днів), запускається наступний сезон автоматично. Дані попередніх сезонів зберігаємо для історії в профілі.

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

В процесі реалізації ми надаємо:

• Повну серверну документацію по API
• Код клієнтської інтеграції на Swift та Kotlin
• Інструкцію з налаштування IAP в консолях App Store та Google Play
• 30-денну підтримку після релізу

Строки та етапи

Базова реалізація (без підписки, без skip levels) — 5 днів. Повна система з підпискою, skip levels, gifting та аналітикою — 2–3 тижні. Ми гарантуємо дотримання строків та прозору звітність.

Зв'яжіться з нами для обговорення вашого проєкту — ми допоможемо реалізувати Battle Pass, який утримає гравців та збільшить дохід.

Монетизація мобільних додатків: 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.