Pull to refresh

A/B тесты не нужны*

Web design *Interfaces *Usability *
Вас всех обманывают. Наглый миф IT-индустрии — утверждение, что А/В-тестирование универсальное и полезное средство для оптимизации.
* для сайтов и мобильных приложений


Немного об авторе и причинах написать этот текст ;)
Привет, меня зовут Чудинов Денис. Сейчас я развиваю свою студию дизайна и разработки мобильных приложений. Я хочу бороться с заблуждениями и стереотипами, которые бродят среди заказчиков.
Мой путь в IT начинался с UX-специалиста (да-да), то есть с проектирования решений и аналитики. Текущий пост является, в каком-то смысле, результатом работы в этом направлении.


По своему опыту и опыту коллег, могу сказать, что почти ни у одной компании нет нормального А/В тестирования, поставленного на поток. Говорят, кто-то где-то видел, но, по сути, честное А/В-тестирование не найти.

Почему так? Давайте разбираться.

Однажды, на одном проекте (суточный трафик порядка 800 000 уникальных пользователей) мы задались целью внедрить А/В тестирование.

Вот с чем мы столкнулись:

1. Трудно с точки зрения «чистоты эксперимента»


Пока не берем А/В-тестирование, а разберем «простой» пример, когда вы добавили еще один рекламный баннер себе на сайт и измерили показатели.

На него кликают, начали капать деньги.

Что стало с другими баннерами и их конверсией? Если вам не повезло, то, скорее всего, суммарный доход не изменился или вообще упал.

А теперь представьте, что вам повезло и доход вырос. Разве дело только в баннере? Может изменился трафик? Сработала сезонность или разовый вирусный эффект в соц.сетях? Пока вы тестируете, продукт живет и развивается, очень трудно найти «чистый» месяц, который был бы «без влияния» маркетинга, портящего эксперимент.

Нужно хорошо разобраться в возможных внешних причинах, а это почти всегда гадание на кофейной гуще. Конечно, вы можете маниакально принять во внимание все показатели продукта… чтобы гадание на кофейной гуще было чуточку научнее.

Как действовать в подобной ситуации? Следовать простому алгоритму:
  1. Придумали гипотезу.
  2. Внедрили изменение.
  3. Измерили главные показатели через месяц (или другой период: день или квартал).
  4. Стало лучше? Можно оставлять.
  5. Стало хуже? Верните как было.
  6. Повторите.
  7. Go to 1.

Увидеть улучшение или ухудшение просто. Объяснить причину изменений и масштабировать ее — ой какое неблагодарное занятие.

2. Нужна крутая аналитика. Или аналитик


Мы в своем проекте помимо Google Analytics и Яндекс.Метрики еще использовали самописную аналитику и выгружали сырые данные в Excel для ручного подсчета. Как мне известно, крупные e-commerce проекты живут примерно так же (по крайней мере жили). Они измеряют все в нескольких системах, так как они считают по разному и дают разную погрешность. У одного и того же сайта данные посещений по ЯМ и GA могут сильно отличаться. Увы, если бы это было главной проблемой: системы аналитики не очень полезны, когда вам нужно одновременно уметь считать коммерческие и продуктовые показатели.

Может так получиться, что с новым баннером доход за месяц вырос. Только возвращаемость (или ретеншен) стал падать. Ядро аудитории стало больше «раздражаться». То есть, через несколько месяцев вы потеряете в трафике и, опять же, «на круг» заработаете меньше.

К чему я веду? К тому, что чисто статистически, учесть все причины и правильно измерить результат изменения фактически невозможно. Методологически (математически) правильно считать естественную погрешность показателей, и если эксперимент дает рост больше погрешности — то только тогда можно подумать о том, стоит ли оставлять новое решение.

Естественные колебания показателей могут достигать 10%-20%, так что если вы поставили баннер и получили изменение прибыли на 5% — это ничего не значит. Вообще ничего.

Перекрасили кнопку в розовый? Конверсия выросла на 9%?
Ха-ха ;)

3. А/В-тестирование очень дорогое


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

Отличная идея.

Если продукт с историей, high-load, настроено кэширование, разные сервера для контента и еще много всяких радостей, то вряд ли этот проект изначально затачивался на разветление продкашена. То есть архитектурно, проект не готов к тесту. Это значит что если вы придете к backend-программисту и скажете:

— Коля, а давай мы на 8% аудитории будем показывать другую верстку страницы регистрации, причем они еще там должны регистрироваться. Да, поля другие. Да, еще надо, чтобы страница персонализировалась, если он вернется. А я уже говорил что статистику надо модифицировать? Ээ, чо я такого сказал, что ты кипятишься?!
Ваш первый А/В-тест будет полон технических сюрпризов и веселья, особенно если что-то отвалится и вы «перемешаете» аудиторию. Конечно, в идеальных проектах такого нет, но в реальности встречается постоянно.

Когда вы с этим справитесь и даже потестируете что-нибудь, вы поймете что небольшие изменения дают небольшой результат. То есть, если на кнопке сделать скругление краев и поменять цвет с синего на зеленый — большинство пользователей не заметят этого. Если вы хотите ощутимый результат — делайте «крупные» изменения. Было 12 полей ввода для регистрации, а осталось 4? Это существенно.

Главный вопрос в том, что если вы можете обойтись 4 полями, вместо 12… почему вы это еще не сделали? Разве вам нужно подтверждение А/В-тестом или мнением авторитетного UX-специалиста для правильного вывода в этой ситуации?

И даже если вы все равно решили сделать A/B тест… готовьтесь выложить минимум половину первоначальной стоимости страницы для подготовки второго, тестового, варианта.

А вы как думали? Еще не верите, что выхлоп очень сомнителен по сравнению с затратами?

4. Другие действия дают больше пользы.


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

Почему А/В-тесты так популярны?


Думаю, потому что крупные компании их используют и непроизвольно пиарят. Для них они необходимы, так как они уже попробовали все для своих продуктов и теперь вынуждены «выжимать камень» в поисках крупиц пользы. У них есть на это ресурсы, деньги и желание.

Например, Яндекс.Музыка использует eye-tracking (целый набор инструментов, который изучает куда смотрит глаз человека во время использования мобильного приложения). Да, штука полезная, когда у тебя есть бюджет. Не рекомендовать же теперь это всем?

А/В-тест легко продается некомпетентным людям. Можно что-то сделать и сказать в отчете, что «возвращаемость аудитории из камчатского региона выросла на 8%». Как это влияет на прибыль? Такой вопрос редко ставят. В общем, аналитики и проектировщики хотят есть свой хлеб ;)

Главный вывод про кнопки и интерфейсы


Делайте аккуратно, удобно и со вкусом. Этого будет достаточно. Если ваш продукт так себе и call-центр хамит клиентам — ни один интерфейс не исправит ситуацию.

Сделали нормальный дизайн, продумали сценарии использования, посидели над текстами, нарисовали приятную графику? Круто, вы уже достигли 96% эффективности!

Достичь оставшиеся 4% за счет интерфейсных улучшений — утопия. Не живите в утопии.

Получается, A/B-тесты — мертвая история?


Нет, конечно! Сама методология прекрасна, если вы работаете в более контролируемых условиях, например, во время тестирования контекстной рекламы или e-mail рассылок. Тексты, в принципе, легко тестировать, в отличии от дизайна. Лэндинги тоже хорошо поддаются экспериментам, но будьте внимательны с интерпретацией результатов ;)
Tags:
Hubs:
Total votes 14: ↑9 and ↓5 +4
Views 6.4K
Comments Comments 19