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

Начало тестирования

Рекомендация: постепенно наращивайте количество пользователей в тестовой группе до 50 % от совокупной выборки.

В начале эксперимента можете сразу направить 50 % трафика в тестовую группу. Сложность заключается в том, что, если закралась ошибка, в результате которой половина ваших пользователей получила негативный опыт, то вы можете просто потерять эту половину пользователей. Вместо этого можно попробовать другой подход: постепенно наращивать количество пользователей в тестовой группе и тщательно контролировать показатели. Рон Кохави предлагает следующую схему[141]:

• 1 % пользователей направляется в тестовую группу на четыре часа;

• 5 % пользователей направляются в тестовую группу на четыре часа (то есть перевод дополнительных 4 % пользователей из контрольной группы в тестовую);

• 20 % пользователей направляются в тестовую группу на четыре часа;

• 50 % пользователей направляются в тестовую группу на все оставшееся время тестирования.

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

Завершение тестирования

Рекомендация: проводите эксперимент, пока не охватите минимальный размер выборки или больше.

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

К сожалению, многие производители программного обеспечения для А/В-тестирования побуждают пользователей проводить эксперимент только до того момента, когда будут достигнуты значимые результаты. Никогда не проводите тестирование подобным образом! (Кажется, так я достаточно дал понять, что это действительно важно?) После изучения предложений четырех производителей специализированного ПО Мартин Гудсон отмечает: «Некоторое ПО для A/B-тестирования разработано таким образом, что оно постоянно отслеживает результаты и останавливает процесс, как только достигаются значимые результаты. Однако когда тестирование проводится подобным образом, вероятность ложноположительного результата может достигать 80 %»[142]. (См. также How Not To Run An A/B Test[143]).

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

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

МНОГОВАРИАНТНОЕ ТЕСТИРОВАНИЕ

До того мы обсуждали только варианты тестирования с двумя переменными: контрольно-тестовое (A/B) или контрольно-контрольное (A/A). Такое тестирование обычно бывает простым и эффективным. Однако у него есть свои недостатки. Вспомните пример с избирательной кампанией Обамы, когда аналитики тестировали разные надписи на кнопке и разные изображения. У них было пять разных вариантов надписи и по крайней мере шесть разных изображений, то есть общее количество разных комбинаций было не меньше 30. Последовательное тестирование всех этих комбинаций заняло бы в 30 раз больше времени, чем проведение одного А/В-теста. Именно по этой причине в некоторых случаях используются многовариантные тесты.

Это тестирование также иногда называют факторным экспериментом, и в ходе него все возможные комбинации тестируются одновременно. То есть группа 1 видит изображение 1 и текст 1, группа 2 — изображение 2 и текст 2, и так до группы 30, которая видит изображение 6 и текст 5.

Какие у этого подхода плюсы и минусы? Если у вас высокая посещаемость сайта и вы можете позволить разделить трафик между разными комбинациями, у вас есть возможность провести тестирование параллельно, то есть потратить на него меньше времени. (Сервис YouTube, у которого, очевидно, огромная посещаемость, в 2009 году провел эксперимент, включавший тестирование 1024 комбинаций[144]. Оптимальная комбинация привела к росту количества подписчиков сервиса на 15 %.) Кроме того, вы можете протестировать так называемый эффект взаимодействия. Возможно, более крупная кнопка подписки эффективнее, чем кнопка стандартного размера, и кнопка подписки красного цвета эффективнее, чем кнопка подписки синего цвета, а если объединить эти две характеристики, то выяснится, что крупная красная кнопка подписки еще эффективнее, чем просто крупная или просто красная кнопка.

Не все комбинации имеет смысл тестировать. Предположим, первый фактор, который нужно протестировать, — цвет кнопки подписки: красный (текущий) или черный (тестовый). При этом второй фактор — цвет надписи на кнопке: черный (текущий) или белый (тестовый). Общее количество возможных комбинаций — четыре, но комбинация «черная кнопка / черный цвет надписи» явно в тестировании не нуждается. Или, как отмечают Кохави и др., более крупное изображение товара и его дополнительное описание может стать не самой удачной комбинацией, поскольку тогда кнопка для оформления заказа слишком сильно сместится вниз. Подобные моменты нужно отслеживать еще на стадии планирования эксперимента и не включать в тестирование.