Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
А нефиг тестировать скругление кнопки. Ценообразование прекрасно тестируется. И да строго в разрезе источников трафика и соцдема. Масштабность наград в играх тоже. И чтобы получить вменяемое p-value (мы же на него смотрим) часто нужно очень много трафика, поэтому стартапам на ранней стадии AB не подходит совсем.
В итоге, получается, что хорошо тестируется только… текст и числа? ;)
Чем меньше изменение тем лучше. Целиком механики можно тестить, но гораздо сложнее.
Вы же говорите о том, что изменять нужно только один параметр, но достаточно существенно, чтобы появилась разница?
А вы сами проводили A/B-тесты? И тестировали целые механики? Вы погрешность считали или все на глазок?
А вы сами проводили A/B-тесты? И тестировали целые механики? Вы погрешность считали или все на глазок?
Проводил, десятками. Все оценки строго по p value. 90% тестов даже весьма смелых, статистически значимого эффекта не выявляют, или выявляют прямой эффект, но не целевой. Пример: В туторе игры тестируем как ставить здания: сразу автоматом, за пользователя, или дать ему поставить самому. Так вот, если ставить за него, он немного дальше проходит по игре, но ретеншн следующего дня не меняется значимо. Вообще повлиять в первой сессии на ретеншн крайне сложно.
Мне что-то подсказывает, что А/B тестирование — это немного не «посмотрим продажи в январе, потом скруглим кнопку и посмотрим продажи в мае». Как минимум нужно сравнивать в одинаковых условиях. И метрики нужно брать вменяемые. И выборки побольше.
Я полагаю, у вас в голове все перемешалось и вы, походу, не поняли мысль поста:
1. Сначала в первых двух пунктах на простом примере показывается что аналитика это в принципе сложно, с научной точки зрения.
2. В пункте 3 в первой строке говорится что:
Может я неочевидно выразился, но имеется в виду что мы A/B-тест делаем в одинаковых условиях.
1. Сначала в первых двух пунктах на простом примере показывается что аналитика это в принципе сложно, с научной точки зрения.
2. В пункте 3 в первой строке говорится что:
А давайте одновременно показывать разные варианты разным людям, тогда мы не будем зависеть от изменчивости трафика, а также исключим сезонность и маркетинг?
Может я неочевидно выразился, но имеется в виду что мы A/B-тест делаем в одинаковых условиях.
«Метрика, влияющая на прибыль» — это не то же самое что метрика «прибыль».
В посте как раз говорится, что подняв одну метрику, вы можете уронить другую. Правильно смотреть только на итог, то есть на прибыль. А она у вас зависит вообще от кучи факторов, в том числе от внешних, которые от вас не зависят, например, праздник в каком-нибудь регионе.
В посте как раз говорится, что подняв одну метрику, вы можете уронить другую. Правильно смотреть только на итог, то есть на прибыль. А она у вас зависит вообще от кучи факторов, в том числе от внешних, которые от вас не зависят, например, праздник в каком-нибудь регионе.
Из вашей статьи я так и не понял, что конкретно вы пробовали, а что — ваши домыслы за фразами «представьте» и «может так получиться». Зато понял, что, с вашей точки зрения, у разработчиков может бомбить, когда вы предлагаете сделать отдельную страницу для новой формы регистрации с отдельным поведением. Вы знаете, я могу в такое поверить, только если в приведённом монологе каждое предложение было спустя пару дней после предыдущего. Потому что это бы показывало, что вы сами не знаете, что вам надо, и не в состоянии формализовать требования. В остальном — это обычная задача, никто с неё кипятиться не будет. То, что для минимизации наводок разумно показывать оба варианта сразу, разным пользователям — мне казалось достаточно очевидным, чтобы люди не пытались тестировать варианты по очереди.
Насчёт аналитики результатов — ну, да, это работа, которую должен работать человек, который в этом разбирается или, на худой конец, хочет научиться разбираться и прикладывает к этому усилия. Нет, A/B-тестирование — это не про то, чтобы генератор случайных чисел и два цвета кнопки повышали вам конверсию на 10%. Это инструмент, которому нужен мастер. Который понимает, что надо проверить, и как именно это надо сделать — например, какие метрики снимать в процессе.
В общем, вы уж простите, но описанных вами предположений явно недостаточно для того, чтобы «заколачивать крышку гроба».
Насчёт аналитики результатов — ну, да, это работа, которую должен работать человек, который в этом разбирается или, на худой конец, хочет научиться разбираться и прикладывает к этому усилия. Нет, A/B-тестирование — это не про то, чтобы генератор случайных чисел и два цвета кнопки повышали вам конверсию на 10%. Это инструмент, которому нужен мастер. Который понимает, что надо проверить, и как именно это надо сделать — например, какие метрики снимать в процессе.
В общем, вы уж простите, но описанных вами предположений явно недостаточно для того, чтобы «заколачивать крышку гроба».
Так пост же не про кейсы, пост про «идеи». Разве их нельзя понять без конкретной истории? ;D
Чем плох A/B-тест интерфейсов?
Очень трудно обеспечить нормальную чистоту эксперимента, поэтому чтобы результаты были достоверными, нужно внимательно отнестись к вопросу с погрешностью и измерениями.
Из-за огромного количества неизвестных факторов, поле возможных гипотез вообще трудно поддается адекватной оценке. Более того, из-за этого вам еще труднее накапливать знания и транслировать их на будущие проекты. Если вы хотите сделать все «честно» и без гаданий — все это требует аккуратной математики и, какого-то, опыта. Вы правы, без мастера не обойтись, но скажите мне, вы много видали аналитиков или пмов, кто погрешность считает для своего проекта?
Это не предположения, это нормальный научный подход. Я предполагаю только одну вещь: в большинстве компаний народ занимается псевдотестами, выдавая их с умным видом как необыкновенный результат… который по сути является гаданием.
Я забиваю гвоздик не в крышку сплиттестирования, метод как метод.
Я мечтаю забить гвоздик в головы людей, кто думает что A/B-тесты это просто/панацея/нужно всем и в любом проекте.
Чем плох A/B-тест интерфейсов?
Очень трудно обеспечить нормальную чистоту эксперимента, поэтому чтобы результаты были достоверными, нужно внимательно отнестись к вопросу с погрешностью и измерениями.
Из-за огромного количества неизвестных факторов, поле возможных гипотез вообще трудно поддается адекватной оценке. Более того, из-за этого вам еще труднее накапливать знания и транслировать их на будущие проекты. Если вы хотите сделать все «честно» и без гаданий — все это требует аккуратной математики и, какого-то, опыта. Вы правы, без мастера не обойтись, но скажите мне, вы много видали аналитиков или пмов, кто погрешность считает для своего проекта?
Это не предположения, это нормальный научный подход. Я предполагаю только одну вещь: в большинстве компаний народ занимается псевдотестами, выдавая их с умным видом как необыкновенный результат… который по сути является гаданием.
Я забиваю гвоздик не в крышку сплиттестирования, метод как метод.
Я мечтаю забить гвоздик в головы людей, кто думает что A/B-тесты это просто/панацея/нужно всем и в любом проекте.
В ваших рассуждениях есть рациональное зерно. Однако, вы столь же безапелляционно заявляете, что A/B не нужны, прямо в заголовке, как и те, «кто думает что A/B-тесты это просто/панацея/нужно всем и в любом проекте». Бросаться из крайности в крайность — это не то, чтобы не научный подход, это просто неразумно.
Давайте я выступлю адвокатом дьявола, и приведу несколько аргументов за A/B тесты, даже если они недостаточно хорошо учитывают все факторы. Так или иначе, все живые проекты меняют что-то. Раз уж вы в статье ведёте речь об интерфейсе, давайте этим «чем-то» он и будет.
Предположим, вы хотите изменить какой-то элемент управления. У вас даже есть видение того, как именно это нужно сделать, и почему это будет лучше, чем текущий вариант (и я со всей ответственностью уверяю, что эти два пункта далеко не всегда выполняются...). Подход с A/B тестированием означает, что вам нужно формализовать свою гипотезу. Это уже хорошо — если вам приходится описать то, что есть в голове, словами на бумаге или в задачнике, зачастую уже на этом этапе видны недочёты. Так или иначе вы с ними справитесь, задача уйдёт в разработку.
В результате вы наснимаете каких-то метрик. Возможно даже, эти метрики будут недостаточно качественными, не учтут каких-то факторов, и так далее. Однако, теперь вы можете оперировать данными! Не ощущениями, не желаниями левой пятки, а вполне конкретными цифрами. Естественно, если вы «эффективный менеджер», вы можете вывернуть цифры так, чтобы представить их, как нужный вам результат. Но, положа руку на сердце, что вам мешает без всяких тестов сделать то же самое? Такое отношение к делу — проблема конкретных людей и рабочих процессов, в которых они участвуют, но не инструмента A/B-тестирования.
Давайте я выступлю адвокатом дьявола, и приведу несколько аргументов за A/B тесты, даже если они недостаточно хорошо учитывают все факторы. Так или иначе, все живые проекты меняют что-то. Раз уж вы в статье ведёте речь об интерфейсе, давайте этим «чем-то» он и будет.
Предположим, вы хотите изменить какой-то элемент управления. У вас даже есть видение того, как именно это нужно сделать, и почему это будет лучше, чем текущий вариант (и я со всей ответственностью уверяю, что эти два пункта далеко не всегда выполняются...). Подход с A/B тестированием означает, что вам нужно формализовать свою гипотезу. Это уже хорошо — если вам приходится описать то, что есть в голове, словами на бумаге или в задачнике, зачастую уже на этом этапе видны недочёты. Так или иначе вы с ними справитесь, задача уйдёт в разработку.
В результате вы наснимаете каких-то метрик. Возможно даже, эти метрики будут недостаточно качественными, не учтут каких-то факторов, и так далее. Однако, теперь вы можете оперировать данными! Не ощущениями, не желаниями левой пятки, а вполне конкретными цифрами. Естественно, если вы «эффективный менеджер», вы можете вывернуть цифры так, чтобы представить их, как нужный вам результат. Но, положа руку на сердце, что вам мешает без всяких тестов сделать то же самое? Такое отношение к делу — проблема конкретных людей и рабочих процессов, в которых они участвуют, но не инструмента A/B-тестирования.
Я полагаю, мы пришли к консенсусу.
A/B-тесты как метод прекрасен, если с ним правильно работать. Мой посыл про то, что есть некий миф, о том, что A/B-тест пригодится в каждом проекте. Цель моего поста поделиться некими соображениями на тему того, что это сложный метод и можно прекрасно обойтись без него. Другими словами, ценность сплиттестирования интерфейсов для сайтов и мобильных приложений (кроме игр) переоценена.
Так или иначе, это мой взгляд, разумеется он может отличаться от общепринятого или чьего-то частного мнения.
А заголовок… ну да, легкий кликбайт, зато честный, со сноской и последующей попыткой доказать утверждение ;)
A/B-тесты как метод прекрасен, если с ним правильно работать. Мой посыл про то, что есть некий миф, о том, что A/B-тест пригодится в каждом проекте. Цель моего поста поделиться некими соображениями на тему того, что это сложный метод и можно прекрасно обойтись без него. Другими словами, ценность сплиттестирования интерфейсов для сайтов и мобильных приложений (кроме игр) переоценена.
Так или иначе, это мой взгляд, разумеется он может отличаться от общепринятого или чьего-то частного мнения.
А заголовок… ну да, легкий кликбайт, зато честный, со сноской и последующей попыткой доказать утверждение ;)
A/B тестирование ни в коем случае не панацея и оно подходит и нужно далеко не всем — сайты с маленьким траффиком просто физически не могут ничего проверить — на достижение statistically significant результатов уйдёт слишком много времени и результаты будут смазаны. Но то что вы написали — это полный бред.
1. Проблема «чистоты эксперимента» решается контрольной группой — в простейшем случае 50% траффика кидать на оригинал, 50% на вариацию. Тогда у вас будет одинаковый траффик в обоих случаях и результаты будут сравнимы.
2. Аналитик не нужен. Нужен тот, кто сможет грамотно составить эксперимент и установить цели. Это нетривиально, но ничего особенного.
3. Зачастую бывает достаточно сменить лейбл или дефолтный текст в поле, чтобы увеличить конверсию. или разбить форму на шаги. Для изменений подразумевающих смену бэкэнда — конечно вам придётся его менять — никто не сделает это за вас.
4. если умножить всё вами перечисленное на a/b тестирование — то получится ещё больше. Единственная цель a/b теста — увеличить размер воронки конверсии. Тогда вы получите больше из той аудитории, которую приведёте распродажей или рекламной компанией.
1. Проблема «чистоты эксперимента» решается контрольной группой — в простейшем случае 50% траффика кидать на оригинал, 50% на вариацию. Тогда у вас будет одинаковый траффик в обоих случаях и результаты будут сравнимы.
2. Аналитик не нужен. Нужен тот, кто сможет грамотно составить эксперимент и установить цели. Это нетривиально, но ничего особенного.
3. Зачастую бывает достаточно сменить лейбл или дефолтный текст в поле, чтобы увеличить конверсию. или разбить форму на шаги. Для изменений подразумевающих смену бэкэнда — конечно вам придётся его менять — никто не сделает это за вас.
4. если умножить всё вами перечисленное на a/b тестирование — то получится ещё больше. Единственная цель a/b теста — увеличить размер воронки конверсии. Тогда вы получите больше из той аудитории, которую приведёте распродажей или рекламной компанией.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
A/B тесты не нужны*