• неверная конфигурация теста;
• плохой генератор частот;
• неверный статистический критерий;
• проблема подглядывания;
• отсутствие пост-анализа;
• принятие решения, когда нельзя отвергнуть нулевую гипотезу.
Неверная конфигурация теста – самая частая проблема. Допустим, вы придумали гипотезу, у вас есть метрика, вы написали техническое задание на проведение теста. Если это ML-модель, то вы заранее провели офлайн-тесты – все было хорошо. После реализации теста и выкладки его в рабочую систему его нужно обязательно проверить. Если это сайт, то прощелкать нужные ссылки, проверить, что обеим группам показываются нужные версии страниц. А теперь представим, что тест запущен и в нем есть ошибка. Прошел месяц, пора считать результаты. Наше сознание заставляет нас искать ошибки, если результаты получились плохими, и просто радоваться, если результаты положительные. Но если в тесте была ошибка, то много времени было потрачено впустую и тест придется перезапускать. У меня на практике такое было сплошь и рядом. В результате мы в Retail Rocket разработали целый бизнес-процесс по запуску тестов с инструкциями по проверке. Такие ошибки очень дорого обходятся.
Плохой генератор случайных чисел для разделения всех пользователей на тестовую и контрольную группы тоже может быть проблемой. Надежный способ обнаружения такой проблемы – A/A-тесты. Второй вариант – симуляция. Тогда вам нужно точно повторить код разработчиков, который назначает сегменты, и проверить его работу на старых логах пользователей, то есть произвести имитацию A/B-теста. С такими генераторами часто возникают проблемы, поэтому команда инженеров написала свой вариант и выложила его исходный код в сеть [85].
Неверный критерий тоже может дать свою погрешность. Я бы рекомендовал в целях проверки делать симуляционные тесты выбранного статистического критерия. Это можно делать как с помощью генераторов распределений, так и с помощью уже имеющихся логов действий пользователя (если есть). Например, сделав два случайных генератора с одинаковыми исходными данными, нужно убедиться, что статистический критерий не показывает значимость. Затем сделать небольшую разницу между генераторами и убедиться, что статистическая значимость появилась. Также рекомендую сделать анализ мощности – сколько данных нужно, чтобы этот критерий показал статистическую значимость на какой-то минимальной для вас важности. Например, вы готовы внедрить новое улучшение только в том случае, если оно улучшает метрику на 1 %. Тогда вы делаете два генератора с этой разностью и моделируете работу критерия, чтобы понять, сколько точек данных вам нужно, чтобы заметить эту разницу. Это и будет вашим минимальным объемом выборки данных.
Проблема подглядывания за результатами теста лично мне хорошо знакома. Она возникает, когда тест не набрал еще необходимых данных, а мы уже пытаемся увидеть его результаты. Статистическая значимость теста – это тоже случайная величина, и она «скачет» в первое время после запуска теста. Так происходит и на симуляциях тестов, и в реальных условиях. Я столкнулся с этим впервые в компании Ostrovok.ru, когда А/Б-тесты были выведены на дашборды офисных мониторов. Мне позвонил CEO с вопросом, почему результаты значимости недавно запущенного теста прыгают туда-сюда. Поэтому если вы примете решение в этот момент, признав тест успешным, то совершите ошибку, так как через некоторое время тест «устаканится» и будет показывать отсутствие статистической значимости. Я считаю, что единственный способ решить проблему подглядывания – определить минимально детектируемую разницу в метриках, которая вас устроит. По ней с помощью калькулятора мощности или симуляций вычисляется нужный объем выборки. И именно после достижения нужного объема данных можно смотреть на результат и принимать решения. Здесь вы столкнетесь с дилеммой – если разница слишком мала, то понадобится очень много данных, что плохо для бизнеса. Потому что чтобы получить много данных, придется долго ждать – тратить время. Рекомендую понять, сколько времени вы готовы ждать, и уже исходя из этого определить минимально детектируемую разницу. Минимальная длительность теста также ограничена бизнес-циклом принятия решений клиентами. Например, если мы знаем, что среднее время принятия решения о покупке составляет три дня, то тест должен идти не меньше двух бизнес-циклов – шесть дней. До этого времени за тестом можно приглядывать, но только с целью обнаружить пропущенные технические ошибки.
Хороший пост-анализ эксперимента гипотезы может помочь понять, что еще можно сделать для улучшения метрики. Как я уже писал, желание обнаружить ошибку, когда тест новой версии продукта провалился, естественно, как и его отсутствие, когда тест выигран. В Retail Rocket мы действительно находили в тестах ошибки не только технического характера, но и идейного. Для этого обычно применяли сводные таблицы и искали проблемы во множестве срезов. Очень приятное чувство, когда находишь ошибку или придумываешь модификацию гипотезы и побеждаешь в следующем тесте. Это можно делать и для положительных тестов, чтобы искать новые идеи по улучшению продукта.
А/А-тесты
Впервые про A/A-тесты я услышал от Ди Джея Патила – до этого я никогда к ним не прибегал. А/А-тест – это проверка последней мили, всего того, что вы сделали для теста: генератора случайных чисел, схемы сбора данных и выбранного статистического критерия для метрики. Сам тест запускается с реальным делением аудитории на две части, но в контрольной и тестовой группах используется одна и та же версия продукта. В финале вы должны получить сходящийся тест без опровержения нулевой гипотезы, так как версия продукта одна и та же.
Первое, что нужно проверить, – насколько хорошо работает генератор случайных чисел, по значениям которого будет происходить разделение на группы в тесте. Само назначение на группы можно делать двумя способами: через назначение случайного числа и через хеширование информации об объекте. Когда пользователь посещает сайт, обычно ему в куки пишут его идентификационный номер. Этот номер используется для того, чтобы узнать пользователя при повторном посещении. Для A/B-тестов этот номер хешируется, то есть его превращают из текста в число, далее берут две или три последние цифры для распределения по группам: 00–49 контрольная группа, 50–99 тестовая. Похожий принцип реализован в нашем проекте Retail Rocket Segmentator [85]. В А/А-тесте вы должны получить то же самое распределение, что и в тесте! Если распределение задано пополам, 50/50, то вы его и должны получить на выходе. Даже небольшие расхождения в 3 % в данных теста могут поставить под угрозу весь тест. Если в тесте есть 100 000 пользователей, вы хотите разделить их пополам, а в итоге получается в одной группе 48 000, а в другой 52 000 – это говорит о проблемах в «случайности» разбиения по группам. Эти распределения можно проверить и на симуляциях, когда вам точно известен алгоритм. Но моя практика показывает, что мелкие нюансы разработки, о которых мы не знаем, могут приводить к «сдвигам» распределений. Поэтому я больше доверяю A/A-тестам.
Второе, на что важно обратить внимание, – пользователи должны попадать в группы равномерно, не должно быть смещений по разным срезам пользователей. Например, в тесте участвуют две группы пользователей: юридические и физические лица, первых всего 10 %, а вторых 90 %. После разбиения на группы это соотношение изменилось – в контрольной группе 7 и 93 % соответственно, в тестовой – 12 и 88 %. У этого явления могут быть две причины. Первая – есть закономерность в назначении идентификаторов клиентов, и эти данные используются в назначении групп. Вторая – юридических лиц слишком мало в абсолютных цифрах, и выборка нужна больше. Последнюю причину проще отсечь – нужно попытаться собрать больше данных, если наблюдаемая разница исчезнет, то все в порядке. Если нет – нужно разбираться с процедурой назначения. Обратите внимание на то, что «срезы» лучше сходятся, когда используется разбиение 50/50, а не какое-нибудь экзотическое 90/10. В меньшую группу попадает всего 10 % пользователей.
