Как предсказывать долгосрочный эффект A/B теста раньше: прокси-метрики и ловушка регрессии

Обновленная и расширенная версия статьи: исправлено изложение и добавлена практическая симуляция.

В продуктовых экспериментах нередко возникает следующая ситуация: бизнесу важна долгосрочная или малочувствительная метрика, но оценить эффект на такие метрики в рамках короткого A/B-теста сложно.

Например, нам могут быть интересны метрики:

конверсия в бронирование (редкая, а потому малочувствительная метрика)
LTV (требует длинного окна наблюдения)

Но эксперимент хотелось бы завершить за две-три недели. Что делать?

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

В этом случае на помощь могут прийти proxy-метрики – более ранние и более чувствительные показатели, по которым пытаются судить о будущем изменении North Star метрики (NSM).

В этой статье я хочу фактически разобрать работу от Netflix Learning the Covariance of Treatment Effects Across Many Weak Experiments, в которой авторы делятся, как использовать историю множества A/B-тестов для построения линейного proxy-индекса, почему наивная регрессия по оцененным эффектам может обмануть и как отделить настоящую связь экспериментальных эффектов от общего статистического шума.

Идея

Допустим, мы решили, что хотим изменить логику пуш-уведомлений в продукте. Уже через неделю без особых проблем можно измерить:

конверсию в открытие пушей
отключения уведомлений
клики по кнопке «Купить»

Но реальный интерес представляет, например, конверсия в покупку в течение 90 дней.

Основная идея в статье следующая:

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

Тогда в новом эксперименте можно быстро оценить эффект на комбинацию коротких метрик (в дальнейшем будем эту комбинацию называть proxy-индексом) и использовать этот индекс как ранний сигнал долгосрочного результата.

$h(S) = 0.4 \cdot \text{полезные сессии} + 0.8 \cdot \text{клики} - 1.2 \cdot \text{отклю чения уведомлений}$

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

Здесь возникает вопрос:

Как убедиться, что экспериментальные изменения коротких метрик действительно отражают экспериментальные изменения North Star?

И откуда взять веса 0.4, 0.8, -1.2?

Почему нельзя просто обучить модель на пользователях?

Первое, что приходит в голову – давайте обучим модель, которая на основе данных по пользователям, используя другие метрики, предсказывает нашу метрику. Вот и получится какой-то вектор с коэффициентами влияния каждой метрики на North Star.

Коротко: это плохой вариант, потому что модель отвечает на вопрос: «Кто, судя по своему поведению, скорее совершит покупку?» А нам нужен ответ на другой вопрос: «Если продуктовый эксперимент увеличит число поисков или кликов, вырастет ли из-за этого число покупок?»

Более подробно

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

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

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

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

А что тогда?

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

Пусть у нас есть множество исторических тестов, и для каждого из них существует:

Истинный эффект на короткие proxy-метрики
Истинный эффект на долгосрочную North Star метрику

Пример

Эксперимент	Эффект на поиски	Эффект на клики	Эффект на конверсию в покупку в течение 90 дней
A	+2%	+1%	+0.4%
B	-1%	0%	-0.2%
C	+3%	+2%	+0.7%
D	+2%	-1%	0%

Мы хотим найти комбинацию proxy-метрик, которая дает приближенный эффект для North Star метрики.

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

Пример

Представим, что на уровне пользователей proxy-метрики и North star метрика положительно коррелируют.

Например, активные пользователи одновременно:

делают больше кликов
приносят больше долгосрочной выручки

В одном эксперименте в treatment случайно может попасть чуть больше активных пользователей. Тогда одновременно будут завышены обе оценки: эффект на proxy-метрики и эффект на North Star метрику.

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

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

Еще больше исторических экспериментов не решают проблему

Можно подумать, что если собрать сотни A/B-тестов, случайный шум просто усреднится. Но шум возникает внутри каждого эксперимента и систематически попадает в общую ковариацию.

Поэтому бОльшее число тестов помогает точнее оценить не истинную связь, а ее смещенную версию. Чтобы смещение уменьшилось само, нужно увеличивать размер каждого эксперимента, либо отдельно оценивать и вычитать вклад шума.

Подведем итог: лучше строить модели регрессии, где объектами являются исторические эксперименты. В качестве признаков модели – proxy-метрики, а в качестве целевой переменной – North Star метрика.

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

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

Решение – восстанавливать ковариацию истинных эффектов. Как это делать?

В статье авторы разбирают несколько методов для решения проблемы, но я остановлюсь подробнее только на основных, более подходящих методах.

JIVE

Jackknife Instrumental Variables Estimation использует leave-one-out подход.

Мы по очереди исключаем каждого пользователя и пересчитываем эффект эксперимента без него. После этого используем данные исключенного пользователя отдельно. Такой прием помогает убрать искусственную связь, возникающую из-за того, что одни и те же наблюдения участвуют сразу в обеих частях расчета.

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

Total Covariance

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

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

После такой коррекции авторы рассчитывают веса коротких метрик. В результате получается единый proxy-индекс. Соответственно, в новом A/B-тесте нужно измерить эффекты на эти proxy-метрики и объединить их с найденными весами. Получившееся значение используется как оценка возможного долгосрочного эффекта на North Star.

Техническая часть, которая за этим скрывается

Случай одной прокси-метрики (для простоты)

Пусть для каждого исторического эксперимента мы знаем оценённые эффекты:

Ts – эффект на короткую метрику
Ty – эффект на North Star метрику

Обычная регрессия оценила бы коэффициент так:

$\widehat{\beta}_{\text{naive}} = \frac{ \operatorname{Cov} \left( Ts, Ty \right) }{ \operatorname{Var} \left( Ts \right) }.$

Но и числитель, и знаменатель содержат шум. Поэтому Total Covariance сначала очищает их:

$\widehat{\beta}_{TC} = \frac{ \operatorname{Cov} \left( Ts, Ty \right) - \operatorname{Cov} \left( \varepsilon_S, \varepsilon_Y \right) }{ \operatorname{Var} \left( Ts \right) - \operatorname{Var} \left( \varepsilon_S \right) }$

То есть логика такая:

Из наблюдаемой совместной изменчивости вычитаем совместную изменчивость ошибок, а из наблюдаемого разброса прокси – разброс ее ошибки. После этого считаем обычный коэффициент регрессии.

Небольшой пример

Допустим, по историческим экспериментам получили:

$\begin{aligned} \operatorname{Cov} \left( {Ts}, {Ty} \right) &= 0.006,\\ \operatorname{Var} \left( {Ts} \right) &= 0.010. \end{aligned}$

Наивная регрессия даст:

$\widehat{\beta}_{\text{naive}} = \frac{0.006}{0.010} = 0.6$

Но мы оценили, что из-за случайного состава групп возникли:

$\begin{aligned} \operatorname{Cov} \left( \varepsilon_S, \varepsilon_Y \right) &= 0.003,\\ \operatorname{Var} \left( \varepsilon_S \right) &= 0.004. \end{aligned}$

Тогда Total Covariance даст:

$\widehat{\beta}_{TC} = \frac{0.006-0.003}{0.010-0.004} = 0.5$

=> Наивная модель приняла часть общего шума за полезный сигнал и завысила коэффициент.

Откуда берется оценка шума

Предположим, в эксперименте всего n пользователей:

n / 2 в treatment
n / 2 в control

Пусть Ω описывает, как метрики связаны между собой на уровне пользователей.
Эффект эксперимента – это разность средних treatment и control. Ковариация ошибки этой разности равна:

$\operatorname{Var}(\varepsilon) = \frac{\Omega}{n/2} + \frac{\Omega}{n/2} = \frac{4}{n}\Omega.$

Именно поэтому Total Covariance вычитает величину 4Ω / n.

Ω берется из данных отдельных пользователей внутри исторических A/B-тестов. Матрицу Ω оценивают по пользовательским данным из экспериментов. Она описывает разброс выбранных метрик между пользователями и их связь друг с другом. Зная эту структуру и размеры treatment и control, можно оценить, какая часть связи между экспериментальными эффектами возникла только из-за случайного состава групп.

Ограничения Total Covariance

Когда Total Covariance работает хорошо

Эксперименты имеют сопоставимую структуру пользовательского шума
Исторические тесты дают достаточно разнообразные эффекты
Связь коротких метрик с North Star переносится на новые изменения
В proxy-метриках учтены основные негативные последствия

Когда достаточно одного proxy-индекса

Простой сценарий выглядит так:

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

В таком случае можно объединить исторические эксперименты, один раз оценить общую поправку на шум и получить один набор весов. Затем этот proxy-индекс используется в следующих тестах.

Когда уже не достаточно

1. Шум может быть устроен по-разному

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

Например, один тест проводился только на iOS, другой – только на Android. Или один тест шел в высокий сезон, а другой – в период, когда покупок было значительно меньше. Даже при одинаковом правиле входа пользователей в эксперимент (например, все пользователи с сессиями), распределения кликов, сессий и покупок могут различаться.

Если различия большие, есть два основных решения.

Первое – строить отдельные индексы для достаточно однородных наборов тестов. Например, отдельно для iOS и отдельно для Desktop.

Второе – использовать метод JIVE. Этот метод не предполагает, что пользовательский шум одинаков во всех тестах. Он поочередно исключает каждого пользователя из расчета экспериментального эффекта и отделяет общую реакцию на treatment от индивидуального шума. В итоге JIVE тоже оценивает один набор весов по всей выбранной истории, а не отдельные веса для каждого теста. Его недостаток – необходимость работать с пользовательскими данными всех экспериментов и существенно больший объем вычислений.

2. Одинаковый рост метрики может иметь разный смысл

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

3. Исторические эксперименты должны давать достаточно разные эффекты

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

Например, если при росте кликов на 1% сессии во всех тестах всегда растут ровно на 2%, невозможно определить, какая из этих метрик действительно связана с North Star. Математически для оценки весов нужно, чтобы эффекты коротких метрик содержали достаточно независимого разнообразия.

В такой ситуации можно:

убрать почти дублирующие друг друга показатели
собрать больше исторических экспериментов
строить более простой индекс из меньшего числа метрик

Когда proxy действительно заменяет North Star

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

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

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

Если в proxy входят только полезные сессии, индекс увидит положительную часть эффекта, но пропустит возможный вред. Поэтому может возникнуть ситуация, когда proxy растет, а настоящая North Star снижается.

=> proxy-метрики безопаснее использовать вместе с защитными метриками: отключениями уведомлений, удалениями приложения, жалобами и другими возможными негативными последствиями.

Практика и симуляции

Чтобы проверить метод в условиях, где правильные веса известны заранее, я собрал синтетическую историю A/B-тестов в Jupyter Notebook на основе статьи. К истинным экспериментальным эффектам добавляется связанный статистический шум, после чего обычная регрессия и Total Covariance пытаются восстановить исходные веса proxy-индекса.

Более подробно изучить симуляции можно здесь: тык.

Сравнение методов в разных сценариях

На визуализации ниже показано, насколько точно методы восстанавливают заданные в симуляции веса proxy-индекса:

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

Более детально

На графике сравнивается, насколько точно разные подходы восстанавливают заранее заданные веса proxy-индекса в трех сценариях.

По вертикальной оси показана ошибка восстановления весов:

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

Каждый сценарий симулировался 200 раз. Высота столбца – медианная ошибка, а черные линии показывают диапазон от 25-го до 75-го перцентиля. То есть они отражают, насколько результат менялся между разными запусками симуляции.

Сравниваются три варианта:

Naive – обычная регрессия по зашумленным оценкам эффектов
Total Covariance – регрессия после поправки на статистический шум
Идеальные данные без статистического шума – недоступный в реальности ориентир, который использует истинные эффекты экспериментов из симуляции

1. Весь эффект проходит через proxy

Когда выбранные метрики отражают весь эффект на North Star, правильные веса можно восстановить почти идеально. Naive сильно ошибается из-за статистического шума, а Total Covariance сильно приближается к правильному результату: ошибка снижается с 0,33 до 0,10.

2. Неучтенные эффекты не связаны с proxy

Выбранные proxy-метрики отражают не все влияние эксперимента на North Star. Однако эксперименты, сильнее увеличивающие proxy-метрики, не создают одновременно более сильный скрытый вред или пользу. В этом случае пропущенные эффекты добавляют неопределенность, но не искажают найденную зависимость. Поэтому Total Covariance по-прежнему работает заметно лучше Naive: ошибка составляет 0,11 против 0,34.

3. Неучтенные эффекты связаны с proxy

Когда скрытый эффект систематически меняется вместе с proxy-метриками, все подходы ошибаются примерно одинаково. Даже идеальные данные дают ошибку 0,45. Значит, проблема уже не в статистическом шуме: по имеющимся метрикам невозможно отделить влияние proxy от пропущенного механизма.

Вывод

Самая сложная часть – найти комбинацию proxy-метрик, экспериментальные изменения которой позволяют судить об экспериментальном изменении долгосрочной North Star.

Обычной пользовательской корреляции для этого недостаточно. Даже наивная регрессия по результатам исторических A/B-тестов может ошибаться, потому что наблюдаемые эффекты содержат общий случайный шум.

Total Covariance пытается оценить и вычесть второй компонент, но даже идеально построенный proxy-индекс не становится автоматически полной заменой North Star. Для этого все важные пути влияния продукта на North Star должны отражаться в выбранных proxy-метриках. Поэтому proxy-индекс лучше воспринимать как более быстрый сигнал о возможном долгосрочном эффекте, основанный на истории экспериментов. Такой сигнал, конечно, полезен для более быстрых решений, но требует регулярной проверки на новых экспериментах и периодического измерения North Star напрямую.

Очень важное сообщение: экспериментируйте! И обязательно делитесь результатами своих экспериментов 🙂

Полезные материалы

ссылка на оригинал статьи https://habr.com/ru/articles/1066638/