World of Tanks — мониторинг здоровья сезона Battle Pass

Условие

В World of Tanks запускаются сезоны Battle Pass длительностью около 3 месяцев. Продюсер просит обеспечить команду мониторингом здоровья метрик Battle Pass — чтобы понимать текущее состояние активности и при необходимости оперативно принимать решения.

Сделайте следующее:

1. Сформулируйте 10 вопросов, которые задали бы продюсеру для лучшего понимания запускаемой активности.
2. Предложите 10+ метрик, которые порекомендовали бы для мониторинга статуса события.
3. Предложите способы и инструменты для выполнения запроса.
4. (Опционально) Опишите этапы / последовательность действий.

Решение

Подход

Мониторинг live-сервисного контента — это не «дашборд для красоты», а система раннего обнаружения проблем, способная подсказать, когда нужно вмешательство (rebalance, ивенты, экстренные награды). Сначала задаём вопросы → потом строим метрики, отвечающие на них.

10 вопросов продюсеру

1. Главная цель сезона. Что важнее — retention (удержать существующих), monetization (продать пасс) или engagement (увеличить time-on-game)?
2. Аудитория. Все игроки или сегмент? Какая ожидается доля покупателей пасса?
3. Структура наград. Чем отличаются tracks (free / premium)? Сколько уровней? Какая «крутая» награда — где?
4. Кривая прогрессии. Сколько в среднем нужно играть в день, чтобы пройти пасс полностью? Есть ли «catch-up» механики?
5. Точки риска. Какие уровни считаете «узкими горлышками» — где люди выгорают? Какие награды считаете «магнитом» — где люди ускоряются?
6. Бенчмарки прошлых сезонов. Какие метрики и значения мы хотим побить (или хотя бы повторить)?
7. Сегменты для отдельного мониторинга. Регионы, платформы (PC vs console), длительность аккаунта (новые vs старые), уровень техники.
8. Точки принятия решений. В какой момент сезона нужно максимум данных? (например, на 25% сезона — оценка, нужны ли изменения).
9. Связи с другими механиками. Конкурирует ли BP с другими активностями (события, боевые задачи)?
10. Что значит «всё пошло не так». Какие «красные» значения метрик заставят запустить корректирующее действие? (porog для повышения наград / запуска бонусной недели).

10+ метрик для мониторинга

Группа A. Активация и охват

• BP activation rate = доля DAU, открывших экран BP в первый день сезона.
• BP unique participants / DAU — доля DAU, набравших ≥ 1 BP-очко за день.
• Premium pass conversion = купивших премиум-пасс / уникальных просмотров пейвола.

Группа B. Прогрессия

• Levels-per-DAU — медианное число уровней пасса, набираемое за день.
• % DAU, преодолевших уровень N — где N — целевые уровни (например, 25, 50, 75 — четверти прогресса).
• Drop-off на каждом уровне — % DAU, которые играли вчера и не играли сегодня (по уровням).
• Catch-up usage — доля DAU, использовавших ускорители (бустеры, daily quests).

Группа C. Монетизация

• Revenue per BP-purchase — средний чек.
• ARPU и ARPPU в сезон vs не-сезон.
• In-pass purchases (покупка скипов уровней / бустеров) — частота и динамика.

Группа D. Удовлетворённость / health

• D7 retention BP-участников vs D7 retention non-participants — даёт ли BP retention-уплифт.
• NPS / CSAT в опросах в сезон.
• Жалобы / тикеты связанные с BP — раннее обнаружение проблем.
• Time-spent в режимах, пушащих BP-progress — не ушли ли игроки в «гринд» однотипных режимов.

Группа E. Гарды

• Crash / error rate в BP-экранах.
• Latency загрузки.
• Доля BP-багов в support-тикетах.

Инструменты и способы

• Дашборд для команды в BI-инструменте (Tableau / Looker / Superset / Metabase). Обновление — ежедневно, ключевые — каждые несколько часов в первые дни.
• Алерты на резкие отклонения (Anodot / самописный alert manager) — например, drop-off на уровне X > 10%.
• Когортный SQL-конвейер в Airflow + хранилище.
• Сегментация для дебага — Tableau со срезами по платформе/региону/тиру техники/предыдущему опыту BP.

Этапы выполнения запроса

1. Снять требования (вопросы выше) → дизайн дашборда (1–2 дня).
2. Понять источники данных и доступность сырых событий → описать пайплайны (3–5 дней).
3. Прототип дашборда с тестовыми данными → согласование с продюсером.
4. Запуск к началу сезона + ежедневный stand-up по метрикам в первую неделю.
5. Постмортем сезона: сравнение факта с гипотезами, обновление бенчмарков.

Подводные камни

1. Vanity metrics. «Просмотры экрана BP» — не покажут проблем с прогрессией. Метрики должны быть actionable.
2. Слишком много метрик. На дашборде должно быть 5–10 главных, остальное — drill-down. Иначе менеджеры теряются.
3. Только средние, нет распределений. «Медианный игрок прошёл уровень 25» = в среднем нормально, но 30% мог застрять на уровне 10 — это и есть проблема.
4. Нет бенчмарка. «X% активировали BP» — много это или мало? Без сравнения с прошлыми сезонами — бесполезно.
5. Нет сегментации. В моноблоке BP может «нормально», а на console — катастрофа. Сегментация по платформе/региону/опыту — обязательна.
6. Совпадение метрик и алертов. Не все метрики мониторим — на алерт ставим только те, у которых есть операционное действие при срабатывании.

Эталонный ответ

Хороший ответ структурирован: вопросы → метрики (по группам активация / прогрессия / монетизация / health / гарды) → инструменты (BI + алерты + когортный пайплайн) → план развёртывания. Главное — показать, что метрики связаны с принятием решений, а не «вообще для красоты дашборда».