Бизнес-метрики и продуктовый подход

Бизнес-метрики — почему NDCG +5% ≠ revenue +5%

Ты улучшил модель ранжирования: NDCG вырос на 5%, офлайн-метрики зеленеют. Выкатил A/B-тест — а revenue не изменился. Или хуже: вырос CTR, но выручка упала. Почему?

Потому что ML-метрики и бизнес-метрики живут в разных мирах. NDCG измеряет качество ранжирования. Бизнес измеряет деньги, пользователей и retention. Между ними — длинная цепочка, которая может порваться в любом месте. Модель ранжирует «кликабельное», а не «покупаемое». Или рекомендует то, что человек купил бы и без рекомендаций. Или оптимизирует краткосрочный engagement в ущерб долгосрочному retention.

Задача ML-инженера — не просто обучить модель с лучшим NDCG, а связать модельные улучшения с бизнес-результатом. В этой ноде — полная картина: от цепочки «ML-метрика → деньги» до A/B-тестирования бизнес-метрик и ловушек, в которые попадают даже опытные команды.

Большая картина: от ML-метрики до денег

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

Уровень 1 — ML-метрика. То, что ты оптимизируешь при обучении: NDCG, AUC, logloss. Считается офлайн на hold-out. Быстрый фидбек, но далеко от реальности. Уровень 2 — Прокси-метрика. Онлайн-метрика, которая (предположительно) связана с бизнесом: CTR, время сессии, глубина просмотра. Считается в реальном времени по логам. Уровень 3 — Бизнес-метрика. То, что волнует продакт-менеджера: revenue, конверсия, retention, ARPU. Прямо связана с деньгами. Уровень 4 — Стратегическая метрика. North star компании: LTV, market share, NPS. Меняется медленно, но определяет долгосрочный успех.

Конкретный пример разрыва: ты оптимизировал модель на NDCG (уровень 1). CTR вырос на 3% (уровень 2) — ура! Но конверсия упала на 1% (уровень 3). Что произошло? Модель научилась ставить наверх «кликабельные» товары (яркие картинки, скидки), но пользователи кликали и уходили — не покупали. Прокси-метрика выросла, бизнес-метрика упала.

Revenue-метрики: GMV, RPS, ARPU, LTV

Revenue-метрики — прямое отражение денег. Именно их смотрит CFO и именно они определяют, жив ли бизнес.

GMV (Gross Merchandise Value) — общая сумма продаж через рекомендации. Самая «жирная» метрика для e-commerce: сколько денег прошло через рекомендательную полку. Проблема: GMV растёт и просто от роста трафика, поэтому нужна нормировка.

Revenue per Session (RPS) — GMV делённый на количество сессий. Показывает ценность одного визита. Если ты улучшил модель и RPS вырос — значит каждый визит стал ценнее, а не просто пришло больше людей. Это главная метрика для рекомендаций в e-commerce.

ARPU (Average Revenue per User) — средний доход с пользователя за период (обычно месяц). Для подписочных сервисов: ARPU = подписка + допродажи. Для freemium: ARPU = доход / все пользователи (включая бесплатных). Метрика отвечает на вопрос: «насколько хорошо мы монетизируем аудиторию?»

LTV (Lifetime Value) — сколько денег пользователь принесёт за всё время использования продукта. Самая стратегическая revenue-метрика. Простейшая формула: LTV = ARPU × среднее время жизни пользователя. Но в реальности считают через когортный анализ или survival models — пользователи уходят с разной скоростью.

# Простой расчёт revenue-метрик из логов
import pandas as pd

orders = pd.DataFrame({
    'session_id': ['s1','s1','s2','s3','s3','s3'],
    'user_id':    ['u1','u1','u2','u1','u1','u1'],
    'item_price': [500, 300, 1200, 150, 200, 350],
    'source':     ['rec','rec','search','rec','rec','organic'],
})

# GMV рекомендаций
rec_orders = orders[orders['source'] == 'rec']
gmv = rec_orders['item_price'].sum()  # 500+300+150+200+350 = 1500

# Revenue per Session (только сессии с рекомендациями)
rec_sessions = rec_orders['session_id'].nunique()  # 2 сессии
rps = gmv / rec_sessions  # 750 руб/сессию

# ARPU (по всем пользователям)
total_revenue = orders['item_price'].sum()  # 2700
unique_users = orders['user_id'].nunique()  # 2
arpu = total_revenue / unique_users  # 1350 руб/юзер

Engagement-метрики: CTR, время, retention, DAU/MAU

Engagement-метрики показывают, насколько пользователь вовлечён: кликает ли, сколько времени проводит, возвращается ли. Для контентных платформ (видео, музыка, новости) engagement часто важнее прямого revenue — деньги приходят через рекламу, подписки или рост аудитории.

CTR (Click-Through Rate) — доля показов, по которым кликнули. Самая быстрая и самая опасная метрика. Быстрая — потому что считается мгновенно, А/B-тест набирает мощность за часы. Опасная — потому что кликнуть ≠ получить пользу. Оптимизация чистого CTR ведёт к кликбейту.

Time Spent — сколько времени пользователь проводит на платформе. YouTube и TikTok оптимизируют именно время: больше смотришь → больше рекламы → больше revenue. Но и тут ловушка: «залипательные» рекомендации увеличивают time spent, но потом пользователь чувствует «вину» и снижает использование.

Retention D1/D7/D30 — доля пользователей, вернувшихся через 1, 7, 30 дней. Золотая метрика для оценки долгосрочного здоровья. Если рекомендации реально полезны — пользователь возвращается. Если рекомендации «дёшево» оптимизируют CTR — retention падает, но заметишь ты это только через неделю-месяц.

DAU/MAU (Stickiness) — отношение дневных активных пользователей к месячным. Показывает, какая доля аудитории пользуется продуктом каждый день. DAU/MAU = 0.5 значит половина месячной аудитории заходит ежедневно — отличный показатель. Для мессенджеров DAU/MAU ≈ 0.6-0.7, для e-commerce ≈ 0.1-0.2.

Каннибализация: рекомендации продают то, что купили бы и без них

Допустим, рекомендательная полка на маркетплейсе сгенерировала GMV = $1M. Значит ли это, что рекомендации принесли $1M дополнительной выручки? Нет. Часть этих покупок произошла бы и без рекомендаций — пользователь нашёл бы товар через поиск, каталог или закладки. Это каннибализация — рекомендации «присваивают» продажи, которые состоялись бы в любом случае.

Аналогия: ты идёшь в магазин за молоком. На входе стоит промоутер: «Купите молоко!». Ты покупаешь. Промоутер записывает себе конверсию. Но ты и так собирался его купить — его усилия не принесли инкрементального эффекта.

Incremental lift — истинный эффект рекомендаций: только те покупки/действия, которые не произошли бы без рекомендации. Считается через контрольную группу в A/B-тесте: • Treatment: видит рекомендации • Control: видит случайные/популярные айтемы или пустой блок • Incremental lift = conversion(treatment) − conversion(control)

Типичная ситуация: GMV рекомендательной полки — $1M/мес, но incremental lift всего 15%. Значит, «настоящий» вклад рекомендаций — $150K, остальные $850K пользователи потратили бы в любом случае (через поиск, каталог). Это не значит, что рекомендации бесполезны — $150K инкрементального дохода может окупать всю команду ML. Но менеджмент должен видеть реальную картину, а не раздутые цифры.

Long-term vs short-term: ловушка кликбейта

Краткосрочные метрики (CTR, session time) и долгосрочные (retention, LTV) часто конфликтуют. Оптимизация краткосрочных метрик может убить долгосрочные — и наоборот.

Классическая ловушка: видеоплатформа оптимизирует watch time. Модель учится рекомендовать «залипательный» контент — shock videos, clickbait, бесконечные listicles. Watch time взлетает на 20% за первую неделю. Но через месяц 30-day retention падает на 5% — пользователи чувствуют, что тратят время впустую, и уходят. Потерять 5% retention для крупной платформы — это миллионы долларов в год.

Решение — разделить метрики на драйверы и контроллеры: • Драйвер — метрика, которую оптимизируем (CTR, time spent, conversion) • Контроллер (guardrail) — метрика, которая НЕ должна ухудшиться (retention, NPS, жалобы) A/B-тест считается успешным, только если драйвер вырос И все контроллеры в норме. Retention D7/D30 — главный контроллер для любых рекомендательных экспериментов.

Другие способы защиты от short-term ловушки: • Многоцелевая оптимизация: score = w₁·P(click) + w₂·P(satisfaction) + w₃·diversity. Satisfaction можно аппроксимировать через dwell time (сколько времени провёл после клика) • Reward shaping: в loss-функцию добавить delayed reward — вернулся ли пользователь завтра • Diversity и exploration: специально показывать разнообразный контент, чтобы не схлопнуть пузырь

OEC: Overall Evaluation Criterion — одна метрика, чтобы править всеми

У тебя десятки метрик: CTR, conversion, revenue, retention, latency, diversity, coverage... A/B-тест показывает: CTR +3%, conversion −1%, retention без изменений, latency +50ms. Катим или откатываем? Каждый стейкхолдер тянет в свою сторону.

OEC (Overall Evaluation Criterion) — единая композитная метрика, которая объединяет ключевые метрики в одно число. Если OEC вырос — катим. Если упал — откатываем. Никаких дебатов.

Как построить OEC: 1. Выбери компоненты — 3-5 метрик, которые отражают здоровье продукта (revenue, retention, satisfaction) 2. Определи веса — через бизнес-приоритеты. Если retention в 3× важнее CTR — дай ему вес 0.6 vs 0.2 3. Нормализуй — метрики в разных масштабах (CTR ~ 0.05, revenue ~ $10K). Z-score или min-max нормализация 4. Валидируй — OEC должен быть чувствителен к реальным улучшениям и устойчив к шуму 5. Добавь guardrails — даже при росте OEC, критичные метрики (latency, error rate) не должны деградировать

# Пример OEC для e-commerce рекомендаций
def compute_oec(metrics: dict) -> float:
    ""
    OEC = weighted sum of normalized metric deltas.
    Positive = experiment wins.
    ""
    weights = {
        'revenue_per_session': 0.40,  # главная метрика
        'retention_d7':        0.30,  # долгосрочное здоровье
        'ctr':                 0.15,  # engagement
        'diversity':           0.15,  # разнообразие рекомендаций
    }
    oec = sum(
        weights[m] * metrics[m]['z_score']
        for m in weights
    )
    return oec

# A/B тест результат
ab_result = {
    'revenue_per_session': {'z_score': 2.1},   # значимо выросло
    'retention_d7':        {'z_score': -0.3},   # чуть упало, незначимо
    'ctr':                 {'z_score': 1.8},    # выросло
    'diversity':           {'z_score': 0.5},    # чуть выросло
}
print(f"OEC = {compute_oec(ab_result):.2f}")  # 1.20 > 0 → катим

A/B-тестирование бизнес-метрик: sample size, duration, guardrails

A/B-тест для ML-модели отличается от тестирования цвета кнопки. Бизнес-метрики (revenue, retention) шумнее, дольше «набирают» статистическую значимость, и имеют отложенный эффект. Несколько ключевых особенностей:

Sample size. Revenue per session имеет огромную дисперсию: большинство сессий — $0, редкие — $500+. Для обнаружения 2% lift в revenue нужно в 5-10× больше сессий, чем для 2% lift в CTR. Предварительный power analysis — обязателен. Формула: n ≈ (z_{α/2} + z_β)² · 2σ² / δ², где δ — минимальный эффект, который хочешь обнаружить.

Duration. Revenue и retention имеют сильную сезонность: выходные vs будни, начало vs конец месяца, праздники. Минимальная длительность A/B-теста — 1-2 полных недели, чтобы покрыть все дни. Для retention D30 тест длится минимум 5-6 недель (30 дней + время на набор когорты).

Guardrail metrics. Основная метрика растёт — но не сломалось ли что-то ещё? • Latency p99 — модель не должна тормозить. +100ms latency = −1% conversion (Amazon) • Error rate — новая модель не падает чаще старой • Coverage — рекомендации покрывают достаточную долю каталога • Revenue per user (не session) — если RPS вырос, но количество сессий упало, общий revenue может не вырасти

Практические советы: • Используй variance reduction (CUPED, stratification) — это может сократить нужный sample size на 30-50% • Не подглядывай в результаты до набора полного sample size — peeking inflates false positive rate • Сегментируй результаты: новые vs вернувшиеся пользователи, mobile vs desktop. Средний эффект может скрывать разнонаправленные тренды • Novelty effect — новая модель может показывать lift первые дни просто из-за новизны. Дай тесту отработать минимум неделю

🎯 На собеседовании

Собираем всё вместе

ML-метрика → прокси → бизнес-метрика → деньги. Эта цепочка разрывается чаще, чем кажется: NDCG растёт, а revenue — нет. Причины: каннибализация (рекомендации «присваивают» органические продажи), кликбейт (CTR растёт, retention падает), отсутствие инкрементального эффекта.

Если запомнить одну вещь из этой ноды: всегда измеряй incremental lift через A/B-тест с guardrail-метриками. Никакой офлайн NDCG не заменит онлайн-эксперимент. Revenue-метрики шумные, retention медленный — закладывай достаточный sample size и длительность. OEC помогает принять решение, когда метрики конфликтуют.

Дальше на роадмапе: A/B-тестирование в ML углубит статистику экспериментов, а Multi-Stage Ranking покажет, как встроить бизнес-метрики в production pipeline ранжирования.