Как спорить про результаты A/B тестирования

Спорить плохо, но раз уж всё равно все спорят, то почему бы не делать это конструктивно и продуктивно 🙂

Лайфхак как успешно убеждать датасайентистов в контексте результатов А/B тестирования. Работают такие аргументы:

• не хватает метрик / разрезов, которые в эксперименте могут прокрасится в красный (стат. значимо ухудшится)

• сетап эксперимента неверный

• есть долгосрочный эффект, который в эксперименте не проявился

• уменьшение метрики X может быть малым и «нестатзначимым«, но по факту свидетельствовать о движении не в ту сторону

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

Есть и другие аргументы. Я собрал самые популярные из своего 12-летнего опыта A/B тестирования.

Далее подробнее.

Итак, вы – заказчик новой фичи (product manager) и смотрите на результаты эксперимента, и вы понимаете, что по метрикам G и P выиграл вариант, в котором реализована крайне опасная хрень, которая может загубить продукт. Ваши аргументы?

Аргументы

Нужна новая метрика Х

Конечно, тут немедленно возникает вопрос «Что ж вы раньше молчали?!», но это неконструктивно, поэтому датасайентистам рекомендуется не «набрасывать».

Итак, нужна новая метрика Х. Типа да, метрики G и P зелёные (стат. значимо меняются в сторону улучшения), но вы забыли про метрику Х, она важна, поэтому эксперимент пока не запускаем в продакшн (aka шипаем). Мы, датасайентисты, в ответ можем

• предложить другую метрику Y, которая лучше Х

• сказать, что похожая метрика Y уже есть и она зелёная

• сказать что метрика X не прокрасится за год и нужна чувствительная прокси метрика

• …

И вы должны что-то суметь нам ответить.

Вообще полезно до запуска эксперимента назвать все метрики, на которые потом вы (заказчик) будете смотреть. Этот список может помочь разработчику/дизайнеру/проджекту лучше понять цель мероприятия, лучше проработать детали реализации, сделать необходимые защиты от падения той или иной метрики.

Важен разрез Х

Это похоже на новую метрику X. Старая метрика G, но в разрезе X – это и есть новая метрика. Например, есть важный разрез «пользователи с мобильников», и если на мобильниках метрика G падает – то плохо, не шипаем. И мы уходим изучать разрезы, анализировать падение метрики и думать, как реализовать фичу, чтобы она в важном разрезе не роняла важную метрику.

Хороший вопрос: как не оказаться в ситуации, когда у тебя 100 разрезов и 100 соответствующих значений метрики G и случайные 5 из них всегда красные (стат. значимо ухудшились)? Ответ такой – да, разрезы – это запрещённый приём, но, видимо, есть исключения типа «новые пользователи», «ядро аудитории» и т.п., так как мы растим клиентскую базу и беспокоимся о лояльных пользователях, поэтому в этих разрезах всё должно быть хорошо. Все дополнительные разрезы должны добавляться через боль «подумай 10 раз» и обсуждения.

Сетап эксперимента невалиден

Сетап эксперимента – это способ проведение эксперимента: как разделили пользователей на группы (aka сплиты) – по логинам, по устройствам, по IP адресу или как-то хитрее, какие изменения пользователи увидели / почувствовали, и как это зависит от статуса пользователя (залогинен или нет, с мобильника или с десктопа), насколько вариант B соответствует тому, как всё будет в продакшене, если вариант будет одобрен и шипнут на всех.

«Сетап эксперимента невалиден» – это прекрасный аргумент, который меня радует, потому что говорит о том, что заказчик хорошо разбирается в вопросе. Тут надо объяснить нам, в чём может быть засада, и мы уходим переделывать эксперимент. Прекрасно, если вы сами можете предложить правильный сетап. Если нет варианта правильного сетапа, то нужно либо довольствоваться тем, что есть, и согласиться с результатами, либо дать задание придумать такой сетап, который позволит с помощью данных честно проверить некую конкретную гипотезу, чтобы перестать беспокоиться о неидеальности исходного сетапа.

Есть долгосрочный эффект

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

• либо предложим провести долгосрочный эксперимент для выяснения правды, либо в прошлом поищем уже что-то похожее и согласимся;

• либо предложим метрику Х, которая этот долгосрочный эффект гораздо раньше поймает, то есть сведём задачу к пункту «Нужна новая метрика Х».

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

Нет стат. значимости для важной метрики X

Уменьшение метрики X может быть малым, меньше MDE (minimal detectible effect), но при этом недопустимым с точки зрения бизнеса (свидетельствовать о движении не в ту сторону и говорить о негативных отложенных эффектах).

Например, X = «количество положительных отзывов после покупки» или «число переходов к конкуренту». Тут нужно оценивать критичные значения метрики и продлять эксперимент настолько, чтобы быть уверенным, что метрика не ухудшилась ниже критического уровня или даже улучшилась.

Продуктовое видение

Продуктовое видение – очень даже валидный аргумент. Сложно представить себе Стива Джобса, который через A/B тестирование доказывает, что 1 кнопка лучше 3-х. Но продуктовое видение должно быть описано, прогнозируемые стратегические отложенные эффекты названы и оценены опять же метриками (пусть грубо, пусть из головы), полезно обозначить дополнительные сопутствующие изменения и решения, которые поддержат предлагаемый вариант. Должен быть текст и некий кворум проголосовавших ЗА.

Все эти сложности нужны для того, чтобы избежать ситуации, когда в каждом втором эксперименте возникает продуктовое видение не запускать зелёное или запускать красное. Тогда проще зафиксировать HIPPO-driven development подход (Highest Paid Person’s Opinions), а A/B тесты использовать исключительно для обнаружения багов реализации, а не для тестирования гипотез. Но вроде бы это не про нас с вами, хабровчане, да?

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

Про одну метрику, транзитивность и эффективность компании

Это сложный раздел про нормальные критерии приёмки вообще, про размены между метриками и про то, что, вообще говоря, нужно иметь одну численную метрику (=комбинации нескольких), иначе можно оказаться в глупых ситуациях с невозможностью двигаться в сторону улучшения продукта.

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

Теперь сложнее. Пусть у вас критерий «метрики G и P растут / не падают». Тогда есть множество вариантов, когда в сплите B одна метрика падает, а другая растёт. И вы в итоге не шипаете такой вариант B.

Забавно, что находясь в B, вы не шипнули бы и вариант A. То есть то, какой вариант в проде, решил случай – могло так статься, что вы сначала оказались бы в проде в варианте B, и вариант A c вашим критерием никогда бы не шипнулся. Я называю это «двухметричной неопределённостью»  или «маленькая – но по 3, большая – но по 5».

Есть решение от учёных – перейти к одной метрике L = G + lambda * P. Значение lambda добывается с помощью паяльника и времени.

Необходимость уметь разменивать одну метрику на другую (допускать падение каких-то метрик за счёт роста других) это не просто ради математической красоты, когда пространство вариантов имеет линейную упорядоченность (любые два варианта сравнимы, то есть мы можем сказать «кто лучше», и если A лучше B, а B лучше C, то A лучше C). Это ещё и про повышение эффективности компании в целом.

Представьте себе три отдела некой компании – отдел дистрибуции (реклама в интернет), отдел маркетинга (промокоды и купоны), отдел ценообразования. Все три отдела умеют тратить деньги (в последнем отделе могут просто уменьшать цену – это тоже переводится в траты) и растить GMV (оборот). И представьте, что они втроём проводят независимые эксперименты и у каждого отдела есть траты 1 млн руб. в день, их не нужно увеличивать, но нужно растить GMV. В каждом отделе придумали какое-то своё улучшение относительно контроля и эксперименты показали следующее:

• отдел 1: траты те же, GMV +3 ± 0.2 млн в день

• отдел 2: траты те же, GMV +2 ± 0.2 млн в день

• отдел 3: траты те же, GMV +1 ± 0.2 млн в день

Ваши выводы? Во-первых, давайте всё это шипнем, правильно? +6 млн GMV в день на дороге не валяется. А траты будут те же. Ну и ещё, наверное, нужно похвалить отдел 1 и пообещать им больше инвестиций в следующем месяце, а инвестиции в отдел 3 подуменьшить. Верно?

Абсолютно неверно! Точнее так: нет информации о том, что нужно делать, потому что здесь вы находитесь в ловушке «двухметричной неопределённости». Две метрики – GMV и Profit. Вы каждому отделу поставили задачу не ронять профит и растить GMV. Выглядит безобидно. Но глаза могут открыться, если вы попросите каждый отдел тратить на 10% меньше или больше.

Profit = const — траты.

Результаты по отделам (расположенным в случайном порядке, анонимизированные специально для заказчика) могут оказаться такими:

• отдел 1: (A1) Profit +100K, GMV -900K; (B1) Profit -100K, GMV +900K;

• отдел 2: (A2) Profit +100K, GMV -700K; (B2) Profit -100K, GMV +700K;

• отдел 3: (A3) Profit +100K, GMV -1500K; (B3) Profit -100K, GMV +1500K.

Переводится это так: отдел 3 лучше всех умеет превращать инвестиции в GMV. Но продукт и алгоритмы там уже настолько отшлифованы и оптимизированы, что просто так увеличить GMV без увеличения трат невозможно. Однозначно нужно уменьшить инвестиции в отделах 1 и 2 и перенести их в отдел 3. Несмотря на то, что в отделе 1 знатно потрудились в последний месяц, они должны ещё улучшать свои алгоритмы и процессы, чтобы конкурировать с отделом 3.

Дальше нужно подумать, чтобы понять важное:

Эффективное перераспределение трат между отделами произошло бы автоматически, если бы вы выбрали одну метрику

L = GMV + 10 * Profit

С метриками типа GMV и Profit это более менее понятно и наглядно, так как люди более менее понимают, что есть размен GMV vs Profit и даже знают, чему он равен. Но важно понимать, что если у вас есть пользовательские метрики типа

• количество вторых покупок у новичков

• время внутри приложения

• среднее время между сессиями

• количество положительных отзывов

• …

то их тоже можно складывать с коэффициентами lambda_1, lambda_2, … И если падение какой-то метрики в каком-то эксперименте не связано с багом в реализации, то можно рассуждать так: фичёй B я сильно подниму GMV и Profit и уроню метрику вторых покупок, а фичёй C я слегка уроню GMV и Profit и сильно подниму метрику вторых покупок и новичков. Шипаю обе фичи.

Фичи B может не быть на столе, но недавно что-то похожее вы шипнули, и тогда это можно зачесть. Или что-то похожее на B вы придумаете скоро, поэтому A можно шипать. Удобно, когда у вас всегда есть под рукой некоторый параметр, соответствующий силе включения фичи B. Это позволяет просто шипать варианты типа A в комбо с изменением параметра в B. А ещё лучше – отказаться от концепции необходимости комбо для того, чтобы всё было зелёным – вместо этого просто делайте регулярный анализ последних N запусков и подкручивайте параметр фичи B, только если случился перекос.

Как-то так. Удачного А/Б тестирования!

PS: Текст придуман, чтобы отравлять на него начинающих менеджеров, чья работа связана с A/B тестированием, да простят меня менеджеры 🙂

PPS: Интересное видео для неискушённых в A/B тестировании.

PPPS: См. полезный чеклист в статье Как устроен запуск экспериментов в ИТ-продукте на примере Joom