Акційні пропозиції в мобільній грі: де ламається механіка
Механіка офферів — це ланцюжок із чотирьох ланок: сервер вирішує, кому і коли показати пропозицію, клієнт відмальовує її в потрібний момент, платіжний шлюз підтверджує покупку, а бекенд нараховує товар і закриває оффер.
Розрив будь-якої ланки не виглядає як помилка в логах — він виглядає як незадоволений гравець, який або не побачив акцію, або заплатив двічі, або втратив прогрес покупки на середині.
Найчастіша помилка — невірні умови показу. Оффер прив'язаний до тригера (рівень, сесія, відсутність покупок N днів), але перевірка умов живе на клієнті, а не на сервері.
Гравець переводить годинник на пристрої, перевстановлює застосунок або заходить з іншого акаунта — і отримує пропозицію, яка йому не належить, або втрачає те, що вже було показано.
Лікується це серверним розрахунком eligibility та ідемпотентним ключем оффера: один гравець — один показ на кампанію, незалежно від пристрою.
Друга категорія — помилки нарахування покупок. Платіжний шлюз відповідає повільно, клієнт повторює запит, а обробник на бекенді не перевіряє унікальність транзакції. Підсумок — подвійне нарахування, яке спливає лише на звірці з магазином, коли гравець уже витратив зайве.
Рішення — ідемпотентна обробка за ідентифікатором транзакції та окремий журнал нарахувань, за яким можна відновити картину.
Третій збій — втрата прогресу покупки при обриві зв'язку. Гравець оплатив, застосунок закрився, чек не дійшов до сервера. Без черги відкладених підтверджень і фонового до-надсилання чека покупка «зависає» між магазином і грою. Тут допомагає локальне сховище незавершених транзакцій і повторна валідація при наступному запуску.
Усі три збої об'єднує одне: стан оффера має жити на сервері, а не в пам'яті клієнта. Розбираємо, як це закривається на рівні архітектури і які перевірки ставляться на кожному кроці.
Як працює видача special offers: режими, перевірки, ефект
Видача special offers — це не «показати банер у потрібний момент», а транзакційна система: сервер вирішує, кому і що запропонувати, клієнт лише відображає, а факт покупки підтверджується окремо.
Якщо рішення про видачу живе на клієнті, будь-яка правка локальних даних відкриває доступ до акції, а повторне надсилання запиту призводить до подвійного списання.
Тому логіка видачі, ліміти акцій і серверна валідація покупки тримаються на бекенді, а застосунок отримує вже готовий набір офферів з ідентифікаторами.
Режими показу офферів
Режим визначає, коли гравець бачить акцію, і напряму впливає на навантаження. Push-видача за подією (вхід, завершення рівня, падіння ресурсів) дає високий відгук, але потребує черги та захисту від штормів при масовому онлайні.
Pull-видача за запитом клієнта простіша в експлуатації, але додає затримку та зайві звернення. Гібрид — базовий набір за запитом плюс точкові події — зазвичай і обирають: пікове навантаження згладжується, а акція приходить вчасно.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Push за подією | Реакція на дію гравця, обмежені в часі акції | Потрібна черга та захист від сплесків при масовому вході |
| Pull за запитом | Прості акції, рідкісні події | Затримка видачі, надлишкові звернення до сервера |
| Гібрид | Основний сценарій у проді | Складніша конфігурація та тестування пріоритетів |
Ідемпотентність і ліміти
Кожна покупка несе унікальний ключ операції: повторне надсилання того самого запиту повертає результат першої, а не створює другу транзакцію. Це закриває подвійні списання при обриві зв'язку та повторних спробах.
Ліміти акцій — скільки разів гравець може купити, загальний обсяг видачі, термін життя — перевіряються на сервері в одній транзакції з покупкою, інакше при паралельних запитах ліміт обходиться.
Перевірки перед видачею
Серверна валідація покупки перевіряє право на акцію, залишок ліміту, стан платежу та відсутність дубля — до нарахування. Помилка на будь-якому кроці відкочує транзакцію повністю, тому гравець або отримує товар, або не втрачає нічого. Такий порядок прибирає клас відмов «списали, але не нарахували», найдорожчий у підтримці.
Google Play Billing та аналогічні платіжні контури дають підтвердження чека, але не замінюють серверну валідацію: чек підтверджує оплату, а право на акцію та ліміти — лише ваш бекенд.
Етапи впровадження механіки акційних пропозицій
Впровадження офферів починається не з коду, а з аудиту монетизації: дивимося, які події гравця вже логуються, як влаштовані покупки, де втрачається конверсія між показом і оплатою.
Якщо аналітика не розрізняє джерело покупки, будь-яка акція перетворюється на стрільбу навмання — ефект не відокремити від сезонного сплеску. Тому спочатку фіксуємо точки заміру, потім проєктуємо схему видачі акцій.
- Аудит монетизації та даних. Розбираємо поточні події, воронку покупок і розрізи за сегментами гравців. На виході — карта точок, куди можна прив'язати тригери офферів без доопрацювання ядра.
- Проєктування схеми видачі. Визначаємо умови спрацювання, ліміти на гравця, термін життя пропозиції та правила пріоритету, коли в гравця збігаються кілька акцій. Схема описується декларативно, щоб змінювати параметри без релізу клієнта.
- Налаштування конфігурації та серверної частини. Оффери виносяться в керований конфіг: сегмент, товар, знижка, вікно показу. Сервер віддає пропозицію на запит клієнта, клієнт лише відображає — це знімає розсинхрон версій застосунку в гравців.
- Перевірка на тестовій групі гравців. Розкочуємо акцію на обмежений сегмент, звіряємо конверсію, частку викупу та навантаження на платіжний контур. Тестова група відокремлена від загальної популяції, тому невдала гіпотеза не псує метрики всьому продукту.
- Масштабування та моніторинг. Після підтвердженого ефекту розширюємо охоплення, ставимо алерти на аномалії: сплеск відмов оплати, просідання викупу, зростання звернень до підтримки.
- Передача конфігурації. Віддаємо команді замовника схему видачі, набір параметрів, інструкцію із запуску та зупинки акції і порядок відкату до попереднього стану.
- Супровід перших кампаній. Залишаємося на зв'язку протягом перших запусків, щоб правки умов ішли за фактом даних, а не заднім числом.
Такий порядок дає передбачуваність: кожна акція запускається і вимикається без релізу, а результат вимірюється на обмеженій групі до того, як його побачать усі гравці.
Чим серверна видача офферів відрізняється від клієнтської?
Клієнтська видача тримає логіку акції у збірці застосунку: умови, склад нагороди та момент показу зашиті в код, а нарахування відбувається на пристрої. Це дешево на старті й працює без мережі — гравець бачить special offers навіть у метро.
Плата за це — довіра до клієнта: системний час, локальне сховище й трафік перебувають під контролем гравця, тому захист від накрутки зводиться до обфускації та перевірок на стороні сервера постфактум.
Будь-яка зміна умов вимагає нового релізу й проходження перевірок у магазинах, а стара версія продовжує жити в частини аудиторії.
Серверна видача переносить рішення на бекенд: застосунок запитує набір доступних акцій, отримує підписаний ответ з ідентифікатором пропозиції та терміном дії, а нарахування підтверджує окремим викликом.
Ключове тут — синхронізація стану: сервер знає, що вже видано, що активовано і що минуло, тому повторний запит не створює другу нагороду.
Захист від накрутки будується на ідемпотентності операцій і прив'язці до акаунта, а не до пристрою, — переведення годинника або перевстановлення застосунку нічого не змінюють.
Різниця проявляється на відмовах. За клієнтської видачі розбіжність між пристроєм і бекендом виявляється, коли гравець уже отримав зайве, і розбирати інцидент доводиться за логами.
За серверної стан залишається єдиним джерелом правди: якщо відповідь не дійшла, клієнт повторить запит і отримає той самий результат.
На практиці підходи комбінують. Сервер вирішує, кому і коли показувати пропозицію, зберігає квоти та історію активацій; клієнт відповідає за відрисовку, кеш останньої відповіді та офлайн-показ. Такий гібрид дає керованість акцій без релізу і зберігає чутливість інтерфейсу за слабкого зв'язку.
Кейс: як акційні пропозиції перестали втрачати покупки
Гра із сезонними акціями та внутрішньоігровими наборами приносила помітну частку виторгу, але механіка акційних пропозицій (special offers) працювала нестабільно. Покупка підтверджувалася на клієнті, а на сервері не проводилася: гравець бачив списання, товар не надходив.
Кожен такий випадок — звернення до підтримки, ручний розбір логів і повернення, а частина гравців просто йшла, не дочекавшись відповіді.
Що було до переробки
Офер жив на стороні клієнта: таймер акції, ціна та склад набору зберігалися в застосунку й синхронізувалися з сервером «коли вийде». При обриві зв'язку в момент оплати транзакція зависала в проміжному стані, а повторна активація того самого офера створювала дубль або відмову.
Частка успішних покупок трималася на рівні близько 70%, звернення до підтримки щодо акцій ішли потоком, а повторні активації були рідкістю — гравці не довіряли механіці.
Що змінили
Перенесли стан офера на сервер: клієнт запитує актуальний набір, сервер фіксує резерв і підтверджує видачу лише після успішної транзакції. Ввели ідемпотентний ключ на кожну спробу — повторний запит при обриві зв'язку не створює другої покупки, а повертає результат першої.
Таймери та умови акції стали серверними, тому підміна часу на пристрої більше не відкриває прострочений офер.
Окремо переробили повторні активації: після покупки гравець отримує наступний крок ланцюжка оферів, а не той самий набір. Це утримало інтерес до акції та знизило частку відмов на етапі підтвердження.
Що стало
| Метрика | До | Після |
|---|---|---|
| Частка успішних покупок | ~70% | вище 96% |
| Звернення до підтримки щодо акцій | регулярний потік | знизилися кратно |
| Частка повторних активацій | низька | зросла в рази |
| Повернення та ручні розбори | часті | поодинокі |
Схему підтвердження транзакцій та ідемпотентності будували за моделлю, близькою до того, як це вирішено в Google Play Billing — серверне підтвердження покупки замість довіри клієнту. Такий підхід прибирає цілий клас відмов: завислі транзакції, дублі та «оплатив, але не отримав».
Якщо у вас акції втрачають покупки або підтримка тоне в однотипних зверненнях — опишіть задачу, повернемося з оцінкою та планом переробки механіки.
Сумніви перед стартом: доступи, відкат, сумісність
Перед стартом замовник зазвичай ставить три питання: що потрібно з нашого боку, що буде при невдалому релізі та чи не зламає це поточну гру.
По доступах до сервера достатньо тестового контуру та облікового запису з правами на викладку — продуктивні ключі та платіжні секрети залишаються у вас, ми працюємо через окремі сервісні облікові записи з обмеженим терміном дії.
План відкату фіксуємо до початку робіт: конфігурація special offers виноситься за межі збірки, тому вимкнення акції — це перемикання прапорця, а не перезбірка та повторна модерація.
Сумісність з поточною грою перевіряємо на вашій версії клієнта та серверній логіці: якщо баланс, інвентар або прогрес гравця змінюються за своїми правилами, ми підлаштовуємося під них, а не переписуємо їх.
Що якщо акція вже запущена і її потрібно терміново зупинити?
Конфігурація зберігається окремо від коду, тому зупинка — це зміна стану на стороні сервера: нові видачі припиняються одразу, вже видані нагороди залишаються у гравців. Відкат коду не потрібен, реліз у стор не потрібен.
Що якщо у нас своя команда і ми не хочемо віддавати серверну частину? Працюємо на вашому боці: передаємо специфікацію, конфігурації та тести, ваші інженери вносять зміни самі, ми підключаємося до приймання.
Що якщо гра вже в проді і є живі гравці? Розгортаємо акцію на частку трафіку, звіряємо метрики видачі і тільки потім вмикаємо на всіх.
На руки за підсумками робіт ви отримуєте:
- конфігурації акцій з описом параметрів і умов спрацювання;
- схему взаємодії клієнта, сервера та сховища нагород;
- політику відкату та порядок аварійного вимкнення;
- набір автотестів на видачу, повторну видачу та граничні умови;
- журнал подій і дашборд за метриками акції;
- документацію щодо передачі: як додати нову акцію без участі розробника.
Опишіть задачу та поточний стек — повернемося з оцінкою та планом робіт.
