Спорить плохо, но раз уж всё равно все спорят, то почему бы не делать это конструктивно и продуктивно :)
Лайфхак как успешно убеждать датасайентистов в контексте результатов А/B тестирования. Работают такие аргументы:
не хватает метрик / разрезов, которые в эксперименте могут прокрасится в красный (стат. значимо ухудшится)
сетап эксперимента неверный
есть долгосрочный эффект, который в эксперименте не проявился
уменьшение метрики X может быть малым и "нестатзначимым", но по факту свидетельствовать о движении не в ту сторону
есть продуктовое видение, мы создаем новый паттерн взаимодействия, стратегически меняем или, наоборот, не хотим менять поведение пользователей и т.д. и т.п.
Есть и другие аргументы. Я собрал самые популярные из своего 12-летнего опыта A/B тестирования.
Далее подробнее.
Итак, вы – заказчик (product manager, product owner) и смотрите на результаты эксперимента, и вы понимаете, что по неким метрикам G и P выиграл вариант, в котором реализована крайне опасная хрень, которая может загубить продукт. Ваши аргументы?
Аргументы
Нужна новая метрика Х
Конечно, тут немедленно возникает вопрос "Что ж вы раньше молчали?!", но это неконструктивно, поэтому датасайентистам рекомендуется не "набрасывать".
Итак, нужна новая метрика Х. Типа да, метрики G и P зелёные (стат. значимо меняются в сторону улучшения; для примера, G = GMV, P = Profit), но вы забыли про метрику Х (например, X = количество вторых заказов у новичков), она важна, поэтому эксперимент пока не запускаем в продакшн (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: (C1) траты те же, GMV +3 ± 0.2 млн в день
отдел 2: (C2) траты те же, GMV +2 ± 0.2 млн в день
отдел 3: (C3) траты те же, GMV +1 ± 0.2 млн в день
Ваши выводы? Во-первых, давайте всё это шипнем, правильно? +6 млн GMV в день на дороге не валяется. А траты будут те же. Ну и ещё, наверное, нужно похвалить отдел 1 и пообещать им больше инвестиций в следующем месяце, а инвестиции в отдел 3 подуменьшить. Верно?
Абсолютно неверно! Точнее так: нет информации о том, что нужно делать, потому что здесь вы находитесь в ловушке "двухметричной неопределённости". Две метрики – GMV и Profit (в метрику Profit траты входят со знаком минус). Вы каждому отделу поставили задачу не ронять профит и растить GMV. Выглядит безобидно.
Но глаза могут открыться, если вы теперь (шипнув варианты C1, C2 и C3 выше) попросите каждый отдел тратить на 10% меньше или больше (не придумывая каких-то новых оптимизаций продукта).
Результаты по отделам могут оказаться такими:
отдел 1: (A1) траты -100K, GMV -900K; (B1) траты +100K, GMV +900K;
отдел 2: (A2) траты -100K, GMV -700K; (B2) траты +100K, GMV +700K;
отдел 3: (A3) траты -100K, GMV -1500K; (B3) траты +100K, GMV +1500K.
Переводится это так: отдел 3 лучше всех умеет превращать инвестиции в GMV. Но продукт и алгоритмы там уже настолько отшлифованы и оптимизированы, что просто так увеличить GMV без увеличения трат у них получается с большим трудом, но и не надо их мучать. Гораздо важнее уменьшить траты в отделах 1 и 2 и перенести их в отдел 3.
Таким образом, несмотря на то, что в отделе 1 и 2 знатно потрудились в последний месяц, они должны ещё улучшать свои алгоритмы и процессы, чтобы конкурировать с отделом 3.
Давайте всё распишем в числах:
Если мы перенесём 100К из отдела 1 в отдел 3, то мы заработаем GMV = +1500К - 900К = +600K
Если мы перенесём 100К из отдела 2 в отдел 3, то мы заработаем GMV = +1500К - 700К = +800K
Сколько мы заработаем, если мы сделаем оба действия? Неизвестно, так как непонятно с каким коэффициентом размена отдел 3 сможет потратить вторые 100К. В жизни каналы для инвестиций имеют такую природу, что с увеличением инвестиций выхлоп уменьшается. Первые 100К отдел 3 конвертирует в GMV с коэффициентом 15. Вторые 100К он может уже тратить с коэффициентом 14, и так далее, и например 6-е 100К он будет тратить с коэффициентом 10. И наоборот, забирая инвестиции из отделов 1 и 2 мы будем обнаруживать, что коэффициент delta(GMV) / delta(-Profit), с которым теряется GMV, растёт и, например, после переноса 500К из отдела 2 в отдел 3 может оказаться, что переносить следующие 100К не имеет смысла, так как в отделе 2 произойдет уменьшение GMV на 1M, а в отделе 3 увеличение GMV на 1М.
Дальше нужно подумать, чтобы понять важное:
Эффективное перераспределение трат между отделами произошло бы автоматически, если бы вы выбрали одну метрику
L = GMV + 10 * Profit
Убедитесь сами, что метрика L в отделах 1 и 2 вырастет, если они уменьшат траты, а у отдела 3 наоборот, метрика L будет расти, когда траты увеличиваются. Процесс перераспределения трат остановится, когда во всех отделах маржинальная эластичность дополнительных инвестиций (=delta(GMV) / delta(-Profit)) будет равна 10.
С метриками типа GMV и Profit это более менее понятно, люди оперируют понятием "коэффициент размена GMV на Profit" и даже знают, чему он равен. Но важно также понимать другое: если у вас есть пользовательские метрики типа
количество вторых покупок у новичков
время внутри приложения
среднее время между сессиями
количество положительных отзывов
...
то их тоже можно складывать с коэффициентами lambda_1, lambda_2, ... И если падение какой-то метрики в каком-то эксперименте не связано с багом в реализации, то можно рассуждать так: фичёй A я сильно подниму GMV и Profit и уроню метрику вторых покупок, а фичёй B я слегка уроню GMV и Profit и сильно подниму метрику вторых покупок и новичков. Шипаю обе фичи.
В идеале полезно в фиче B иметь параметр соответствующий силе применения фичи B. Тогда можно шипать фичи типа A, не думая про зелёность всех метрик G, P и X, но требуя зелёности метрики L:
L = G + lambda_1 * P + lambda_2 * X.
Периодически, можно смотреть на последние N шипнутых экспериментов и с помощью ручки в фиче B и других подобных возвращать баланс между метриками G, P и X.
Как-то так. Удачного A/B тестирования!
PS: Текст придуман, чтобы отравлять на него начинающих менеджеров, чья работа связана с A/B тестированием, да простят меня менеджеры :)
PPS: Интересное видео для неискушённых в A/B тестировании.
PPPS: См. полезный чеклист в статье Как устроен запуск экспериментов в ИТ-продукте на примере Joom
