Одно из важнейших требований к A/B тестингу, которое обязательно должно быть заложено в визуальные эксперименты — это требование устойчивости. В данном случае под устойчивостью мы понимаем два простых пожелания. Во-первых, мы, конечно, не хотим видеть значимых изменений там, где их на самом деле нет. С другой стороны, обратное тоже верно: если какие-то значимые изменения есть, то мы хотим их увидеть на метриках. Это очень просто понять на примере. Предположим, мы выкатываем в эксперимент две одинаковые версии сервиса. Ну, например, у нас нет никаких изменений. В данном случае, конечно же, нам на всех метриках хочется видеть одинаковый результат, нам хочется быть уверенными, что если изменений нет, то мы их не увидим. С другой стороны, если есть некоторые значимые изменения, то конечно, мы хотим увидеть это на метриках. Мы хотим убедиться, что по всем метрикам есть некоторый значимый прирост. Казалось бы, это очень простые и логичные требования, которые должны всегда выполняться. Но часто на практике получается, что это не так. Давайте рассмотрим следующий пример. Допустим, у нас есть некоторый сайт, который позволяет делать поиск по некоторому специфичному контенту. Ну, например, мы ищем по объявлениям о недвижимости. В данном случае мы можем изменить дизайн и проверить то, как новый дизайн влияет на поведение пользователей. Правда ли, что он им нравится больше, они начинают больше искать и более активно пользоваться сервисом. Мы можем сделать некоторое очень простое изменение, ну, например, перекрасить кнопку поиска из синего цвета в зеленый. В данном случае легко понять, как будет выглядеть наш A/B тестинг. Мы разобьем пользователей на тестовую и контрольную группу. Одной группе пользователей будем показывать кнопку синего цвета (старый дизайн), а другой группе пользователей будем показывать кнопку зеленого цвета, это наш новый дизайн. Дальше мы с вами посчитаем некоторые метрики, которые можно считать в онлайне в данном случае (количество нажатий на эту кнопку), и посмотрим, как же они изменились. Часто в таких экспериментах можно наблюдать следующий эффект. В контрольной группе, то есть в группе, где мы изменили дизайн, количество кликов будет больше. Но что же это означает? Действительно ли дизайн стал лучше? В данном случае возможна двоякая трактовка. Те пользователи, которые привыкли пользоваться сайтом и уже привыкли к тому, что кнопка имеет синий цвет, могут удивиться тому, что что-то изменилось и захотеть проверить, изменился ли только дизайн или, может быть, как-то изменилось поведение. Соответственно, они могут начать чаще нажимать на кнопку просто из любопытства, чтобы понять, что же изменилось. В данном случае важно убедиться, что те метрики, которые мы считаем, не учитывают это изменение как значимое. Для того чтобы обезопасить себя от ситуации, в которой мы принимаем незначимые изменения за значимые, мы можем поступить следующим образом. Предположим, мы провели классический A/B тестинг и увидели, что новый дизайн лучше, то есть кнопка зеленого цвета больше нравится пользователям. По тем метрикам, которые мы меряем, например, доля кликов, или длина сессий, или, может быть, что-то другое, мы видим значимые улучшения. Тогда по логике мы должны поступить следующим образом: мы должны выбрать новый дизайн и раскатить его на всех пользователей, то есть показывать всем пользователям кнопку зеленого цвета. Однако мы можем поступить несколько хитрее. Давайте выберем небольшую группу пользователей, ну, например, меньше 1 %, и будем продолжать показывать им старый дизайн после выкатки нового. То есть у нас будет отдельно существовать некоторая группа пользователей, которая еще какое-то существенное время будет видеть старый дизайн. Это позволит нам сделать следующее: мы сможем продолжить рассчитывать те же самые метрики, которые мы считали в процессе A/B тестинга, более длительное время. По прошествии более длительного времени мы с вами сможем снова сравнить поведение пользователей, которые видят новый дизайн, с поведением пользователей, которые видят старый дизайн. В данном случае, если мы не увидим значимых изменений, то мы сможем сделать вывод о том, что во-первых, нам дизайн эксперимента не позволяет нам отличать незначимые изменения от значимых, потому что иначе мы бы увидели это в результате первоначального A/B тестинга, а с другой стороны, мы поймем, что на самом деле мы можем оставить любой дизайн, который нам больше нравится. Пользователи их не отличают. Вот такая техника называется обратным экспериментом. Ее идея заключается в том, что после классического A/B тестинга мы с вами продолжаем проводить эксперимент, однако мы выделяем некоторую маленькую группу пользователей, которые продолжают видеть старое решение. Это дает нам возможность убедиться в том, что наши изменения действительно значимы и приводят к тому эффекту, который мы ожидаем. Казалось бы, технология обратного эксперимента способна решить все наши проблемы и помочь нам очевидным образом отличать значимые изменения от незначимых, но представьте себе следующую ситуацию. Мы часто проводим A/B тестинг, видим значимые изменения на целевой и контрольной группе, запускаем эти изменения в технологию «обратный эксперимент» и понимаем, что на самом деле изменений нет. Конечно же, эта ситуация является для нас крайне нежелательной, потому что мы тратим довольно много времени на проведение A/B тестинга и далее на проведение обратного эксперимента. Возникает вопрос: можем ли мы заранее убедиться в том, что наш дизайн эксперимента позволяет нам отличать значимые изменения от незначимых? В частности, убедиться в том, что размер наших контрольных и целевых групп позволяет нам это делать, а также в том, что длительность эксперимента тоже подобрана правильно. Для того чтобы эту задачу решить, существует технология A/A тестинга, или А/А тестов. Это работает следующим образом. Предположим, что мы приняли решение о том, что мы хотим провести A/B тестинг с новым алгоритмом, ну, например, алгоритмом поиска или алгоритмом рекомендации. Как в этом случае выглядел бы классический A/B тестинг? Мы бы разделили пользователей на контрольную и тестовую группу, и показывали бы разные алгоритмы в разных группах, после чего сравнили бы те метрики, которые нас интересуют, рассчитанные на разных группах. Давайте перед тем как запускать классический A/B тестинг, поделим пользователей на группы точно так же, как мы бы это сделали в рамках A/B тестинга, но только будем показывать разным группам один и тот же алгоритм, то есть не будем в тестовой группе показывать наше новое решение. Какое-то время будем проводить этот эксперимент, на самом деле ровно такое время, которое мы бы хотели делать A/B тестинг, и дальше посмотрим, видим ли мы значимые изменения на тех метриках, которые нас интересуют. В том случае если мы значимые изменения не видим, то это хорошая ситуация, потому что кажется, что наш дизайн эксперимента не пытается показать нам значимые изменения там, где их нет. С другой стороны, в противоположной ситуации, если мы вдруг увидим значимые изменения при том, что мы с вами знаем, что обе группы видят одно и то же решение, то это наводит нас на мысль о том, что что-то в нашем дизайне эксперимента не так. Например, эксперимент длится недостаточно долго или мы неправильно разбили пользователей на группы. В любом случае, это повод задуматься о дизайне вашего эксперимента и каким-то образом его провалидировать. Таким образом, мы с вами обсудили две методологии, которые позволяют вам убедиться в устойчивости вашего дизайна эксперимента: это обратный эксперимент и А/А тест. А в следующем видео мы поговорим о том, как же нам оценить необходимый объем выборки и длительность эксперимента.
