Оценка эффекта релиза по истории метрики: causal impact без AB теста / forpes.ru

Главная
Оценка эффекта релиза по истории метрики: causal impact без AB теста

Оценка эффекта релиза по истории метрики: causal impact без AB теста

12.01.2026 13:55

Niuh 0 4600 Источник

Сценарий

У нас есть дата изменения . Например, поменяли алгоритм, цены, онбординг, выдачу, лимиты, антифрод, форму оплаты. Есть метрика которую мы наблюдаем каждый день или каждую неделю. Хотим понять:

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

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

Почему AB тест бывает недоступен

AB тест - лучший вариант, когда его можно провести корректно. Но в продуктовой практике регулярно встречаются случаи, когда AB теста нет:

изменение нельзя раскатить частично по пользователям или по трафику,
релиз уже выкатили сразу на всех, а вопрос про эффект возник постфактум,
есть только агрегированные данные, например дневные метрики по продукту,
в компании нет экспериментальной инфраструктуры, а решение все равно нужно принимать.

В таких задачах разумно использовать подход на основе временных рядов: построить прогноз того, как метрика должна была бы вести себя без изменения, и сравнить его с фактом.

Контрфакт в терминах бизнеса

Контрфакт (counterfactual) - это ответ на вопрос какой была бы метрика после даты X, если бы изменения не было.

Если обозначить:

- фактическое значение метрики в дату
$\hat{y}_t$ - оценка контрфакта в дату

то эффект в дату :

$effect_t=y_t-\hat{y}_t$

Дальше обычно считают:

средний эффект на периоде после изменения,
накопленный эффект на периоде после изменения,
относительный эффект в процентах относительно контрфакта.

Какие данные нужны

Чтобы метод работал стабильно, важна не только таблица, но и форма данных.

Частота:
1. дневная или недельная,
2. если дневные значения очень шумные, иногда полезно перейти на недельные.
Длина периода до изменения и после изменения:
1. на периоде до изменения должно быть достаточно точек, чтобы модель успела выучить зависимость метрики от факторов,
2. на практике хорошо иметь хотя бы несколько десятков точек до изменения,
3. период после изменения должен быть достаточно длинным, чтобы не спутать эффект с краткосрочным всплеском.
Полный календарь:
1. во временном ряду не должно быть пропусков по датам,
2. если пропуски есть, нужно явно определить правило заполнения или причину их появления.
Как ведет себя метрика, есть ли разрывы, скачки, смена режима, выраженная сезонность
Календарные эффекты:
1. день недели почти всегда влияет на бизнес-метрики,
2. праздники и распродажи часто дают скачки, которые полезно заносить отдельными признаками, если такие данные есть.

Как строится контрфакт

Для удобства прикладываю ссылку на репозиторий: https://github.com/Niuhych/trustworthy-experiments-core/tree/main

В репозитории используется простой и воспроизводимый вариант:

обучаем модель на периоде до изменения,
на периоде после изменения строим прогноз контрфакта,
сравниваем факт и прогноз, получаем эффект.

В качестве базовой модели используется гребневая регрессия (ridge regression). Она хорошо подходит, когда факторов несколько, они коррелируют между собой, и хочется избежать переобучения.

Фактическая метрика и оценка того, что было бы без изменения

Если - вектор факторов в дату , то оценка параметров на периоде до изменения выглядит так:

$\hat{\beta}=\arg\min_{\beta}\sum_{t\in T_0}(y_t-\beta_0-X_t^\top\beta)^2+\lambda\|\beta\|_2^2$

Дальше контрфакт на периоде после изменения:

$\hat{y}_t=\hat{\beta}_0+X_t^\top\hat{\beta},\quad t\in T_1$

Итоговые агрегаты

Средний эффект:

$\Delta_{avg}=\frac{1}{|T_1|}\sum_{t\in T_1}(y_t-\hat{y}_t)$

Накопленный эффект:

$\Delta_{cum}=\sum_{t\in T_1}(y_t-y^{cf}_t)$

Относительный эффект:

$\Delta_{rel}=\frac{\Delta_{cum}}{\sum_{t\in T_1}\hat{y}_t}$

Неопределенность: блочный бутстрап

Даже если контрфакт построен, остается вопрос: насколько надежна оценка эффекта.

Временные ряды часто имеют зависимость ошибок по времени. Если метрика сегодня выше ожиданий, завтра она тоже нередко будет выше ожиданий. Это означает, что обычные методы, которые предполагают независимые ошибки, могут дать слишком узкие доверительные интервалы.

Для этого можно использовать блочный бутстрап (block bootstrap), пример которого я привожу в репозитории:

после обучения модели на периоде до изменения считаются остатки,
затем формируются новые выборки остатков: берутся подряд идущие блоки длины kkk дней с повторениями,
для каждой такой выборки пересчитывается эффект,
по распределению эффектов строятся доверительные интервалы на уровне alpha.

Какой в этом практический смысл:

интервалы обычно становятся шире,
оценка неопределенности лучше соответствует данным, где есть зависимость по времени.

Полезно увидеть форму эффекта. Если весь эффект держится на 2-3 днях, это часто не продуктовый эффект, а шум или внешнее событие.

Выбор факторов

Факторы, которые подаются в модель, в литературе называются ковариатами (covariates). Их роль - объяснить колебания метрики, не связанные с изменением.

Для начала стоит взять за правило:

начать с 2-4 факторов,
брать те, которые логично связаны с метрикой и доступны на том же календаре.

Примеры для типовой продуктовой метрики:

трафик, например сессии:

Ковариата: сессии
активная аудитория:

Ковариата: активные пользователи
маркетинговые расходы или прокси маркетинга:

Ковариата: маркетинговые расходы
внешний индекс спроса, если он есть:

Ковариата: внешний индекс спроса

NB: Метрика и факторы на одном календаре. Если уже на этом уровне видны пропуски, разрывы или смена частоты, дальше причинный анализ будет показывать некорректные результаты.

Важное ограничение: фактор не должен быть прямым следствием изменения. Если фактор сам меняется из-за релиза, модель может частично спрятать эффект внутри контрфакта, и итоговая оценка станет заниженной.

Контрольные проверки качества

Ниже проверки, которые стоит сделать до того, как превращать цифры в продуктовые решения.

1) Качество прогноза на периоде до изменения

Если модель плохо описывает историю до изменения, ей нельзя доверять и после изменения.

Минимальные метрики:

на периоде до изменения,
(корень из средней квадратичной ошибки) на периоде до изменения, то есть насколько в среднем промахивается прогноз относительно факта, в тех же единицах, что и метрика.

2) Автокорреляция ошибок

Полезно посмотреть, насколько остатки модели похожи сами на себя со сдвигом на 1-7 дней. Это можно оценить через функцию автокорреляции.

Если автокорреляция на сдвиге 1 день очень высокая, то:

доверительные интервалы могут быть оптимистичными,
имеет смысл увеличить длину блока в блочном бутстрапе.

3) Устойчивость к выбору окна

Простой тест:

немного сдвинуть границы периода до изменения и пересчитать эффект.

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

4) Плацебо даты

Полезный тест, который снижает риск собственной ошибки.

Идея:

выбрать несколько дат внутри периода до изменения,
"сделать вид", что изменение произошло в одну из этих дат,
посчитать накопленный эффект для каждой плацебо даты.

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

Типичные эффекты, которые получаются, если подставлять ложные даты изменения в периоде до изменения

Краткое резюме

Если AB тест недоступен, оценка эффекта по истории метрики может быть разумной альтернативой, но только если помимо самой метрики есть несколько сопутствующих рядов, которые объясняют ее колебания, и если пройдены проверки качества (качество на периоде до изменения, устойчивость к окнам, плацебо даты).
Контрфакт - это основа: без хорошего описания периода до изменения нельзя доверять выводам после изменения;
Блочный бутстрап помогает реалистичнее оценить неопределенность в данных, где есть зависимость по времени;
Плацебо даты и устойчивость к окну - быстрые проверки, которые сильно повышают доверие к результату.

В этой статье мы рассмотрели, как оценивать эффект продуктового изменения по истории одной метрики: строим контрфакт на период после изменения, считаем эффект и проверяем устойчивость вывода через качество модели на периоде до изменения, плацебо даты и чувствительность к окну.

Дальше будет более частый сценарий: изменение затронуло не всех. Например, релиз раскатан на часть географий, сегментов или кластеров, и у нас есть несколько групп, которые можно использовать как контроль. Тогда вместо одной временной линии у нас появляется набор временных линий: одна и та же метрика, но отдельно по каждой группе, и на каждом шаге времени мы видим сразу несколько значений.

Такой формат данных часто называют панельным (panel data). Во второй части перейдем к этому случаю и разберем два базовых инструмента практики - синтетический контроль и diff-in-diff, а также проверки, которые помогают не перепутать эффект релиза с различиями между группами.