Roblox Experiments: как проводить A/B-тесты и улучшать игру

1. Для каких решений нужен этот инструмент

Поломки исправляйте сразу. Если причина оттока неизвестна, сначала посмотрите прохождения игроков. A/B-тест нужен, когда есть конкретная гипотеза и два работоспособных варианта.

При небольшой аудитории проверяйте заметные изменения: обучение, сложность, темп прогресса. Для небольшого эффекта вроде смены оттенка кнопки потребуется больше участников.

2. Что сначала должен сделать разработчик

Подключите Experience configs и используйте значения ключей в коде игры. Например, onboardingHintMode должен действительно переключать старую и новую подсказки. Создание ключа в кабинете само по себе не меняет игру. Настройка конфигураций.

Для персональных вариантов используется ConfigService:GetConfigForPlayerAsync(player). Обычный GetConfigAsync() подходит для общей конфигурации и не включает игрока в эксперимент. Чтение соответствующего ключа через GetValue() у персонального снимка запускает участие в тесте этого ключа. Поэтому важно когда именно код впервые читает значение. Подключение Experiments к коду.

Тест оформления магазина: включайте игрока перед первым показом окна. Тест заметности кнопки магазина: включайте до показа кнопки. Отбор только открывших магазин во втором случае исказит результат.

• Значение читается отдельно для нужного игрока и действительно меняет нужное поведение.
• Включение в эксперимент происходит до первого возможного влияния изменения, в одинаковой точке для A и B.
• При ошибке чтения действует безопасный обычный вариант; ошибка отдельно учитывается, а не записывается как успешное назначение A.
• В тестовой среде проверены оба поведения, повторный вход и игрок с уже существующим прогрессом.
• Сервер проверяет награды, прогресс и покупки; клиент не определяет их авторитетные значения.
• Есть способ остановить применение изменения и понимание, что случится с уже полученными наградами и сохранениями.

Проверьте подготовленные конфигурации в Studio до публикации. ConfigSnapshot не обновляется сам: применяйте новые значения в подходящий момент, например между раундами. Обновление конфигураций.

3. Как создать первый эксперимент в кабинете

Creator Hub → Creations → ваша игра → Experiments → Create experiment.

1. Выберите In-experience, если меняете поведение через конфигурацию. Matchmaking предназначен для отдельной задачи — сравнения настроек подбора игроков.
2. Назовите тест по изменению: например, Подсказка первого улучшения — v1.
3. Выберите основную метрику — goal metric.
4. Укажите плановую длительность. Текущий диапазон Roblox — 14–60 дней.
5. Задайте rollout: долю подходящих игроков, участвующих в эксперименте.
6. Настройте контроль A и вариант B, их значения и распределение.
7. При необходимости задайте целевую аудиторию.
8. Проверьте параметры, оценку MDE и расписание, затем запускайте в согласованное время.

Для первого теста предпочтительны один контроль и один вариант с распределением 50/50. Roblox допускает контроль и до двух альтернатив в таком эксперименте, но дополнительные варианты требуют большего объёма данных. После назначения расписания параметры нельзя свободно редактировать; работающий тест также блокирует свой ключ и связанные условия. Контроль получает результат действующих правил конфигурации — это не обязательно одно число для всех. Создание эксперимента.

Rollout — охват теста, распределение A/B — доли внутри него. Например, из 10 000 подходящих игроков rollout 40% включает около 4 000. При 50/50 это 2 000 в A и 2 000 в B. Остальные 6 000 не входят в контрольную группу отчёта.

Маленький rollout ограничивает последствия ошибки, но замедляет накопление данных. Проверьте техническую работу заранее и выберите достаточный охват до запуска: менять его каждый день в работающем тесте нельзя.

4. Какие показатели читать и что они означают

Roblox Experiments отслеживает D1 и D7 retention, Playtime, Session time, ARPU, ARPPU и Payer conversion rate; выбор goal metric не отключает остальные. Playtime и денежные показатели в этом отчёте относятся к периоду эксперимента. Их нельзя автоматически считать суточными показателями из другого отчёта. Метрики Experiments.

ARPU = доля платящих × ARPPU при одинаковых периоде, аудитории и определении выручки. Пример: в A платят 2% по 100 Robux — ARPU = 2. В B платят 3% по 60 Robux — ARPU = 1,8. Покупателей больше, выручка на пользователя меньше.

Задайте три роли метрик: главная — цель теста; диагностические — объяснение результата; ограничивающие — допустимая цена улучшения. Практика Microsoft.

Для обучения: главная — D1; диагностика — доля дошедших до первого улучшения и время до него; ограничения — D7 и ошибки. Улучшение воронки без роста D1 не подтверждает гипотезу о возврате игроков.

5. Сначала найдите место потери игроков

Составьте воронку реальных действий: вход → первое действие → награда → улучшение → применение улучшения → следующая цель. Названия шагов должны соответствовать механике игры.

Смотрите два вида переходов: долю от всех вошедших и долю от предыдущего шага. Большая потеря на раннем шаге обычно даёт больше пространства для улучшения, чем небольшая потеря на этапе, куда доходят единицы. Но сначала проверьте само событие: отсутствие записи не обязательно означает, что игрок не выполнил действие.

В Roblox есть важные особенности воронок: пропуск раннего шага при регистрации позднего может автоматически засчитать предыдущие; повтор шага не означает ещё одного уникального прохождения; фильтры привязываются к первому шагу. Неверное логирование способно нарисовать улучшение, которого не было. Для сравнения вариантов можно использовать собственные поля событий. Funnel events.

Посмотрите несколько прохождений с согласия участников. Попросите выполнить задачу и объяснить ожидания; не подсказывайте. «Не понимаю, зачем улучшение» требует другого теста, чем «слишком долго коплю на него».

6. Восемь экспериментов для игры

Приоритет: понимание → первая полезная награда → ранний прогресс → возвращение → монетизация. Сначала устраните подтверждённую потерю игроков в основном цикле.

Проверяйте связанные изменения последовательно: упрощение прогресса может менять спрос на ускоритель. Если запустить их одним пакетом, результат покажет эффект пакета, но не каждой правки.

7. Полностью разобранный первый тест

Возьмём гипотезу: новички не понимают, что первое улучшение меняет их возможности; если показать эффект сразу, больше людей вернутся завтра.

В A остаётся текущая подсказка. В B появляется короткий понятный показ: что станет сильнее и какое действие станет доступнее. Стоимость, сила улучшения, награда, магазин и реклама внутри игры остаются прежними. Это помогает проверить именно понимание ценности.

Для аудитории выберите игроков, которым показывается этот ранний этап, и заранее определите момент включения. Основная метрика — D1. Завершение улучшения служит диагностикой. D7, выручка на пользователя и технические ошибки — ограничения.

До запуска задайте минимально полезный прирост D1 и максимально допустимое падение D7. Пороги выбирайте по экономике игры, базовым метрикам и стоимости поддержки изменения.

1. До старта: проверить оба варианта, события, обычный вариант при ошибке и план возврата.
2. При старте: записать параметры, версию игры, даты и состояние рекламного трафика.
3. Первые сутки: проверить технические ошибки и факт получения разных значений. Оценку победителя не делать.
4. Во время теста: следить за безопасностью, полнотой данных и размером групп; не подстраивать гипотезу под график.
5. В плановую дату: проверить зрелость нужных показателей, интервалы неопределённости и ограничения.
6. После решения: документировать результат и наблюдать, сохраняется ли польза после распространения изменения.

Если завершение первого улучшения выросло, а D1 нет, следующий тест посвятите цели после улучшения: понятный первый шаг ещё не даёт причины вернуться.

8. Как не принять случайность за победу

MDE — минимальный эффект, который тест способен достаточно уверенно обнаружить при выбранном плане. Смотрите его до запуска. Если вас интересует рост на 5%, а MDE около 25%, такой план плохо подходит для ответа на ваш вопрос. Варианты: больше подходящих участников, дольше тест, меньше вариантов или более заметная гипотеза. Низкий DAU усложняет задачу, но одного универсального порога «можно / нельзя» нет: важны метрика, разброс и реальное включение игроков. Планирование Experiments.

CCU здесь не заменяет число участников. Игрок, заходящий ежедневно, не становится семью независимыми игроками. И 14 дней работы не гарантируют достаточную выборку для редкой покупки или дорогого товара.

Не путайте проценты и процентные пункты. Увеличение D1 с 10% до 11% — это +1 процентный пункт и +10% относительно исходного уровня. Для планирования полезно записывать обе величины.

Интервал неопределённости важнее одной зелёной цифры. В Roblox он доступен через View confidence; интервал изменения, пересекающий ноль, не позволяет уверенно утверждать направление эффекта по принятому критерию. Интерпретация результатов.

«Статистически незначимо» не означает «варианты одинаковы». И наоборот: небольшой убедительный прирост не всегда стоит дорогой поддержки. При выборе учитывайте ожидаемую пользу на масштабе игры, сложность кода, нагрузку на контент и обратную связь.

Чем больше метрик, вариантов и срезов вы просматриваете, тем проще случайно найти что-то зелёное. Поэтому основное решение опирается на заранее выбранную цель; неожиданное улучшение другой метрики — повод для осторожной проверки, а не для переименования гипотезы задним числом.

Ежедневный просмотр допустим для поиска поломок. Опасно другое: каждый день искать удобный момент объявить победу. Плановый срок и основной критерий фиксируются заранее. При серьёзной поломке тест останавливают ради игроков и описывают как остановленный по технической причине, а не как завершённое доказательство гипотезы.

9. Приёмы, которые делают тесты полезнее

Сравнивайте всех включённых участников. Отбор только покупателей или дошедших до финала зависит от варианта и искажает его эффект.

Задавайте важные сегменты заранее. Случайно удачный результат в одной из десятков стран — гипотеза для нового теста, а не основание объявить победу.

Сравнивайте A и B одновременно. Новый состав трафика может поднять показатели обеих групп. Вывод относится к включённым участникам; результат среди открывших магазин не описывает автоматически всех посетителей игры.

Проверяйте баланс групп. Заметное необъяснимое отклонение от ожидаемого распределения — повод разбираться в включении, ошибках и логировании до интерпретации результата. Это не повод вручную выкинуть лишних игроков из группы. Такая проблема известна как Sample Ratio Mismatch; исследователи Microsoft относят её к проверкам качества эксперимента. Разбор SRM.

Не делите одну общую механику между игроками без проверки. Если варианты меняют здоровье общего босса, совместную награду, торговую экономику или правила PvP, игроки воздействуют друг на друга. Персональная настройка может оказаться технически противоречивой или загрязнить сравнение. Нужен отдельный дизайн теста с подходящей единицей распределения; простого переключателя на игрока может быть недостаточно.

Отдельно продумайте возвращающихся участников. Roblox переоценивает условия целевой аудитории по сессиям. Игрок может перестать подходить под условие и вернуться к обычной конфигурации. Для сценария, которому нужна непрерывность между сессиями, разработчик должен явно обеспечить её и учитывать правила атрибуции. Таргетирование Experiments.

Откат конфигурации не откатывает жизнь игрока. Полученный ресурс, пройденная зона или покупка уже произошли. Поэтому первые эксперименты лучше проводить на обратимых подсказках и представлении информации, а не на необратимом изменении сохранений.

Записывайте, что именно не сработало. «Подсказка увеличила завершение, но не возврат» подсказывает следующий тест точнее, чем «не сработало».

10. Что проверяли другие создатели игр

В подборке Roblox Staff с рассказами создателей опубликованы такие результаты:

MikkelDevs в той же публикации описывает, как промежуточный рост ARPU на 30% сократился до 3% на следующий день: ранний результат может сильно измениться.

Авторы не раскрыли размеры выборок, исходные значения и интервалы. Проценты приведены как в источнике; для долевых метрик их нельзя заменять процентными пунктами.

11. Особая осторожность с монетизацией

Разделите три вопроса: игрок видит предложение, понимает пользу, принимает цену. Проверяйте их отдельно, чтобы знать причину результата.

Не считайте, что число в Config автоматически меняет настоящую Robux-цену developer product или pass. Для таких цен у Roblox есть отдельный механизм Managed Pricing / Price optimization; интерфейс магазина должен получать актуальную цену, а не показывать зашитую константу. До теста нужно проверить совпадение отображаемой цены и системного предложения покупки. Price optimization.

Начните с описания товара, демонстрации пользы или момента показа при прежней цене. Так результат не смешается с реакцией на скидку.

При редких покупках средняя выручка может резко меняться из-за нескольких плательщиков. Проверяйте число покупателей и концентрацию выручки. Нельзя вручную убрать неудобного крупного покупателя только из одной группы: правила обработки необычных наблюдений должны быть едиными и определёнными заранее.

12. Как использовать Experiments вместе с MARPLA

До теста найдите потери в воронке и проверьте удержание, выручку и состав трафика. Учитывайте покрытие данных: отсутствие событий не означает нулевое прохождение.

Создайте веху со ссылкой на карточку теста, версией игры и сопутствующими изменениями. После завершения добавьте результат и решение. Веха сохраняет контекст, но сама не доказывает эффект.

Результат A/B проверяйте в Creator Hub. Общие графики MARPLA и сравнение «до / после» не заменяют разбивку по участникам и вариантам конкретного эксперимента.

В собственных событиях записывайте идентификатор теста и фактически применённый вариант. Не определяйте A/B по дате, стране или предполагаемому назначению игрока.

13. Карточка эксперимента, которую можно копировать

Скачать карточку эксперимента

Название:

Наблюдаемая проблема: какие реальные данные или прохождения её показывают.

Гипотеза: если изменить …, то …, потому что …

Аудитория и точка включения: кто попадает в тест, когда и почему.

Контроль A / вариант B: точные значения и поведение; что остаётся одинаковым.

Главная метрика: одна; точное определение, период и основание расчёта.

Диагностика: шаги воронки и события, объясняющие механизм.

Ограничения: какие ухудшения неприемлемы и как их проверяем.

План измерения: rollout, распределение, длительность, MDE, достаточность аудитории и зрелость D7.

Техническая проверка: оба варианта, ошибки, логирование, обычное поведение при сбое.

Условия экстренной остановки: поломка, потеря прогресса или другой заранее определённый существенный вред.

Решение: внедрить / оставить A / данных недостаточно / нужен новый тест. Результаты, интервалы, ограничения вывода.

После внедрения: кто проверяет результат, когда и какие признаки потребуют возврата к прежнему поведению.

Перед Make decision проверьте предлагаемые изменения конфигурации. По текущей документации выбор победившего нетаргетированного варианта делает его новым значением по умолчанию и убирает условные значения этого ключа. Это реальное изменение игры, а не просто отметка в отчёте. Для таргетированного победителя действуют отдельные правила переноса условий. Применение результата.

Использована документация Roblox Creator Docs, Roblox Corporation, CC BY 4.0. Текст переведён, переработан и дополнен.

Первичные источники

• Roblox Experiments
• Roblox Configs
• ConfigService
• ConfigSnapshot
• Funnel events
• Price optimization
• Running successful experiments: Insights from top creators
• Microsoft Research: Metric Interpretation Pitfalls