К содержимому
Темы и маршруты чтения

Анализ игр

Before/after-анализ обновления: база и смешивающие факторы

График до и после измеряет совпадение вокруг релиза. Он помогает решать, если план, база и альтернативные причины заданы явно, но сам по себе не создаёт причинность. Используйте его с [гидом по обновлениям](/ru/resources/evaluate-game-updates), а при подходящем трафике выбирайте [эксперимент Roblox](/ru/resources/roblox-experiments-guide).

Подробный разбор

Понятия и инструменты этой темы 7
Авторская тематическая схема MARPLA: Before/after-анализ обновления: база и смешивающие факторы
Авторская тематическая схема. Не интерфейс сервиса и не измеренные показатели.

Спроектируйте сравнение до релиза

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

Смешивающие факторы двигают результат вместе с обновлением: реклама, Home, блогер, цены, сбои платформы, праздники, другой релиз, изменение трекинга или состава игроков. Проверьте их до интерпретации. Формулировки «метрика изменилась после релиза» и «релиз вызвал изменение» должны быть разными.

Пример: D1 вырос после онбординга

В понедельник команда сокращает онбординг. D1 новичков равен 18% против 14% в прошлый понедельник, а их число растёт с 5 000 до 12 000. Результат выглядит хорошим. Но Acquisition показывает большую когорту Home вместо платного трафика и новый состав стран. Продукт изменился вместе с аудиторией.

По источнику и стране крупная стабильная когорта выросла с 15% до 17%, новая Home-когорта показывает 19%. Безопасный вывод: общий D1 вырос, онбординг мог помочь, но состав тоже изменился. Команда может провести допустимый эксперимент или повторить логику на сопоставимой когорте до масштабного редизайна.

Проведите защищаемую наблюдательную оценку

Храните исходный план вместе с итогом, чтобы была видна смена метрик после факта.

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

Ложная уверенность в оценке

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

Возврат к среднему делает изменение после плохой недели успешным на вид. Новизна временно повышает вовлечение. Трекинг имитирует продуктовый эффект. Если решение дорого или необратимо, ограничения before/after оправдывают эксперимент или поэтапный запуск.

Запись решения

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

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

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

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

Примените это в MARPLA

Обсуждение0

Загружаем комментарии…