* для сайтов и мобильных приложений
Мой путь в IT начинался с UX-специалиста (да-да), то есть с проектирования решений и аналитики. Текущий пост является, в каком-то смысле, результатом работы в этом направлении.
По своему опыту и опыту коллег, могу сказать, что почти ни у одной компании нет нормального А/В тестирования, поставленного на поток. Говорят, кто-то где-то видел, но, по сути, честное А/В-тестирование не найти.
Почему так? Давайте разбираться.
Однажды, на одном проекте (суточный трафик порядка 800 000 уникальных пользователей) мы задались целью внедрить А/В тестирование.
Вот с чем мы столкнулись:
1. Трудно с точки зрения «чистоты эксперимента»
Пока не берем А/В-тестирование, а разберем «простой» пример, когда вы добавили еще один рекламный баннер себе на сайт и измерили показатели.
На него кликают, начали капать деньги.
Что стало с другими баннерами и их конверсией? Если вам не повезло, то, скорее всего, суммарный доход не изменился или вообще упал.
А теперь представьте, что вам повезло и доход вырос. Разве дело только в баннере? Может изменился трафик? Сработала сезонность или разовый вирусный эффект в соц.сетях? Пока вы тестируете, продукт живет и развивается, очень трудно найти «чистый» месяц, который был бы «без влияния» маркетинга, портящего эксперимент.
Нужно хорошо разобраться в возможных внешних причинах, а это почти всегда гадание на кофейной гуще. Конечно, вы можете маниакально принять во внимание все показатели продукта… чтобы гадание на кофейной гуще было чуточку научнее.
Как действовать в подобной ситуации? Следовать простому алгоритму:
- Придумали гипотезу.
- Внедрили изменение.
- Измерили главные показатели через месяц (или другой период: день или квартал).
- Стало лучше? Можно оставлять.
- Стало хуже? Верните как было.
- Повторите.
- 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 рассылок. Тексты, в принципе, легко тестировать, в отличии от дизайна. Лэндинги тоже хорошо поддаются экспериментам, но будьте внимательны с интерпретацией результатов ;)
Комментарии (19)
farwayer
07.02.2017 20:13+1Угадал ваш последний абзац ;) Про call-центр золотые слова. Про 96% в точку. Не всегда, правда, с самого начала интерфейс получается близким к идеальному. Но A/B тестирование тут все равно не поможет. А какое-то улучшение обычно заметно и без цифр.
Где хорошо работает A/B тестирование интерфейса? В тех же игровых магазинах. Да и вообще в играх с кнопками доната на разных экранах. Но, само-собой, нужно разделение трафика.
SoulAge
07.02.2017 21:58Да, про игры, согласен. Почему-то я про них даже не вспомнил ;)
Но, по мне, это пока единственное исключение из интерфейсов, которое подходит для сплиттестирования.
bobermaniac
07.02.2017 20:38+2Мне что-то подсказывает, что А/B тестирование — это немного не «посмотрим продажи в январе, потом скруглим кнопку и посмотрим продажи в мае». Как минимум нужно сравнивать в одинаковых условиях. И метрики нужно брать вменяемые. И выборки побольше.
SoulAge
07.02.2017 21:48Я полагаю, у вас в голове все перемешалось и вы, походу, не поняли мысль поста:
1. Сначала в первых двух пунктах на простом примере показывается что аналитика это в принципе сложно, с научной точки зрения.
2. В пункте 3 в первой строке говорится что:
А давайте одновременно показывать разные варианты разным людям, тогда мы не будем зависеть от изменчивости трафика, а также исключим сезонность и маркетинг?
Может я неочевидно выразился, но имеется в виду что мы A/B-тест делаем в одинаковых условиях.SoulAge
07.02.2017 21:52Переписал эту строчку, чтобы было поочевиднее:
А давайте одновременно показывать разные варианты дизайна разным людям, но из одинакового источника? Тогда мы не будем зависеть от изменчивости трафика, а также исключим сезонность и маркетинг.
Antelle
07.02.2017 21:33Тестировать две версии не в одно время — выстрелить себе в ногу, надо рандомно распределять юниты между вариантами, и никак по-другому. Это же очевидно.
Как это влияет на прибыль? Такой вопрос редко ставят.
В любой уважающей себя компании в системе A/B тестирования одним их первых показателей всегда будет метрика, влияющая на прибыль.
SoulAge
07.02.2017 21:50«Метрика, влияющая на прибыль» — это не то же самое что метрика «прибыль».
В посте как раз говорится, что подняв одну метрику, вы можете уронить другую. Правильно смотреть только на итог, то есть на прибыль. А она у вас зависит вообще от кучи факторов, в том числе от внешних, которые от вас не зависят, например, праздник в каком-нибудь регионе.Antelle
07.02.2017 22:05+1Это я так обошёл понятие "прибыль" или, как вы говорите, "итог", потому что метрики, влияющие на краткосрочную и долгосрочную прибыль немного отличаются. Net customers, net conversion и net revenue это разные метрики, которые, вообще говоря и есть прибыль, но разных видов. Какую из них оптимизировать, вопрос очень хороший, решаться может по-разному.
Праздник в каком-нибудь другом регионе одинаково повлияет на оба варианта, если, опять же, распределять пользователей равномерно.
Shaco
07.02.2017 21:59Из вашей статьи я так и не понял, что конкретно вы пробовали, а что — ваши домыслы за фразами «представьте» и «может так получиться». Зато понял, что, с вашей точки зрения, у разработчиков может бомбить, когда вы предлагаете сделать отдельную страницу для новой формы регистрации с отдельным поведением. Вы знаете, я могу в такое поверить, только если в приведённом монологе каждое предложение было спустя пару дней после предыдущего. Потому что это бы показывало, что вы сами не знаете, что вам надо, и не в состоянии формализовать требования. В остальном — это обычная задача, никто с неё кипятиться не будет. То, что для минимизации наводок разумно показывать оба варианта сразу, разным пользователям — мне казалось достаточно очевидным, чтобы люди не пытались тестировать варианты по очереди.
Насчёт аналитики результатов — ну, да, это работа, которую должен работать человек, который в этом разбирается или, на худой конец, хочет научиться разбираться и прикладывает к этому усилия. Нет, A/B-тестирование — это не про то, чтобы генератор случайных чисел и два цвета кнопки повышали вам конверсию на 10%. Это инструмент, которому нужен мастер. Который понимает, что надо проверить, и как именно это надо сделать — например, какие метрики снимать в процессе.
В общем, вы уж простите, но описанных вами предположений явно недостаточно для того, чтобы «заколачивать крышку гроба».SoulAge
07.02.2017 22:12Так пост же не про кейсы, пост про «идеи». Разве их нельзя понять без конкретной истории? ;D
Чем плох A/B-тест интерфейсов?
Очень трудно обеспечить нормальную чистоту эксперимента, поэтому чтобы результаты были достоверными, нужно внимательно отнестись к вопросу с погрешностью и измерениями.
Из-за огромного количества неизвестных факторов, поле возможных гипотез вообще трудно поддается адекватной оценке. Более того, из-за этого вам еще труднее накапливать знания и транслировать их на будущие проекты. Если вы хотите сделать все «честно» и без гаданий — все это требует аккуратной математики и, какого-то, опыта. Вы правы, без мастера не обойтись, но скажите мне, вы много видали аналитиков или пмов, кто погрешность считает для своего проекта?
Это не предположения, это нормальный научный подход. Я предполагаю только одну вещь: в большинстве компаний народ занимается псевдотестами, выдавая их с умным видом как необыкновенный результат… который по сути является гаданием.
Я забиваю гвоздик не в крышку сплиттестирования, метод как метод.
Я мечтаю забить гвоздик в головы людей, кто думает что A/B-тесты это просто/панацея/нужно всем и в любом проекте.Shaco
08.02.2017 00:15В ваших рассуждениях есть рациональное зерно. Однако, вы столь же безапелляционно заявляете, что A/B не нужны, прямо в заголовке, как и те, «кто думает что A/B-тесты это просто/панацея/нужно всем и в любом проекте». Бросаться из крайности в крайность — это не то, чтобы не научный подход, это просто неразумно.
Давайте я выступлю адвокатом дьявола, и приведу несколько аргументов за A/B тесты, даже если они недостаточно хорошо учитывают все факторы. Так или иначе, все живые проекты меняют что-то. Раз уж вы в статье ведёте речь об интерфейсе, давайте этим «чем-то» он и будет.
Предположим, вы хотите изменить какой-то элемент управления. У вас даже есть видение того, как именно это нужно сделать, и почему это будет лучше, чем текущий вариант (и я со всей ответственностью уверяю, что эти два пункта далеко не всегда выполняются...). Подход с A/B тестированием означает, что вам нужно формализовать свою гипотезу. Это уже хорошо — если вам приходится описать то, что есть в голове, словами на бумаге или в задачнике, зачастую уже на этом этапе видны недочёты. Так или иначе вы с ними справитесь, задача уйдёт в разработку.
В результате вы наснимаете каких-то метрик. Возможно даже, эти метрики будут недостаточно качественными, не учтут каких-то факторов, и так далее. Однако, теперь вы можете оперировать данными! Не ощущениями, не желаниями левой пятки, а вполне конкретными цифрами. Естественно, если вы «эффективный менеджер», вы можете вывернуть цифры так, чтобы представить их, как нужный вам результат. Но, положа руку на сердце, что вам мешает без всяких тестов сделать то же самое? Такое отношение к делу — проблема конкретных людей и рабочих процессов, в которых они участвуют, но не инструмента A/B-тестирования.SoulAge
08.02.2017 01:26Я полагаю, мы пришли к консенсусу.
A/B-тесты как метод прекрасен, если с ним правильно работать. Мой посыл про то, что есть некий миф, о том, что A/B-тест пригодится в каждом проекте. Цель моего поста поделиться некими соображениями на тему того, что это сложный метод и можно прекрасно обойтись без него. Другими словами, ценность сплиттестирования интерфейсов для сайтов и мобильных приложений (кроме игр) переоценена.
Так или иначе, это мой взгляд, разумеется он может отличаться от общепринятого или чьего-то частного мнения.
А заголовок… ну да, легкий кликбайт, зато честный, со сноской и последующей попыткой доказать утверждение ;)
4vanger
09.02.2017 05:54A/B тестирование ни в коем случае не панацея и оно подходит и нужно далеко не всем — сайты с маленьким траффиком просто физически не могут ничего проверить — на достижение statistically significant результатов уйдёт слишком много времени и результаты будут смазаны. Но то что вы написали — это полный бред.
1. Проблема «чистоты эксперимента» решается контрольной группой — в простейшем случае 50% траффика кидать на оригинал, 50% на вариацию. Тогда у вас будет одинаковый траффик в обоих случаях и результаты будут сравнимы.
2. Аналитик не нужен. Нужен тот, кто сможет грамотно составить эксперимент и установить цели. Это нетривиально, но ничего особенного.
3. Зачастую бывает достаточно сменить лейбл или дефолтный текст в поле, чтобы увеличить конверсию. или разбить форму на шаги. Для изменений подразумевающих смену бэкэнда — конечно вам придётся его менять — никто не сделает это за вас.
4. если умножить всё вами перечисленное на a/b тестирование — то получится ещё больше. Единственная цель a/b теста — увеличить размер воронки конверсии. Тогда вы получите больше из той аудитории, которую приведёте распродажей или рекламной компанией.
Aquahawk
А нефиг тестировать скругление кнопки. Ценообразование прекрасно тестируется. И да строго в разрезе источников трафика и соцдема. Масштабность наград в играх тоже. И чтобы получить вменяемое p-value (мы же на него смотрим) часто нужно очень много трафика, поэтому стартапам на ранней стадии AB не подходит совсем.
SoulAge
В итоге, получается, что хорошо тестируется только… текст и числа? ;)
Aquahawk
Чем меньше изменение тем лучше. Целиком механики можно тестить, но гораздо сложнее.
SoulAge
Вы же говорите о том, что изменять нужно только один параметр, но достаточно существенно, чтобы появилась разница?
А вы сами проводили A/B-тесты? И тестировали целые механики? Вы погрешность считали или все на глазок?
Aquahawk
Проводил, десятками. Все оценки строго по p value. 90% тестов даже весьма смелых, статистически значимого эффекта не выявляют, или выявляют прямой эффект, но не целевой. Пример: В туторе игры тестируем как ставить здания: сразу автоматом, за пользователя, или дать ему поставить самому. Так вот, если ставить за него, он немного дальше проходит по игре, но ретеншн следующего дня не меняется значимо. Вообще повлиять в первой сессии на ретеншн крайне сложно.