Гра провалила тест через низький Retention D1: Як її врятувати і чи варто це робити

Привіт! Мене звати Ростислав Воловик, я Game Designer продуктової компанії Smart Project. Понад 4 роки я працюю у геймдеві і за цей час переконався: невдалий старт ще не означає кінець історії. У цій статті я поділюся кейсами зі свого досвіду роботи на попередніх проєктах — ще до того, як приєднався до команди Smart Project.

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

Настає тиша. Команда мовчить. Кожен переживає по-своєму. Хтось одразу лізе в цифри, хтось шукає винного в ідеї. А хтось тільки знизує плечима: «Ми ж це передбачали». І все одно боляче.

У такі моменти важливо не втратити ґрунт під ногами. Ret нижче бенчу — ще не привід ховати проєкт у шухляду. Це просто частина процесу.

Що варто зробити в перші години після провального запуску? На що подивитися в аналітиці? Як приймати рішення разом із командою, і коли краще зупинитись, аби не потрапити в пастку безкінечних ітерацій?

Це не історія про ідеальні старти. Це про реальність, у якій поганий запуск — ще не вирок.

Чесна оцінка: закрити гру, ітерація чи півот

Після провального тесту головне питання — а чи має сенс далі витрачати ресурси на гру, яка вже не показала результату? Адже кожна нова ітерація — це гроші, час і команда, яку ви не зможете залучити до інших, потенційно сильніших проєктів. І найгірше в цій ситуації — продовжувати роботу лише тому, що вже почали.

Відштовхуйтесь від документації, а не від емоцій

Перш ніж ухвалювати будь-яке рішення, поверніться до стартової документації та перевірте, чи немає помилок в закупці або аналітиці. Уточніть:

• Які бенчі були поставлені на тест?
• Які допуски ви собі дозволяли заздалегідь?
• Яка нова інформація з’явилася під час розробки чи тесту, і як вона впливає на початкові припущення або цілі?
• Чи не було помилок у трекінгу івенту або якості тестового трафіку?

Це допоможе зрозуміти не просто «погано» чи «непогано» пройшов тест, а наскільки саме ви не дотягнули до плану і чи релевантні тестові дані взагалі.

Як результати тесту впливають на рішення про те, що робити з грою далі

Кожного разу хочеться думати: «ну з цим проєктом точно буде інакше». Щоб уникати цього упередження, я для себе ввів просте правило щодо Retention D1:

Якщо до бенчу понад 10 відсоткових пунктів (далі: в.п.) — закривати, або продовжувати тільки за наявності сильних гіпотез для ітерацій чи плану на півот.

Якщо відставання до 10 в.п. і є виявлені проблеми, можна спробувати точкову ітерацію.

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

Після того як ви звірились з документацією і оцінили масштаб відхилень, залишаються три шляхи: kill, півот або ітерація.

Kill — найболючіше, але, частіше за все, правильне рішення

Закрити проєкт, перенаправити ресурси, винести уроки і рухатись далі. Це не провал — це ознака адекватної продакт-логіки. Kill часто є найоптимальнішим варіантом, особливо якщо:

• Retention D1 набагато нижчий за ціль і немає чіткого пояснення чому.
• У вас немає сильних гіпотез, як покращити ситуацію.
• Продукт не дає цінності гравцю навіть на рівні core-геймплею.

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

Півот — радикальні зміни з новим фокусом

Це не «продовження розробки», а фактично новий проєкт на старому фундаменті.

Один із кейсів — word puzzle де гравець розгадував цитати відомих людей. Ідея показала слабкий Retention у перші дні. Ми вирішили зробити півот: змінили напрямок на word-chain, переробили дизайн рівнів, спростили core-механіку, а елементи з попередньої версії зберегли на пізніших етапах воронки, щоб не втратити глибину. В результаті Retention D1 виріс на 11 в.п.

Півот — це не завжди data-driven. Часто неможливо точно довести, що саме зміна core-механіки вирішить проблему. Такий підхід більше схожий на старт нового проєкту: зі своїм набором гіпотез, ризиків і необхідністю повторного пошуку фітів. Це сильний, але ризикований інструмент. Я не радив би його початківцям, адже дуже легко обманути себе та команду в значимості цих змін.

Ітерація — контрольоване вдосконалення

Ітерація — це не «виправити все й одразу». Це точкові зміни середньої складності, спрямовані на вирішення конкретної проблеми або покращення одного з ключових KPI.

Вона доречна тоді, коли:

• Проблема чітко ідентифікована. Наприклад, слабке проходження туторіалу або значний дроп на певному рівні.
• Є гіпотеза та оптимальний обсяг роботи.
• Очікуваний ефект співвідноситься з поточним gap до бенчмарку.

З досвіду: На 5-му рівні ми зафіксували 34% дропа. Було боляче, але показник говорив сам за себе. Ми повернулись до дизайну рівня, додали підказки, спростили кілька моментів і це дало результат: D1 Retention зріс на +4 в.п.

Наступним кроком додали базову механіку прокачки персонажа після бою. Простий, але відчутний для гравця прогрес. Так Retention піднявся з 26% до 31%.

Також перезібрали FTUE. Спростили інтерфейс, скоротили туторіал утричі, рознесли пояснення на перший день геймплею — так звані «софт» туторіали. У підсумку прохідність вступного досвіду зросла з 55% до 74%. Це принесло ще +4 пункти до Ret D1.

Якщо ви вирішили вкладати ресурси в продукт після невдалого запуску, то ітерація — зазвичай найкращий вибір. Тут менше ризиків через невеликий обсяг змін і вища прогнозованість результату. Але варто розуміти, що швидкого або значного ефекту очікувати не слід. Це дрібні, поступові кроки. Іноді тільки один з них — саме той, що вам потрібен.

Але в будь-якому разі ми цілимось у відчутні зміни. Врахуйте, що на старті у вас буде мало трафіку для A/B тестів. І якщо очікуваний ефект лише 2-3 в.п., для статистичної значущості може знадобитись десятки тисяч гравців у кожній групі. Це навряд чи підйомна задача. А один A/B тест на пів року — слабка стратегія для розвитку.

Водночас, якщо проєкт не підходить ні під півот, ні під ітерацію, найкращим рішенням буде вчасно зупинитись.

Почни з команди: заспокой, якщо плануєш продовжувати

Провал тесту легко деморалізує, особливо в молодих або надто залучених командах. У цей момент важливо спокійно проговорити ситуацію, не шукати винних, озвучити план дій і підсвітити те, що вже вийшло.

Навіть проста фраза: «Так, це боляче, але це лише старт. У нас є план» повертає контроль. Якісне ретро та декілька зустрічей/брейнстормів з продуктовою командою в допомогу.

Мета — не «надихнути» порожніми обіцянками, а допомогти команді повернутися в робочий ритм. Як саме це зробити — залежить від вас. Ви краще за всіх знаєте своїх людей.

Аналіз воронки: знайти, де саме ми втрачаємо гравця

У команди завжди буде десятки ідей, що можна покращити, і різні думки, що саме «провалило» гру. Але без даних це все — стрільба навмання. Воронка ж допомагає зосередитись. Вона показує, де саме гравці відвалюються, і вже після цього можна думати — чому саме там і що з цим робити. Ось базовий набір воронок, на які я рекомендую дивитися в першу чергу:

• Воронка за плейтаймом (похвилинна)
  Показує, на якій хвилині трапляються аномальні відвали. Це хороший орієнтир, який підкаже, з чого починати: що відбувається в ці моменти, що могло спровокувати вихід?
• Воронка до core-геймплею (від app open до повного керування)
  Відображає, скільки гравців взагалі дійшло до основної механіки. Якщо багато хто не доходить — значить проблема в затягнутому вступі або невдалому туторіалі.
• Воронка за туторіалом (по кожному кроку)
  Дає змогу побачити, на яких саме кроках гравці виходять. Тутор проходять на початку воронки, тому його зрозумілість і довжина критично впливають на Retention.
• Воронка першого рівня (по ключових діях гравця)
  Показує, як гравець взаємодіє з core-геймплеєм після завершення туторіалу. Чи все зрозуміло? Чи використовує потрібні механіки? Чи є аномалії в діях або відвали на нетипових моментах?
• Воронка по рівнях (по кожному level win у порядку проходження).
  Показує, на яких саме рівнях відбуваються відвали. Допомагає виявити надто складні, заплутані або нецікаві рівні.

З досвіду: У проєкті Retention D1 тримався на рівні ~23%. Ми занурилися в аналітику і воронка до core-геймплею показала, що 12% гравців відвалювались ще до старту туторіалу. Ми оптимізували перший екран і пришвидшили завантаження — дрібниця, але важлива.

Далі — воронка самого туторіалу. 80% відвалів припадали на три конкретні кроки. Ми їх скоротили, додали кнопку «Пропустити» і переробили ключові моменти. Після цього прохідність зросла вдвічі.

Наступний інсайт дала воронка по рівнях. Кілька локацій виявились занадто складними, тому ми замінили їх на простіші, але не менш цікаві.

У підсумку Retention D1 виріс на 6 в.п. І це без жодних змін у core-геймплеї.

Аналіз фідбеку: як правильно читати коментарі гравців

Гравці — це джерело даних, просто в іншому форматі. Їхні коментарі, звернення в підтримку, відгуки в магазинах — усе це може допомогти знайти реальні причини відвалів або підказати нові гіпотези.

Якщо правильно працювати з фідбеком, можна отримати:

• Відвали з воронки. Наприклад: бачите падіння на 6-му рівні з новою механікою і паралельно серія коментарів «не зрозуміло, як це працює».
• Багрепорти. Точкові проблеми, наприклад: «гра зависає після використання двух бустерів одночасно» або «не працює tap після туторіалу» — не так видно в аналітиці, але впливають на досвід.
• Сигнали про core/UX. Фрази: «нудно», «арт слабкий», «не зрозуміло, що робити» — натякають на проблеми з фундаментом.

Якщо у вас немає команди саппорту або окремого процесу збору фідбеку, підійде простий Google Sheet. Туди заносимо усі релевантні коментарі по кожній версії, сегментуємо за типами проблем і сортуємо за кількістю згадок.

З фідбеком варто працювати дуже обережно. На відміну від воронки, фідбек часто містить «рішення проблем», що не підкріплені масштабом, Гравець міг зіткнутися з рідкісною ситуацією, але звучатиме це так, ніби все зламано. Тому перш ніж щось змінювати, варто перевірити в аналітиці: скількох людей це реально зачіпає?

Фокус має бути на релевантних сигналах, які впливають на більшість користувачів у D0—D1.

P.S. Так, це нормально, що в грі з рекламною монетизацією топовий коментар — «забагато реклами». Але це не означає, що її варто одразу прибирати.

Аналіз конкурентів: не для натхнення, а для діагностики

Цей інструмент особливо корисний, коли у вас є прямі рефи — успішні ігри з однаковим core-геймплеем. Аналіз відмінностей між вашим продуктом і ними може підказати, що саме у вас може бути «не так» і як це покращити.

Головне — не розпиляйтесь. Якщо ви не маєте бюджету Royal Match, то не варто порівнювати себе з ним за візуалом чи продакшеном. В кризові моменти після провального тесту фокус має бути тільки на релевантних рефах.

Я рекомендую:

Визначити, що саме побачив гравець у D0

Подивіться, куди дійшли 50% і 75% гравців у свій нульовий день: який контент вони побачили, які механіки спробували. Це і є ваша «реальна перша сесія».

Записати проходження

У форматі family & friends порівняйте, як гравці грають у вашу гру та 2-3 гри-референси. Обов’язково з відео і голосом. Міксуйте послідовність ігор в групі.

Фокус на конкретиці, а не на емоціях:

• Скільки тривав лоадінг?
• Скільки часу зайняв туторіал?
• Скільки дій/спроб потрібно для проходження рівня?
• Коли надається повний контроль?
• Коли надається перша нагорода?
• Дедлоки.

Порівняння з рефами дозволяє сфокусуватись на гострих розбіжностях — найчастіше це пейсинг. Ви й так багато взяли з рефів, але могли упустити критичну деталь, яка зламала роботу всієї системи з точки зору ігрового досвіду.

Перший день — це про досвід, а не про фічі. FTUE — головна історія

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

Ці речі здаються простими, але саме вони — найсильніші важелі впливу на Retention D1. Усі ігри з високими метриками роблять це добре: швидкий вхід у гру, зрозумілий core, приємне керування, мінімальна фрустрація. Якщо ви не знаєте, з чого почати — почніть із цього.

Підсумки

Провальний тест — це не емоційна оцінка гри, а сигнал, що частина гіпотез не підтвердилась. Це момент, коли потрібно не доводити, що продукт «все ще хороший», а тверезо зважити: що саме зламалось, чи можемо це виправити, і чи варто вкладати ресурси далі?

Важливо — приймати ці рішення не «на віру», а спираючись на воронки, фідбек, конкурентів і обсяг роботи, який реально потягне команда по експертизі а студія по костам.

Бажаю всім, хто отримав слабкий старт, зберігати холодну голову, тестувати гіпотези та приймати зважені рішення, навіть після фейлу!

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини