Тем, кто на практике не использует A/B-тестирование, возможно, будет не очень интересно, но я постараюсь осветить какие-то важные пункты и для тех, кто уже имеет налаженный процесс тестирования внутри своей команды или компании в целом.
Покажу различные примеры из своей практики: я работал руководителем проектного офиса в "Бегуне" и других компаниях. Будет несколько примеров, которые связаны с моими личными проектами, а также несколько "классических" примеров A/B-тестирования, которые показывают, как работает этот инструмент, чего можно достичь с помощью него и зачем, собственно, он вообще используется.
Начнем с небольшого конкретного примера. Скажу сразу: это не мой пример. Я просто нашел его на одном из сайтов, где выкладывают конкретные готовые A/B-тесты. Хотелось бы просто проверить вашу интуицию и возможность принимать интуитивные решения относительно того, что хорошо, а что плохо в интернет-проектах.
Итак, у нас есть вариант А: некий сайт, на котором есть большая кнопка "Use Coupon". Смысл теста заключался в следующем: появилась такая гипотеза - если мы добавим зеленый шильдик, обозначающий безопасность транзакции, то мы повысим конверсию. В данном случае конверсия – это клики на кнопку "Use Coupon".
Собственно говоря, некий менеджер продукта предположил, что добавление данного шильдика в варианте В будет благотворно сказываться на конверсии.
Какие действия можно предпринять в данном случае? Мы просто добавляем шильдик и смотрим, повысилась конверсия или нет. Более правильный подход – попробовать проверить данную гипотезу, сравнить ее с вариантом А (он также носит название "control") и принять более взвешенное решение.
Задам вопрос.
Кто считает, что изначальный вариант более эффективен в плане конверсии, чем вариант B, поднимите руки.
Хорошо. Кто голосует за вариант, где мы применили шильдик?
Отлично. В общем, вариант B, на самом деле, проиграл.
400 %. Первоначальный вариант значительно лучше. Те, кто выбрал вариант А, условно молодцы. На самом деле, здесь никто не молодец. Здесь молодец – статистика, то есть более или менее точная наука, которая позволяет с большой долей вероятности утверждать, что вариант А эффективнее, чем вариант B.
Рассматривая этот конкретный случай, можно предположить, что наличие шильдика отвлекает внимание пользователей. Они пытаются кликнуть по нему и ощущают дискомфорт относительно того, что их отвлекают от цели. В итоге конверсия падает.
Вот такой наглядный пример, показывающий важность принятия решения на основании конкретных данных, а не того, что в английском языке называется "God feeling", то есть внутреннего ощущения, что правильно, а что неправильно.
Прекрасная табличка. Скажу честно, ее автор не я. Автором является Якоб Нильсен (Jakob Nielsen), небезызвестный юзабилити-гуру. Буквально в своей последней статье он привел подобную таблицу.
Я решил ее забрать, немного сократить и показать, поскольку она очень наглядна и дает представление о том, что является А/В-тестированием и где оно находится на общей шкале управления продуктами и улучшения веб-сервисов.
Как видно из схемы, А/В-тестирование – это самое дешевое, простое и доступное средство улучшения продуктов (хотя, может быть, не самое эффективное). Чуть позже я остановлюсь на нюансах А/В-тестирования, на том, какие могут быть ошибки, и расскажу, на что стоит обращать внимание.
Судя по этой таблице, выгода при использовании этого вида тестирования в среднем составляет 1-10 % от первоначального варианта (мы не сильно улучшаем продукт с виду). Однако А/В-тестирование должно быть постепенным, пошаговым процессом, и в итоге продукт может сильно улучшиться, – при том условии, что мы построим полноценный и эффективный процесс тестирования.
Мы о нем не будем говорить о юзабилити-тестах. Цифры по ним есть на слайде. Потом можно к нему вернуться.
Радикальные инновации
В терминах Нильсена они представляют собой нечто потрясающее. Например, придумывание iPhone. Это происходит раз в 10 лет и требует гигантских усилий гениальных людей, каких-то умственных затрат (может быть, иногда случайных открытий). Тем не менее, это процесс, который довольно редко приводит к реальным улучшениям. Чаще всего радикальные инновации – это нестандартные ходы, которые сложно придумать и трудно реализовать.
А/В-тестирование – самый простой и доступный способ.
Хотелось бы кратко рассказать о некоторых терминах, чтобы понимать, о чем мы будем говорить дальше.
Существует, условно говоря, две категории тестирования, связанные с распределением трафика и определением победителя – это может быть вариант А или вариант Б, или какие-то еще варианты.
Первая категория тестов – это А/В-тестирование или В/С-тестирование, или B/N-тестирование (оно же сплит-тестирование). Это методика улучшения продуктов, в ходе которой мы берем какую-то одну сущность, предлагаем ее в двух вариантах и смотрим, какой вариант – А или В – эффективнее.
Трафик распределяется, условно говоря, 50 на 50. Поскольку это делается случайным образом, там могут быть какие-то девиации, но мы условно считаем, что разделили трафик 50 на 50 и нашли лучший вариант.
Мультивариативное тестирование (MVT) мы здесь не будем рассматривать. Оно более сложное. Это более продвинутый метод тестирования, который подразумевает изменение сразу нескольких сущностей. Допустим, мы ставим другой заголовок и одновременно меняем цвет ссылок и кнопок.
Соответственно, у нас уже три набора изменений. Для каждого из этих изменений может быть несколько вариантов данного изменения. Все это мы перемешиваем и получаем довольно большое количество версий.
Мультивариативное тестирование хорошо, если у вас много трафика. Например, его может использовать Mail.Ru Group или какой-то большой портал, который имеет возможность быстро и много тестировать. Такому ресурсу выгодно применять именно второй подход, поскольку тот позволяет проверить больше различных гипотез.
А/В-тестирование подходит даже для сайтов, которые не могут похвастаться высокими показателями посещаемости. Тем не менее, их создатели тоже хотят проверять какие-то гипотезы и делать выводы относительно того, что хорошо, а что плохо.
Немного о статистике
Не хотелось бы детально останавливаться на этом вопросе, потому что тема довольно сложная. Существует много различных вариантов проведения тестов и получения результатов.
В А/В-тестировании мы считаем возможными два исхода.
Первый исход: у нас есть победитель: вариант А или вариант В.
Второй исход: у нас нет победителя.
Нельзя сказать, что какой-то из исходов является "плохим" или "хорошим". В терминах статистики, это просто более или менее вероятный исход. Менеджерам продуктов и тем, кто инициирует изменения, конечно, хотелось бы видеть победителя, чтобы провести на конкретном некие действия, направленные на увеличение той же конверсии, если мы говорим об увеличении конкретных показателей.
Но часто бывает, что победителя нет. Я продемонстрирую такой результат на одном из слайдов. Он тоже хорош и тоже иногда является желаемым. Например, когда мы хотим убедиться в том, что изменения, которые мы хотели бы сделать (например, изменение в дизайне, новый макет), не ухудшат основные показатели по конверсии.
Стоит остановиться еще на одном термине: статистическая значимость. Это уровень нашей уверенности в том, что результат А победил результат В, либо что у нас нет результата, нет победителя.
Обычно вероятность в 95 % считают достаточной, чтобы верить в то, что у нас есть победитель. На волю случая остается примерно 1/20: мы получили неправильные результаты – в конечном итоге, не отсутствие зеленой кнопки, а большая желтая кнопка приводит к повышению конверсии. 5 % мы "отдаем" на то, что зеленая кнопка все-таки могла победить.
Поговорим о лицах, которые так или иначе могут стать заказчиками А/В-тестирования. Этот вопрос тесно связан с вопросом о том, зачем оно нужно. Я привел довольно длинный список. На самом деле его можно еще расширить.
Кто использует сплит-тестирование?
Прежде всего, маркетологи. То есть люди, которые отвечают за сегментирование трафика (если мы говорим об интернет-маркетинге), за анализ трафика, понимают, как трафик привлекается, конвертируется и как он в целом ведет себя. Им важно понимать, какие стоит сделать улучшения.
Веб-аналитики. То есть люди, которые погружены в конкретные цифры. Им, очевидно, тоже надо понимать, как связаны элементы дизайна с конкретными конверсиями.
Юзабилити-аналитики. Это те люди, которые имеют дело с интерфейсами. Поскольку юзабилити, в общем-то, считается менее точной наукой, там есть определенные законы и количественные показатели, которые тоже можно считать с помощью сплит-тестирования.
Кто еще может заказать сплит-тестирование?
Менеджеры продукта, копирайтеры, разработчики. Это могут быть и непосредственные владельцы веб-проектов, если они знают о такой возможности и хотят принимать решения на основании конкретных данных, а не внутренних ощущений.
Что, собственно, можно оптимизировать?
Приведу несколько примеров улучшений.
Оптимизация конверсии (англ. Conversion Rate Optimization).
Показатель отказа (англ. Bounce Rate Optimization). Если на странице высокие показатели отказа, это значит, что много трафика уходит впустую. Люди приходят на страницу и, к сожалению, уходят, не достигнув нужных нам целей.
Показатель увеличения просмотров страниц. Он довольно важен для контент-ресурсов.
Определение оптимальной цены товара. Эта метрика важна для электронной коммерции (англ. e-commerce). Большинство А/В-тестов, которые проводятся в интернет-магазинах, так или иначе связаны именно с определением оптимальной цены и оптимальной конверсии, а также с увеличением конверсии.
Показатель увеличения CTR рекламы. Он необходим, например, для рекламодателей и партнеров. С одной стороны, рекламодатели иногда заинтересованы в том, чтобы у них увеличился CTR, и соответственно уменьшилась цена. Партнеры заинтересованы в том, чтобы кликали на объявления, которые есть у них на партнерских площадках.
Можно привести еще массу других примеров.
В "Бегуне", например, мы очень много тестировали непосредственно подбор объявлений. Это довольно тонкая материя: там могли быть не вполне очевидные параметры, которые влияли на подбор. Разумеется, там вообще нет никакой визуализации. Приходилось все тестировать с помощью А/В-тестов. Нельзя принять решение на основании каких-то умозаключений, даже примерно не видя, как это может отразиться на основных KPI.
Здесь более предметно показано, что конкретно можно тестировать. Есть различные "классические" элементы.
Элементы, которые призывают к действию (англ. "сall-to-action" elements). Это кнопки, ссылки и картинки. У них можно менять размер, цвет, расположение, текст и так далее (какие-то их свойства и сущности).
Изображения. Это непосредственно сами изображения (визуалы), их размер, качество, расположение элементов. Большой спектр различных изменений.
Количество текста, длина веб-формы. Сейчас популярно мнение о том, что более длинные формы лучше конвертируются, потому что люди видят всю информацию на одной странице. Люди принимают более осознанные решения сразу. У них возникает желание зарегистрироваться или купить какой-то товар прямо на этой странице.
Разумеется, каждую гипотезу нужно проверять. Для этого и существует А/В-тестирование.
Можно тестировать цветовую гамму, макеты страниц. Как я уже говорил, можно менять цену товара или спецпредложения, элементы рекламных блоков, пункты меню. Можно перечислять много различных элементов страницы, которые так или иначе можно протестировать с помощью А/В-тестов.
Три человека признались, что у них построен процесс А/В-тестирования. Я за них очень рад. Хотелось бы обратить внимание на то, как на практике проходит процесс А/В-тестирования. Возможно, будут какие-то комментарии и вопросы относительно этого процесса.
Сначала имеет место генерация идеи. Разумеется, мы должны понимать, что тестируем. Какое-то предположение у нас должно быть изначально. Например, мы хотим добавить шильдик и тем самым повысить конверсию. Собственно, это и есть генерация идеи.
Выбор инструмента. Позже я расскажу об инструментах, которые доступны для тестирования: на платных, бесплатных, SaaS-решениях, inhouse-разработках. Хотелось бы показать, чем можно проводить такие сплит-тесты.
Создание альтернативных вариантов. На этом этапе зачастую требуется участие дизайнеров, специалистов по юзабилити – людей, которые готовы предоставить альтернативные варианты страниц либо элементов страниц.
Случайное распределение вариантов между посетителями. Очень важный пункт. Он может не всегда корректно выполняться. Очень важно случайным образом распределять трафик: не надо, скажем, брать идентификатор пользователя. Лучше просто по модулю посмотреть: если меньше такого-то значения мы берем, если больше – этих людей определяем в группу В.
Важно случайным образом "перемешать" всех пользователей, потому что таким образом мы все отдаем на волю статистики, математики, а не заведомо внедряем псевдослучайные характеристики.
Наблюдение за тестом. Это важный процесс, потому что в моей практике бывали случаи, когда буквально в первые минуты при большом трафике становилось видно, что тест абсолютно некорректен с точки зрения постановки задачи. Конверсия падает на сотни процентов. Очевидно, надо иметь возможность быстро останавливать такие тесты.
О некоторых нюансах остановки тестов я тоже расскажу чуть позже.
Пункт 7 – это определение победителя. Желательно, конечно, чтобы победитель был. Но иногда статистически мы не можем сказать, что он есть - у нас нет уверенности на 95%. Приходится признавать, что победителя нет.
Мы должны быть честны, даже если отсутствие победителя огорчает тех людей, которые изначально считали, что вариант В, например, побеждает вариант А. Тут нужно проявить определенную твердость и следовать математическим законам, а не внутренним ощущениям.
Возвращаемся к пункту 1. Процесс цикличен - в том смысле, что в поисках улучшений А/В-тесты можно делать постоянно. В некоторых случаях они даже могут идти параллельно. Это завит от того, какую выборку пользователей вы делаете.
Процесс А/В-тестирования выглядит примерно вот так.
Несколько классических примеров.
Блогер по имени Дастин Кёртис (Dustin Curtis) решил проверить следующую гипотезу: если он изменит текст сообщения о добавлении в друзья в Twitter, то количество кликов увеличится.
Так и произошло. У него был изначальный вариант "follow me on twitter", который имел процент конверсии (здесь это клики) 7,31 %. Он протестировал несколько других фраз. Один из вариантов был сформулирован как "you should follow me on twitter here", и его "кликабельность" составила 12,81 %.
В процентном выражении он получил улучшение на 173%. При этом Дастин ничего больше не менял на странице, кроме этого текста.
Еще один классический пример. Добавление к кнопке маленькой пометки "It's free" увеличивает конверсию на 28 %. Никаких других изменений не было. Надпись "It's free" довольно маленькая. В плане юзабилити она не вполне удобна, поскольку не слишком привлекает внимание. Тем не менее, простое добавление фразы "It's free" повысило конверсию на 28 %.
Следующий канонический пример такой - правда, он вырван из контекста. Тем не менее, после изменения цвета имело место повышение CTR кнопки на 34 %. Мы "перекрасили" зеленую кнопку в красный цвет. Конверсия повысилась на 34 %.
Очевидно, что не совсем корректно рассматривать этот пример вне контекста. Если весь сайт зеленый, то изменение цвета одного элемента на красный априори должно повысить "кликабельность".
Это пример из моей практики, связанной с рекламной сетью Yandex. Сам сайт выполнен преимущественно в красно-серой цветовой гамме. Возникла такая гипотеза: если поменять цвет рекламных ссылок на синий, то можно добиться большего количества переходов. Собственно, так и произошло. По результатам А/В-теста, синий цвет, который больше гармонирует с цветом ссылок на всем сайте, дает повышение конверсии на 80 %. Довольно неплохо!
Пример из практики "Бегуна"
Примерно года полтора назад возникла идея изменить дизайн макетов (англ. layout) некоторых блоков. В данном случае речь идет о фиксированном блоке размером 240х400. Слева на слайде вариант А, а справа вариант В.
В левом варианте изначально были сервисные ссылки: "Дать объявление", "Все объявления". В варианте В мы решили от этого отказаться и оставить только надпись "begun". Мы сочли нужным переместить ее вниз, чтобы она не привлекала внимания. Мы надеялись, что в этом случае количество кликов по объявлениям (а значит, и наши доходы) будет больше.
Оказалось, что это не так. Статистически значимых результатов мы не получили, хотя тест проводился долго. С репрезентативностью все было в порядке, была большая выборка. Тестирование проводилось на двух дата-центрах. Дата-центр А – это вариант А. Дата-центр В – это вариант В. Но результата не было.
Если нет статистически значимого результата, мы можем остановиться на одном из альтернативных вариантов только потому, что он более привлекателен. Тут есть некоторое допущение. Выбранный нами вариант потенциально может приводить к увеличению KPI (в данном случае CTR).
При одинаковых результатах можно выбрать вариант В, потому что он более привлекателен, вот и все.
Был еще один пример, когда результат варианта В получился отрицательным. На самом деле, мы изначально это предполагали, но хотели знать на самом деле, насколько вариант В хуже варианта А.
В варианте В мы добавили кнопку "Закрыть рекламу", которая знакома пользователям по интерфейсу Facebook. Нажав ее, можно было написать свое послание компании "Бегун" с объяснением того, почему эта реклама не релевантна, не подходит и так далее. При этом можно было не нажимать на саму рекламу.
Мы понимали, что некоторые люди будут нажимать на крестик и игнорировать само объявление, но мы хотели знать, сколько будет этих людей. Мы выяснили, что вариант В дает нам на 10 % меньше кликов. Поэтому мы запустили вариант с отключаемой рекламой только 1 апреля в качестве шутки, написав еще какой-то специальный текст типа: "Вы избранные, у вас теперь есть возможность рулить всей рекламой на партнерской сети "Бегуна".
Здесь несколько ссылок на ресурсы с примерами А/В-тестов. Там иногда бывают довольно вдохновляющие примеры, которые позволяют посмотреть, что люди на самом деле тестируют и зачем они это делают.
Whichtestwon, abtest.com. Есть еще русский abtest.ru, который тоже позволяет посмотреть реальные кейсы.
Инструменты для А/В-тестирования
Давайте перейдем к инструментам для А/В-тестирования. Может быть, я рассказал много теоретических вещей. Теперь надо остановиться на конкретных решениях. Дальше будут названия конкретных продуктов.
Условно я разделил их на 2 категории. Это готовые сервисы и программные решения.
Готовые сервисы – это SaaS-решения, которые дают вам возможность быстро, а иногда даже бесплатно начать проводить А/В-тестирование. Вам достаточно зарегистрироваться, получить небольшой кусок кода, разместить его на всех страницах, и после этого реализация будет содержаться уже в самом сервисе. Вам больше не нужно будет ничего менять на странице.
У этого подхода есть определенные недостатки. Если у вас большой трафик, придется думать об оптимизации загрузки этих JS-решений, потому что они могут "тормозить".
Может возникнуть неприятный эффект: посетитель хочет посмотреть страницу, а ему сначала показывают вариант А, который потом меняется на вариант B в реальном времени из-за того, что какой-то сервис медленно отдает файлы клиенту.
Есть конкретные программные решения, которые позволяют реализовывать А/В-тестирование на серверном уровне. Вам не потребуется иметь какой-то клиентский сторонний сервис. Дальше я назову конкретные решения…
Они работают на сервере. Они не дают эффекта "торможения" на клиенте, поскольку все происходит на сервере в момент сборки страницы. Тем не менее, должна быть реализована определенная защита от ботов. Иначе неминуемо победит вариант B. У нас есть канонический вариант А – мы хотели бы на нем остаться.
Это важно. Если вы берете западное программное решение, постарайтесь убедиться, что оно поддерживает Yandex и другие наши боты, которые могут индексировать страницы.
На этом слайде перечислены конкретные готовые сервисы.
Самый первый из них - это Google Website Optimizer. Он абсолютно бесплатный. Наверное, он наиболее популярен. Но у него есть один серьезный недостаток: он тестирует только конкретные страницы, а не изменение элемента (например, то же самое "перекрашивание" кнопки).
Чтобы "перекрасить" кнопку, вам потребуется две страницы. Нужна страница test-1 или стандартный логин HTML. Вам придется сделать логин подчеркивания BHTML.
В чем недостаток?
Когда у вас будет победитель – вариант А или вариант В, вам придется весь трафик с варианта А перекидывать на вариант В, потому что URL должны оставаться доступными. Необходимо позаботиться о том, чтобы в конечном итоге весь трафик шел на вариант В. Нужно сделать так, чтобы остальные варианты, которые участвовали в тесте, не попали в кэши поисковых машин и не показывались каким-то случайным пользователям. Это стоит учитывать.
Поскольку приходится делать несколько страниц, это может быть не очень удобно. Это требует дополнительных ресурсов разработки, а они, конечно, не всегда доступны.
Google Analytics и Яндекс.Метрика нужны, прежде всего, для другого. Но поскольку они оперируют какими-то переменными, которые можно задавать на уровне пользователей, мы можем случайным образом разделить пользователей на группу А и группу В. Соответственно, дальше надо следить за изменениями конверсии внутри инструмента Google Analytics или Яндекс.Метрика.
Разумеется, там нужно еще считать статистическую значимость. Это можно делать с помощью дополнительных инструментов-калькуляторов. Чуть позже я назову некоторые из них. Вам все равно придется использовать какие-то дополнительные инструменты, чтобы убедиться, что вы получили статистически корректные результаты.
Существуют и такие сервисы, как Visual Website Optimizer и Optimizely. Они довольно понятные, визуальные, все сделано по современным стандартам. Но они платные. Optimizely сразу требует кредитную карту. Visual Website Optimizer можно месяц пользоваться бесплатно, а после этого они готовы выставить счет.
Для кого-то это может быть неподходящим вариантом из-за необходимости платить. Западным компаниям не очень удобно делать это в российских реалиях. Но инструменты показали себя с хорошей стороны. Если у вас нет желания внедрять свою систему А/В-тестирования, можно воспользоваться уже готовым инструментом, который хорошо работает.
Есть еще Unbounce. Он в большей степени ориентирован на оптимизацию так называемых "посадочных страниц" (англ. landing pages). Там даже есть редактор таких страниц. По сути, это некий визуальный редактор, а не просто инструмент А/В-тестирования.
Рядом с abtest.ru я нарисовал грустный смайлик. Не хочется подробно на нем останавливаться. Смысл в том, что этот инструмент, к сожалению, довольно сырой. Там много того, что не работает. Видно, что разработчики ориентировались на Visual Website Optimizer и Optimizely, но, к сожалению, у них пока не очень получается.
Я надеюсь, ребята справятся, потому что задумка хороша. Наши сервисы удобны хотя бы в плане оплаты: им проще выплатить деньги, нежели западным сервисам.
Выше перечислены программные решения для А/В-тестирования.
Я привел несколько примеров программных инструментов:
- phpA/B, который позволяет тестировать с использованием PHP;
- Python-ab для Python;
- для Ruby on rails есть A/Bingo;
- даже для JS есть собственное решение.
У нас были свои панели мониторинга (англ. dashboard) и свои инструменты, которые позволяли понимать, насколько корректно идут тесты. Также можно взять какие-то готовые решения – их довольно много. Я назвал лишь наиболее типичные и интересные.
Дам еще несколько полезных ссылок. Возможно, не стоит их записывать и запоминать; важно помнить, что некоторые инструменты изначально не позволяют проверять статистическую значимость.
Google Analytics или Яндекс.Метрика изначально не были предназначены для А/В-тестирования: они не позволяют понять, какой из вариантов более вероятностный. Для этого есть сторонние калькуляторы, которые работают на основе различных экзотических моделей. Это j-test, students-test, p-test и так далее. Их довольно много.
Может быть, там применяются не очень простые математические алгоритмы, но вы можете посмотреть, что составляет базу каждого из этих тестов.
Длительность теста - это, на самом деле, важный момент. У вас есть какое-то количество трафика, у вас есть вариант А, вариант В и гипотеза относительно увеличения конверсии. Вам нужно понять, сколько должен длиться тест.
Для этого есть готовые калькуляторы, которые возьмут ваши исходные данные и посчитают все за вас. Разумеется, они делают это с определенной погрешностью, потому что ваш трафик может меняться, можно неправильно посчитать конверсию или сделать неверный прогноз. Но какую-то цифру вы все равно получите. Это лучше, чем вообще ничего.
Распространенные ошибки при проведении А/В-тестирования
Хотелось бы остановиться на нескольких ошибках при проведении А/В-тестирования. Я их разбил на несколько категорий.
- Подготовка к тесту.
- Проведение эксперимента.
- Завершение и интерпретация результатов.
Подготовка к тесту часто осуществляется некорректно. Различные заинтересованные лица (заказчики) могут понимать его не совсем верно. Очень важно тестировать варианты А и В одновременно, а не последовательно.
Это аксиома для А/В-тестирования. Оно называется сплит-тестированием в том смысле, что мы разделяем весь трафик пополам или на три равные части, и так далее. Весь поток должен быть разделен одновременно. Нельзя в течение одной недели тестировать один вариант, в течение второй – второй вариант. Это даст абсолютно неправильный результат.
Трафик у нас разный, пользователи разные, обстоятельства разные – праздничные дни или будни. В общем, довольно много факторов, которые влияют на результат.
Если вы боитесь отпугнуть постоянных пользователей, вы можете тестировать пользователей в некой небольшой выборке, связанной преимущественно с новыми посетителями (этот вариант хорош, если у вас много трафика, и вы можете себе это позволить). Такое тестирование не затронет тех пользователей, которые уже были у вас на сайте и привыкли к его дизайну и особенностям.
Важный момент. Если мы говорим именно про А/В-тест, а не мультивариативное тестирование, должна меняться только одна сущность. Это может быть цвет кнопки или расположение элемента. Если вы измените сразу несколько сущностей, вы уже не сможете точно сказать, что больше повлияло на изменение конверсии. Вы не узнаете, будет ли вообще какое-то изменение показателей, если поменять только кнопку, но оставить прежний текст, например.
Вы этого не узнаете, потому что у вас будут неправильные данные. Менять нужно только одну вещь. Тогда вы будете уверены, что изменения либо полезны, либо вредны, либо ни на что не влияют.
Важный момент: проверяйте чужие тесты. Допустим, вы перейдете по тем ссылкам, которые я указывал, найдете там различные примеры А/В-тестов и захотите их проверить… Точнее, даже не проверить, а наоборот – сразу внедрить у себя в системе, это будет ошибкой.
Разумеется, очень важен контекст использования того или иного подхода. Изменение цвета кнопки не является решением, подходящим для всех случаев. Все возможные выводы, которые есть в конкретных тестах, нужно проверять.
Проведение тестов
Первый пункт. Скажу честно: я сам не всегда ему следовал. Если некий случайный пользователь Вася Пупкин увидел вариант В, и мы его зафиксировали с помощью cookie или какого-то другого инструмента, то при следующем заходе Вася обязательно должен видеть вариант В.
Он не должен больше видеть вариант А, иначе получится, что мы сами портим наши данные. Мы должны их запоминать до того момента, пока текст не завершится.
Кроме того, если у нас изменения не на одной странице, а на ряде страниц всего сайта, обязательно нужно фиксировать Васю Пупкина на всех этих страницах, чтобы он всегда видел вариант В. В идеале он должен видеть вариант В на всех устройствах.
Если мы имеем дело с зарегистрированными пользователями, то это довольно просто. Пользователь выполнит вход на сайт и на iPad, и со смартфона. Мы всегда знаем, что это один и тот же человек.
Разумеется, тут есть нюансы. Если пользователь зайдет со смартфона, у него будет уже несколько другой дизайн (адаптивный). Может быть, не очень правильно проводить там тесты, но если мы хотим тестировать восприятие пользователями вариантов везде, на всех устройствах, то желательно везде следовать этому правилу, везде показывая нашему Васе вариант В.
Там, где нет регистрации, применяются более сложные механизмы синхронизации профиля. Там должны работать cookie, чтобы мы "узнавали" Васю Пупкина на всех устройствах, и он видел вариант В.
Окончание тестирования
Важный момент, о котором я уже говорил: победитель должен определяться статистически, а не "на глазок". В ходе теста мы можем увидеть, что побеждает вариант А, и остановить тест слишком рано (второй пункт).
Нужно дождаться статистически корректных значений. Того же пресловутого значения 95 %, когда мы точно можем сказать: да, победил вариант А (или вариант В). Соответственно, больше тест проводить не нужно.
Работа с редиректами, GWO. Если у нас несколько страниц, весь трафик обязательно нужно "переливать" на ту страницу, которая победила.
Внедрение процесса А/В-тестирования
Процесс А/В-тестирования – относительно новый процесс для Рунета. Крупные компании, впрочем, довольно давно его используют. Я знаю, что Mail.ru и Yandex, например, точно его применяют.
В более мелких, не настолько продвинутых компаниях А/В-тестирование еще не настолько распространено. Поэтому у него должны быть свои идеологи, сторонники подхода, основанного на конкретных данных (англ. data-driven approach), а не на каких-то внутренних ощущениях.
Есть еще одна роль – "пытливый исследователь". Это термин Димы Кирноценского из "Бегуна" (технического директора на тот момент). Это человек, который хочет проверить какую-то гипотезу. Некий автор предположения о том, что добавление зеленого шильдика даст нам повышение в конверсии. Должен быть человек, который инициирует тестирование.
В тестировании, естественно, участвуют и сами разработчики. В общее понятие "разработчики" я в данном случае включил и дизайнеров. Можно было их и отдельно указать. Это люди, которые воплощают конкретные предположения относительно варианта А и варианта В.
Идеолог
Идеолог - это некий чемпион. Это человек, который должен всюду пропагандировать культуру подхода, основанного на конкретных данных, то есть внедрять различные практики, связанные с управлением проектами и продуктами на основании данных, а не на основании гипотез.
Правила и роли должны быть зафиксированы в отдельном регламенте. Если у вас принято писать регламенты на разработку и тестирование, должен быть отдельный регламент на А/В-тестирование, потому что оно довольно специфическое.
Весь процесс связан с разного рода нестандартными подходами. Здесь нужно помнить о некоторых мелочах. Лучше все это зафиксировать в отдельном документе, не связывая его с регламентами, допустим, по разработке.
Пытливый исследователь
У этого человека должна быть возможность быстро запускать и останавливать тесты. Останавливать особенно важно, потому что в случае проблем нужна возможность быстрого возврата к изначальному варианту.
Качественная панель мониторинга (англ. dashboard) - важный инструмент для принятия решения. Это некая "приборная доска", которая позволит посмотреть, какие KPI достигаются, и достигаются ли они вообще.
Автоматизированные отчеты необходимы для быстрого получения и оценки результата.
Остановимся на слайде, связанном с разработкой тестов. Не очевидный, но важный момент. Надо писать юнит-тесты на А/В-тесты, потому что это тот же код, который выкатывается на продакшн и может содержать ошибки.
"Переключалка" альтернатив – это возможность быстро посмотреть, например, вариант В в любой момент, когда нам это нужно. Нам система уже выдала вариант А, а мы как разработчики хотели бы видеть вариант В. Для этого мы делаем некий параметр GET, который даст нам возможность быстро это посмотреть.
Повторное использование А/В-тестов и неких целей, конверсий – это норма. Надо понимать, что мы можем вернуться к тому или иному тесту, и он должен у нас остаться в системе контроля версии, допустим.
Главные выводы
Тестируйте часто и разнообразно. Некоторые примеры тестов я привел в рамках этого доклада. Если речь идет о пытливом исследователе, то этот специалист должен постоянно придумывать различные варианты улучшений.
Обязательно автоматизируйте рутинные операции: никто не любит рутину. Лучше, чтобы всю скучную и трудоемкую работу делал компьютер – например, считал различную статистику или делал конкретные красивые графики по результатам.
Полагайтесь на статистические выкладки. Принимайте решения осознанно – на основании данных, не руководствуйтесь внутренними ощущениями.
Не впадайте в крайности.
По поводу крайностей... у меня есть последний слайд.
Дуг Бауман (Doug Bowman), некогда главный дизайнер Google, ныне главный дизайнер Twitter, рассказывал в своем блоге следующее.
Когда он работал на Google, был случай, когда ему пришлось доказывать, что граница должна быть толщиной 3, 4, 5 пикселей. Для этого ему предлагали провести А/В-тест. Поскольку он дизайнер и человек творческий, он ответил на это предложение довольно резко. В конечном итоге он ушел из компании и написал: "I can't operate in an environment like that".
Довольно сложно работать в условиях, когда дизайнера заставляют доказывать очевидные вещи.
Наверное, это уже крайность. Но я не исключаю, что это может быть важно в каких-то отдельных случаях. Например, для PDA-устройств (для мобильных устройств) наличие 3-х или 5-типиксельной границы может оказаться важным, поскольку там мало места.
Все. Я закончил.
Спасибо.
Вопросы и ответы
Реплика из зала: У меня вопрос по поводу случайного "разбиения" всех пользователей на сплиты. Ты сказал, что нужно брать только новых пользователей…
Александр Шуркаев: Не нужно. Это один из вариантов.
Реплика из зала: Это же заведомо неслучайное разбиение!
Александр Шуркаев: Нет. Мы просто делаем выборку. Всех новых пользователей мы разделяем на вариант А и В. Новых! Если у нас миллион посетителей в месяц…
Реплика из зала: Понятно, можно не продолжать.
Александр Шуркаев: Да, это довольно много.
Реплика из зала: В выборке изначально только новые пользователи?
Александр Шуркаев: Да.
Реплика из зала: "Старых" пользователей мы вообще не рассматриваем?
Александр Шуркаев: Естественно. Они не участвуют в тесте.
Реплика из зала: Какие правильные способы разделения тебе известны? Понятно, что нужен ID…
Александр Шуркаев: Случайное разделение. В MySQL это Rand, в PHP это тоже Rand, про другие языки я сходу не скажу… Просто одна строчка кода, которая позволяет определить число, с которым мы можем сравнить идентификатор.
Реплика из зала: Понятно. Допустим, мы берем неделю сплит-тестирования. У нас есть какая-то недельная аудитория. Приходит человек с каким-то ID, который записан в cookie или еще где-то. Мы случайным образом ему назначаем какой-то сплит.
Александр Шуркаев: Конечно.
Реплика из зала: Так и делаем с каждым пользователем?
Александр Шуркаев: Да.
Реплика из зала: Мы действительно получим правильный результат в итоге?
Александр Шуркаев: Конечно. Это же математика: случайное распределение называется. Нормальное распределение.
Реплика из зала: Да, хорошо, но мы хотим именно пользователей разделить.
Александр Шуркаев: Ты имеешь в виду зарегистрированных пользователей?
Реплика из зала: Например, один пользователь зашел и ушел, а другой всю неделю сидит на этом сплите. У нас в итоге будет правильная оценка? Это инструменты каким-то образом разбивают по сплитам?
Александр Шуркаев: Если речь идет обо всем трафике, что более просто, то с помощью того же GWO или Optimizely мы весь трафик распределяем. Там есть настройки. Можно выбрать часть трафика.
Я, кстати, не уверен, что в SaaS-решениях (готовых сервисах) есть возможность добавить какую-то логику, которая будет работать для зарегистрированных или незарегистрированных пользователей.
Это, скорее всего, придется делать на клиенте – вы должны на клиенте организовать какую-то проверку для зарегистрированных пользователей. Вы должны дать им код Optimizely или какого-то другого инструмента. Тем, кто не зарегистрирован, ничего давать не нужно. Соответственно, у них не будет теста.
Или, при проведении тестирования на новых пользователях, нужно давать кусок кода, который инициирует сплитование, только им. Другим пользователям в этом случае мы ничего не даем. Эту логику потребуется вынести на уровень непосредственно самого веб-приложения.
Реплика из зала: Из твоего личного опыта – какое количество сплитов ты считаешь оптимальным?
Александр Шуркаев: Это очень индивидуально.
Реплика из зала: Для каждого элемента индивидуально или для количества пользователей индивидуально?
Александр Шуркаев: Тут очень важна аудитория, разумеется. Если у нас большая аудитория, проблем с ней мало (если много пользователей, то много трафика). Здесь очень важно большое количество трафика, чтобы выборка была репрезентативной и чтобы мы могли сделать корректные данные на основании статистики.
Если много трафика, можно тестировать всего 2-3 дня и получить хорошие результаты. Если у нас мало трафика, можно тестировать неделями. Это, конечно, неудобно: процесс затягивается, принятие решений усложняется.
В таком случае можно попробовать какие-нибудь мультивариативные тесты, но с упрощенной системой. Есть такой тест под названием "Тагути-тест". Он основан на том, что мы проверяем гипотезу не относительно всех 27-ми вариантов, если у нас есть 3. Мы меняем заголовок. Меняем кнопку, меняем цвет. Соответственно, у нас есть 3 элемента.
27 вариантов проверить на небольшом трафике сложно. Для этого есть методы оптимизации количества вариантов: тот же Тагути-тест.
Он не очень научный. По крайней мере, так утверждают. Тем не менее, он позволяет отобрать 8 вариантов, а не 27. На них с помощью этих комбинаций можно проверить, какой вариант побеждает.
Комментариев нет:
Отправить комментарий