Як впровадити та ефективно використовувати Remote Config в дитячому EdTech продукті

Привіт, мене звати Олесь Дібрівний, я Unity Developer в компанії Keiki з екосистеми Genesis. Ми створюємо продукт на стику EdTech та GameDev — застосунки й вебпродукти для розвитку дітей. Ними користуються понад п’ять мільйонів юзерів.

Як створити оптимальний онбординг, який не будуть скіпати, розширити користування доступним функціоналом та експериментувати з головним меню без додаткових перерелізів? З допомогою віддалених налаштувань, аналітики та A/B тестів. Як це реалізувати — розповідаю у цій статті.

Ця стаття буде корисною усім, хто розробляє мобільні аппки — від розробників до продакт-дизайнерів.

Чого хочуть малі й дорослі користувачі

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

Це підтверджує інфографіка нижче. Ліворуч — дані звіту Udonis Hyper-Casual Games Report: Monetization & Advertising за вересень 2022 року. Праворуч — статистика, зібрана командою аналітиків Keiki.

На ній зображені відсотки від загальної кількості користувачів, середня тривалість однієї сесії та кількість рівнів, які пройдуть гравці за цей час. Як бачимо, 55-60% користувачів обох аудиторій гратимуть протягом 20-25 хвилин, діти в середньому проходять 8 рівнів, дорослі — 3. Така різниця повʼязана не з віком гравця, а з тим, що в додатку Keiki середня довжина рівня набагато менша — 2-3 хвилини. Але що ця інформація дає розробнику? Цей час та кількість рівнів — все, що ми маємо, щоби зацікавити користувачів і викликати в них бажання повернутися, або навіть здійснити покупку. Отже, маючи обмежені ресурси, треба використовувати їх ефективно.

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

На гіфках нижче зображені два варіанти онбордингу. Чим вони відрізняються? Перше, що спадає на думку — дизайн. Лівий має більш кольоровий і округлий дизайн, з більшими елементами. Але для нас головна відмінність — процент користувачів, що закінчують послідовність екранів онбордингу без пропусків. Для наведених нижче послідовностей різниця складає 26%. Більш того, замінивши всього один екран у послідовності, цю метрику можна збільшити на 6%. Але як дізнатися, який із дизайнів чи екранів, спрацює у вашому застосунку найкраще? Відповідь — віддалені конфіги, аналітика та A/B тести.

Як впровадити та використовувати ремоут конфіги

Існує з десяток варіантів, як впровадити віддалені конфіги в застосунок. Виділю три найпоширеніших:

  1. Firebase — універсальне і відносно недороге рішення, що покриє всі базові потреби у роботі з віддаленими налаштуваннями та аналітикою. Функціонал доволі легко інтегрується майже в будь-який мобільний проєкт. Докладна документація написана доволі просто. Також оскільки це одне з найпопулярніших рішень на ринку, на форумах можна знайти відповіді на більшість питань, що виникають у процесі роботи.
  2. Unity remote configs — рішення виключно для тих, хто використовує двигун Unity. Має такі ж переваги, що і Firebase, але його ще простіше інтегрувати в проєкт.
  3. Самописна аналітика — шлях для проєктів, у яких є вільні «руки» й бюджет. Головна перевага такого підходу — повна кастомізація під ваші потреби. Але якщо ви тільки починаєте, раджу розглядати перші 2 варіанти.

Після того, як ви виберете систему для роботи з віддаленими конфігами, вам потрібно буде підготувати гіпотезу, яку ви хочете перевірити. У нашому випадку — протестувати послідовності різних екранів онбордингу.

Які тести ми можемо проводити із цими екранами? Наприклад, паралельне тестування двох абсолютно різних послідовностей (на гіфках вище). Або послідовностей, які відрізняються кількома або лише одним екраном. Або навіть тести, де ми змінюємо частину конкретного екрана. Всі ці перевірки можна запускати одночасно за допомогою A/B тестів. Ви просто обираєте, скільки користувачів братиме участь у тесті, розділяєте їх на дві групи та надсилаєте кожній групі конфігурацію, яка визначатиме, що вони бачитимуть у застосунку. Потім обираєте показники та відстежуєте їх (у нашому випадку таким показником була кількість юзерів, що пройшли онбординг без пропуску).

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

Що означають ці параметри:

  • Id — єдиний параметр аналітики, який ми використовуємо для зручності під час тестування.
  • PageType разом із PageSkin визначає, який префаб використовуватиметься для візуалізації екрана.

Що стосується параметра «Data», то він визначає все, що ми захочемо. Це можуть бути майже будь-які налаштування екрана: від анімації до внутрішніх послідовностей.

Екрани, які ми тестуємо, зібрані в Scriptable Object. Для тих, хто не використовує Unity — сховище на основі патерну легковаговика (Flyweight). Ми можемо знайти потрібний префаб за PageType і PageSkin, які ми зберегли у віддалених конфігураціях. Це можливо завдяки системі, яку назвали динамічним контекстом.

Це реалізація досить простої концепції:

  • не маємо жодних статичних послідовностей екранів;
  • створюємо екземпляри екранів під час виконання, коли нам це потрібно;
  • після використання знищуємо їх з урахуванням певних умов (наприклад, онбординг — це одна послідовність, тому ми будемо знищувати послідовність, тільки коли користувач її завершить);
  • зберігаємо деяку кількість раніше використаних екранів, щоби ми могли повернутися до них.

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

Ремоут конфіги для зміни вигляду меню

Інша річ, яку ми протестували з використанням віддалених конфігурацій, це зовнішній вигляд головного меню. Так виглядало старе рішення, де основну частину екрана займала анімована іконка лише однієї гри, тоді як в застосунку є понад 30 різних ігор і три списки відео.

Напередодні тестування у нас було дві теорії.

  1. Батьки вважають, що в застосунку досить мало контенту через те, що його важко знайти. Для цього користувачу треба прокрутити всі ігри та внутрішні меню з рівнями.
  2. Більшість користувачів грають лише в перші декілька ігор у порядку прокручування, тому ми не можемо оцінити, як кожна гра впливає на інтерес користувачів. Крім того, через те що великі анімовані піктограми привертають більше уваги, деякі інші функції використовувалися лише невеликою кількістю користувачів, яким пощастило їх знайти.

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

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

У результаті в нас було два дизайни, A/B тестування яких дало доволі цікаві результати.

Функціонал

Різниця використання відносно старого меню

Games

-3 %

Videos

-6 %

Learning Plan

+29 %

Work Sheets

+33 %

Daily Games

+45 %

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

Також в новому меню можна експериментувати з такими речами, як вигляд кнопок та порядок того, що бачить користувач. Доступна зміна майже кожної опції відображення, починаючи з розміру елементів і закінчуючи функціоналом. Так ми можемо повністю змінити вигляд цього екрану без нових випусків, і зробити це у вигляді A/B-тестів. Наприклад, встановити пріоритети на екрані, просто зробивши більші кнопки обраного функціонала.

Також через ремоут конфіги ми можемо керувати таким функціоналом:

  1. Локалізація.
  2. Політики конфіденційності.
  3. Список відеоконтенту, який юзери можуть переглядати із застосунку.
  4. Список і порядок ігор, у які користувачі можуть заходити, а також вигляд меню вибору рівнів.
  5. Список категорій та рівнів у навчальному плані.
  6. Параметри екранів батьківського захисту (задачки, щоби не пустити дітей у налаштування).

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

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

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному4
LinkedIn

Схожі статті



Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Офігенно! Дякую за приклади з роботи. А всі ці змінні налаштування суттєво впливають на фінальний розмрі апки чи ні?

Ну самі налаштування не дуже. Впливають ресурси, для того що ви хочете тестувати\змінювати. Наприклад якщо у вас буде 2 вікна з різними зображеннями, то кожне зображення буде тягнути додаткову вагу.

Підписатись на коментарі