Если не можешь измерить — не можешь улучшить

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

Я видел это много раз: талантливые ML-команды создавали отличные модели, но не могли объяснить бизнесу, зачем это нужно. И проекты закрывались — не потому что не работали, а потому что не умели показать, что работают.

В этой части я расскажу, как мы строили систему метрик в Звуке, какие ловушки встретили в A/B-тестах и как научились переводить ML-результаты на язык, понятный CEO и совету директоров.

Proxy-метрики vs бизнес-метрики

Первая и главная ошибка — путать proxy-метрики (технические) и бизнес-метрики (то, что волнует stakeholder'ов).

Proxy-метрики (ML-уровень)

Это метрики качества модели:
- Precision@K, Recall@K — точность и полнота рекомендаций в топ-K
- nDCG — качество ранжирования
- AUC-ROC — качество классификации (для churn prediction и т.д.)
- Hit rate — доля пользователей, кликнувших хотя бы на одну рекомендацию
- Coverage — доля каталога, появляющаяся в рекомендациях

Эти метрики важны для ML-команды, но CEO не понимает nDCG. И не должен.

Бизнес-метрики (C-level)

Это то, что влияет на P&L:
- Revenue / ARPU — доход на пользователя
- LTV — lifetime value
- Churn rate — отток
- Conversion rate — конверсия (в покупку, подписку, целевое действие)
- DAU / MAU — активная аудитория
- Engagement — время в приложении, количество сессий

Мост между ними

Задача ML-лидера — построить мост: показать, как улучшение proxy-метрик транслируется в бизнес-метрики. В Звуке мы это делали так:

nDCG +5% → streaming time +8% → retention D30 +3% → LTV +2.5%

Каждая стрелка — это подтверждённая корреляция на исторических данных. Не теоретическая, а эмпирическая: мы проанализировали десятки прошлых экспериментов и выявили устойчивые зависимости.

Правило: в отчётах для бизнеса используйте только бизнес-метрики. Proxy-метрики — для внутренних ревью ML-команды.

Ловушки A/B-тестов

A/B-тестирование — золотой стандарт оценки персонализации. Но в нём полно ловушек, и я хочу рассказать о тех, в которые мы попадали сами.

Ловушка 1: Simpson's Paradox

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

Как мы попались: запустили новую модель рекомендаций, A/B-тест показал +5% streaming time overall. Отлично! Но при разбивке по сегментам обнаружили: у тяжёлых пользователей (>30 мин/день) — -3%, у лёгких (<10 мин/день) — +15%. Overall положительный эффект объяснялся тем, что в treatment-группу случайно попало больше лёгких пользователей.

Урок: всегда проверяйте баланс групп по ключевым сегментам. И всегда смотрите результаты в разбивке, а не только overall.

Ловушка 2: Novelty Effect

Что это: пользователи реагируют на новое — любое изменение временно повышает engagement, просто потому что оно новое.

Как мы попались: запустили новый блок «Для вас» на главной. Первую неделю — +20% CTR. Через месяц — +3%. Реальный эффект был +3%, а не +20%. Но если бы мы остановили тест через неделю — приняли бы решение на основе inflated metrics.

Урок: минимальная длительность теста — 2 недели, лучше 4. И обязательно стройте time series метрик — если видите затухающий тренд, это novelty effect.

Ловушка 3: Peeking Problem

Что это: проверяете результаты теста каждый день и останавливаете, когда видите «значимый» результат. Это множественное тестирование — вероятность ложноположительного результата растёт экспоненциально.

Как мы попались: тест показал p-value = 0.04 на день 3. PM обрадовался: «Значимо! Раскатываем!». Если бы мы подождали до дня 14, p-value стал бы 0.12 — незначимо. Ранняя остановка дала бы нам ложноположительный результат.

Урок: определяйте sample size и длительность заранее, до начала теста. Используйте sequential testing (например, always-valid p-values) если нужна ранняя остановка. Никогда не пикайте без поправки на множественное сравнение.

Ловушка 4: Interference (сетевые эффекты)

Что это: пользователи в control и treatment группах влияют друг на друга. Актуально для социальных функций.

Пример: если treatment-пользователь делится плейлистом с control-пользователем, control-пользователь получает «лечение», хотя не должен.

Решение: кластерная рандомизация — разделяем не пользователей, а кластеры (города, регионы, социальные графы). Менее мощно статистически, но корректно.

Ловушка 5: Survivorship Bias

Что это: анализируете только пользователей, которые дожили до конца теста, игнорируя тех, кто ушёл.

Пример: новая модель отталкивает 10% пользователей в первый день, но оставшиеся 90% показывают +15% engagement. Overall effect кажется положительным, но вы потеряли 10% аудитории.

Урок: всегда используйте ITT (intention-to-treat) анализ — включайте в анализ ВСЕХ пользователей, попавших в тест, включая тех, кто ушёл.

Статистическая значимость: когда можно принимать решение

Коротко о том, как мы определяли, когда тест завершён:

До запуска теста определяем:
1. MDE (Minimum Detectable Effect) — минимальный эффект, который нас интересует. Обычно 1–3% для основных метрик.
2. Significance level (alpha) — обычно 0.05 (5% вероятность false positive).
3. Power (1-beta) — обычно 0.8 (80% вероятность обнаружить реальный эффект).
4. Sample size — рассчитывается на основе MDE, alpha, power и baseline метрики.
5. Длительность — sample size / daily traffic, но не менее 2 недель.

Во время теста: не смотрим на результаты (или используем sequential testing с always-valid confidence intervals).

После теста: рассчитываем confidence interval, проверяем практическую значимость (effect size), смотрим разбивку по сегментам, проверяем SRM (Sample Ratio Mismatch).

Практический совет: не гонитесь за p < 0.05. Результат с p = 0.06 и effect size +5% — это ценная информация, а не «незначимый результат». Используйте confidence intervals, а не бинарное «значимо/незначимо».

Как «продать» результаты CEO

Это отдельный навык, которому не учат на курсах по ML. CEO не хочет слышать про nDCG и AUC. Он хочет знать три вещи:

  1. Сколько денег это принесёт?
  2. Сколько это стоит?
  3. Когда окупится?

Фреймворк: Impact → Investment → Timeline

Impact (в рублях):

«Новая модель рекомендаций увеличила streaming time на 8%. Исторически +1% streaming time = +0.3% retention. +0.3% retention = +12M ₽ ARR. Итого: +96M ₽ ARR от одного улучшения модели.»

Investment:

«3 ML-инженера × 3 месяца + инфраструктура = 15M ₽»

Timeline:

«Окупаемость: менее 2 месяцев. ROI за год: 640%.»

Вот так разговаривают с бизнесом. Не «мы улучшили nDCG на 5%», а «мы принесли 96 миллионов».

Визуализация

Для совета директоров я всегда готовил один слайд с тремя элементами:
1. Waterfall chart — разложение роста ключевой метрики по факторам (какая инициатива сколько принесла)
2. Trend line — метрика до и после внедрения
3. ROI table — инвестиции vs отдача по каждой инициативе

Один слайд. Никаких confusion matrices и ROC-кривых.

Наш фреймворк метрик в Звуке

Мы выстроили трёхуровневую систему метрик:

Уровень 1: North Star Metric

Streaming time per user per day — главная метрика всей компании. Все остальные метрики — лидирующие индикаторы, которые в конечном счёте влияют на неё.

Уровень 2: Product Metrics (для PM и бизнеса)

  • Retention D1, D7, D30 — удержание
  • Conversion to premium — конверсия в платную подписку
  • DAU / MAU ratio — stickiness
  • Sessions per day — частота использования
  • Content diversity — разнообразие потребления (proxy для долгосрочного retention)

Уровень 3: ML Metrics (для ML-команды)

  • nDCG@K по каждому RecSys-продукту
  • Hit rate, Coverage, Diversity, Novelty
  • Offline → Online correlation — насколько офлайн-метрики предсказывают онлайн-результат
  • Model freshness — как быстро модель адаптируется к новым данным
  • Latency P95 — производительность inference

Связь между уровнями: каждую неделю мы ревьюили ML-метрики, каждый месяц — product metrics, каждый квартал — north star metric. И на каждом ревью показывали, как изменения на нижних уровнях транслируются в верхние.

Типичные ошибки, которых стоит избегать

Подведу итог в виде антипаттернов:

  1. Оптимизировать proxy, забыв про бизнес. nDCG растёт, streaming time падает? Значит, оптимизируете не то.
  2. Останавливать тест рано. Увидели значимость на день 3 — это не значимость, это шум.
  3. Не смотреть сегменты. Overall +5% может скрывать -10% у вашего самого ценного сегмента.
  4. Не иметь pre-registration. Определяйте гипотезу, метрики и критерии до начала теста, а не после.
  5. Рассказывать CEO про AUC. Переводите на язык денег.
  6. Не считать ROI. Если вы не можете посчитать ROI персонализации, кто-нибудь другой решит, что его нет.

Что дальше

В следующей части мы поговорим о команде — кого нанимать, как структурировать и какую культуру строить.

Хотите выстроить систему метрик для персонализации? Запишитесь на консультацию — помогу определить ключевые метрики и построить мост между ML и бизнесом.