Условие

Что такое OEC (Overall Evaluation Criterion), как его строить и чем он отличается от guardrail-метрик?

Решение

Подход

OEC — одна (composite) метрика, выбранная для принятия решения о запуске. Часто это линейная комбинация бизнес-критичных метрик:

OEC = w_1·M_1 + w_2·M_2 + ... + w_k·M_k

где w_i отражают долгосрочную ценность каждой метрики (часто из CLV-модели).

Guardrail — метрика, которая не должна ухудшиться (latency, error rate, churn). Это ограничение, а не часть OEC.

Разделение: OEC → maximize, guardrails → constrain. Решение: «launch if ΔOEC > 0 (значимо) и все guardrails в норме».

Пример

# OEC для маркетплейса
OEC = (
    1.0 * revenue_per_user
    + 0.5 * sessions_per_user_log
    - 0.3 * refunds_per_user
)
 
# Guardrails (не входят в OEC)
guardrails = {
    'p99_latency_ms': {'max': 800},
    'crash_rate': {'max': 0.005},
    'churn_30d': {'max': 0.18},
}
 
def decide(ate_oec, p_oec, guardrail_values):
    if p_oec > 0.05 or ate_oec <= 0:
        return 'no launch'
    for name, val in guardrail_values.items():
        if val > guardrails[name]['max']:
            return f'no launch: {name} breach'
    return 'launch'

Как выбирать веса OEC

Из CLV-модели: коэффициент при метрике = ∂CLV/∂метрика.
Из исторических корреляций с долгосрочной retention.
Через ranking метрик командой и нормализацию.

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

OEC, который меняется каждый квартал, бесполезен — пропадает сравнимость экспериментов.
Если в OEC включён guardrail с большим весом, он может «компенсироваться» бизнес-метрикой — плохо. Latency должен оставаться ограничением.
OEC чувствителен к шкалам метрик — нормализуйте (z-score / log).
Без OEC: команда смотрит на 10 метрик и выбирает «удобную» — это классический cherry-picking.

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

OEC — одна композитная метрика для принятия решения (maximize), линейная комбинация ключевых метрик с весами из CLV-модели. Guardrails — ограничения (constrain), не входят в OEC. Launch ⇔ ΔOEC > 0 значимо И все guardrails в норме.

Сценарий A/B: OEC vs guardrail metrics