Які проблеми вирішують акційні пропозиції?
Гравці отримують сотні пропозицій — більшість ігнорують. Основний біль: показувати знижку 20% усім — означає втрачати гроші. Ми вирішуємо це через сегментацію та тригери. Наприклад, для гравця, що застряг на рівні 15, показуємо бустер саме для цього рівня. Конверсія такого оффера до 30%. A/B-тест одного клієнта показав, що таргетований оффер на 3-й день збільшив першу покупку в 4 рази.
Перша проблема — спалювання знижок на нецільових користувачів. Гравець, який і так купить, отримує 70% знижку — ви втрачаєте маржу. Друга — пропущені можливості: користувач, що йде, без winback-оффера йде назавжди. Третя — слабка аналітика: незрозуміло, який оффер спрацював. Система Special Offers вирішує всі три: сегментує аудиторію, показує оффер у потрібний момент і збирає метрики. Типова економія від її впровадження становить $5,000 на місяць на проекті зі 100 000 MAU.
Реалізація акційних пропозицій: серверна конфігурація
Усі оффери зберігаються на сервері. Клієнт при вході або відкритті магазину запитує активні оффери. Сервер перевіряє triggerConditions і повертає лише відповідні. Приклад конфігурації:
{ "offerId": "starter_pack_d3", "title": "Стартовий набір", "products": [ {"type": "gems", "amount": 500}, {"type": "chest", "itemId": "epic_chest", "amount": 3}, {"type": "resource", "itemId": "gold", "amount": 10000} ], "iapProductId": "com.mygame.starter_pack_d3", "originalPrice": 9.99, "discountPercent": 70, "validUntil": "2099-12-31T23:59:59Z", "triggerConditions": { "daysSinceInstall": {"min": 2, "max": 4}, "hasNeverPurchased": true, "minLevel": 5 }, "maxPurchases": 1 } Як налаштувати тригери показу?
Оффер не просто висить у магазині — він спливає в контексті.
Contextual trigger. Гравець програв рівень 3 рази поспіль — показуємо оффер з бустером саме для цього рівня. Сервер знає поточний рівень і кількість спроб.
Time trigger. День 3 після встановлення — найкращий момент для starter pack: гравець уже зрозумів механіку і готовий витратити перший долар.
Re-engagement trigger. Гравець не заходив 5 днів — при поверненні показуємо winback оффер. Реалізується через push-повідомлення з deeplink на екран оффера.
Achievement trigger. Гравець щойно пройшов складний рівень або відкрив новий контент — емоційний пік, найкращий час для пропозиції.
Чому серверна конфігурація критична?
Клієнтська логіка вразлива: зломщики можуть підмінити умови та отримати знижку без тригера. Серверна перевірка triggerConditions перед покупкою — єдиний спосіб гарантувати, що оффер показаний лише цільовому сегменту. Це ж вирішує проблему синхронізації: якщо термін оффера минув, клієнт не зможе його купити, навіть якщо не отримав оновлення. Економія від такого підходу — до 70% на знижкових акціях за рахунок виключення false-positive покупок.
Порівняння серверної та клієнтської конфігурації
| Критерій | Серверна конфігурація | Клієнтська конфігурація |
|---|---|---|
| Контроль тригерів | Так, на сервері | Ні, вразлива для злому |
| Синхронізація завершення | Автоматична | Вимагає оновлення клієнта |
| Гнучкість оновлення | Без публікації в магазин | Через апдейт застосунку |
| Безпека | Висока | Низька |
Як реалізувати Special Offer крок за кроком?
- Сегментація аудиторії. Визначте критерії: кількість днів з встановлення, рівень, історія покупок.
- Створення оффера. Опишіть склад, знижку та IAP-продукт на сервері.
- Налаштування тригерів. Задайте умови показу: contextual, time, re-engagement, achievement.
- Розробка UI. Реалізуйте спливаюче вікно з таймером та анімацією.
- Інтеграція аналітики. Відстежуйте покази, кліки та покупки.
- Запуск A/B-тесту. Перевірте кілька варіантів та оберіть найкращий.
Як налаштувати таймер та терміновість?
Таймер на клієнті оновлюється кожну секунду, але завершення перевіряється на сервері при кліку «Купити». Це виключає покупку простроченого оффера.
struct OfferTimerView: View { let expiresAt: Date @State private var timeRemaining: String = "" let timer = Timer.publish(every: 1, on: .main, in: .common).autoconnect() var body: some View { Text("Залишилось: \(timeRemaining)") .onReceive(timer) { _ in let remaining = expiresAt.timeIntervalSinceNow if remaining > 0 { timeRemaining = formatDuration(remaining) } else { NotificationCenter.default.post(name: .offerExpired, object: nil) } } } } Стартовий набір з таймером конвертує в середньому в 2-3 рази краще, ніж аналогічний без таймера.
A/B-тестування офферів
Firebase Remote Config дозволяє тестувати різні варіанти. Група A: 500 гемів + 3 скрині; група B: 300 гемів + 5 скринь + 1 скін. Метрика — conversion rate (купили / побачили). Тест на 1000+ гравців на групу, статистична значущість >95%. Для персоналізації використовуємо власну recommendation-систему.
Порівняння типів офферів — реалізація акційних пропозицій
| Тип оффера | Мета | Приклад | Типова конверсія |
|---|---|---|---|
| Starter pack | Перша покупка | 500 гемів за 50% знижки | 15–25% |
| Winback | Повернення тих, хто пішов | 70% знижка на популярний предмет | 8–12% |
| Flash sale | Терміновість | Знижка 40% на 24 години | 20–30% |
| Contextual | Вирішення проблеми | Бустер для поточного рівня | 25–35% |
Система Special Offers підвищує конверсію в середньому в 2-3 рази порівняно з показом однакових пропозицій усім гравцям. Типова додаткова виручка від використання Special Offers — $2,000 на місяць на проект.
Інтеграція з IAP
Кожен Special Offer — окремий продукт в App Store / Google Play з унікальним productId. Apple надає Promotional Offers для знижки на підписки та Introductory Offers для нових підписників. Це вбудовані механізми, які не потребують окремих product ID.
Технічні деталі безпеки: offer validation — перевірка підпису receipt на сервері; rate limiting — не більше 3 запитів на оффер за хвилину; серверна фіксація перевірок для аудиту.
Що входить у нашу роботу
- Аналітика: сегментація гравців, підбір тригерів
- Проектування: структура офферів та серверна схема
- Реалізація: серверна конфігурація, клієнтський UI, інтеграція з IAP
- A/B-тестування: налаштування Remote Config, аналіз результатів
- Документація: опис логіки та налаштування аналітики
- Підтримка: допомога при запуску та моніторинг
Наша команда має 7+ років досвіду в мобільній розробці та реалізувала понад 30 проектів з IAP-системами.
Терміни: базова система — від 2 до 3 днів, повна — від 1 до 1.5 тижнів. Вартість розраховується індивідуально. Замовте впровадження Special Offers сьогодні. Зв'яжіться з нами для консультації та оцінки вашого проекту. Отримайте консультацію з впровадження Special Offers у вашу гру.