Меня зовут Сергей Гудков, я Product Manager в Preply и куратор в Projector. В этой статье я хочу поделиться типичными ошибками, с которыми сталкиваются новички при внедрении А/Б-тестирования в компаниях. Это поможет вам внедрить тестирование быстрее, без ущерба бизнесу, а также сэкономить время команды.
А/Б-тесты являются одним из основных инструментов проверки продуктовых и маркетинговых гипотез. Свой первый тест я запустил в 2011 году. Тогда мы поспорили с моим руководителем, чья идея лучше и принесет больше денег бизнесу. Во многих компаниях тесты являются обязательным этапом внедрения любого изменения в продукт. Это позволяет компаниям оставлять в продукте только то, что действительно полезно для пользователей, партнеров и бизнеса.
HiPPO — это английская аббревиатура, которая означает «Мнение самого высокооплачиваемого человека» (Highest Paid Person’s Opinion). По сути, приходит начальник и говорит, что лучше знает, что надо делать, и вся команда просто должна следовать плану.
HiPPO как метод принятия решения обычно противопоставляется подходу, основанному на данных. Все смотрят на начальника, старшего, лидера. Проблема в том, что каждый человек в разной степени предвзят. Это несомненно мешает принимать верные решения в длительной перспективе.
В реальной жизни это выглядит примерно так. Приходит руководитель и говорит, что его сосед по дачному участку смотрел сайт или использовал продукт и дал несколько дельных советов. Нам обязательно надо все внедрить, но через А/Б-тест. Гипотезы не имеют под собой реальных оснований, хотя идеи звучат великолепно. Да, идея и гипотеза — это не одно и тоже, но об этом в другой раз. Сосед не является представителем целевой аудитории. Эксперимент проигрывает.
Так происходит несколько раз. Эксперименты не выигрывают, тратятся ресурсы, время уходит, ничего не работает. Под удар попадает сама идея экспериментов. Тесты не работают, все это сказки. Компания отказывается от инструмента тестирования и продолжает вслепую внедрять идеи руководителя.
Лучше всего работает независимая методика, алгоритм приоритизации гипотез. Одной из самых распространенных на сегодня является методика RICE. Гипотеза новичка рассматривается и оценивается наравне с гипотезой опытного сотрудника или гендиректора. Никто не может быть более правым, чем фактические данные.
Несколько лет назад у меня был случай, когда junior соседней команды подошел с просьбой дать ему какой-то простой А/Б-тест, чтобы он попробовал его запустить самостоятельно. Мне это ничего не стоило, и я просто вытащил самую технически легкую гипотезу из бэклока. Руководитель узнал об этом, когда разработчик все уже сделал и был готов запускать. Гипотеза руководителю совсем не нравилась, но я все же запустил эксперимент на свой страх и риск. Мне очень-очень повезло, что через месяц тест выиграл. С тех пор руководитель только предлагал свои гипотезы и просил объяснять принципы приоритезации, но никогда больше не блокировал наши тесты.
В начале пути обычно именно HiPPO приносят идеи извне. Он прочитал, услышал на конференции, узнал от коллег по рынку новый кейс. Презентация кейса была очень вдохновляющей, сама идея выглядела настолько простой и изящной, что становится непонятно, как же сами до этого не додумались. Нет никаких сомнений, что сработает и у вас.
Дело в том, что решение сработает только, если у вас есть такая же проблема. А это уже не факт. Это как в очереди к врачу обсудить свои симптомы и начать принимать лекарства соседа, но к врачу так и не зайти. Разумеется, что лекарство от того, чего у вас нет, не сработает. Так же и с внедрением чужих решений. В результате, как и с прошлой проблемой, во всем виноваты тесты и зачем вообще их делать, без тестов же все было замечательно.
Решить это поможет наличие списка проблем ваших клиентов, пользователей, посетителей. С актуальным списком проблем вы всегда можете проверить, подходит ли решение для чего-то из списка. Не стоит чинить то, что не сломано.
Года четыре назад я работал в автомобильной тематике, что-то вроде маркетплейса авто. Ко мне временами прилетали идеи, взятые с сайтов автосалонов. Когда у меня не получалось отбиться, мы вынуждены были тестировать эти идеи. Ничего не выстрелило. Люди на интервью так и говорили: «если бы мне надо было это, я бы пошел в салон». Получается, мы тратили время и ресурсы, тестируя подобные вещи.
Представьте, что вы подбрасываете монетку десять раз. 5 раз выпадает орел, и 5 раз — решка. Потом вы сделали изменение, подпилили монетку напильником слегка. Бросаете еще 10 раз. Орел выпадает 6 раз, что скажете? Такое случается? Сколько раз должен выпасть орел, чтобы вы были уверены, что с монеткой стало что-то не так, и орел выпадает чаще?
В разных тестах и при разных условиях используются разные математические методы. Но цель всегда одна — понять, действительно ли результаты эксперимента (орел выпал чаще) вызваны нашими изменениями (мы подпилили монетку).
Досрочное завершение теста — это когда вы бросаете монетку три раза из 10, и неожиданным образом все три раза выпадает орел. «Ну вот оно! Работает! Теперь монетка волшебная, всегда выпадает орел». После этого вы решаете, что делать оставшиеся семь бросков смысла уже не имеет, и так уже все понятно.
В бизнеса желание завершить эксперимент раньше очень усугубляется слепым желанием заработать или избежать потерь. Если видят, что несколько дней положительная динамика, и что каждый день приносит +10% денег, то зачем же продолжать получать +10% только с половины трафика, а не со всего? Аналогично с потерями, каждый день терять 10% очень больно.
Посмотрите на скриншот. Вариант 1 приносит здесь и сейчас на 20.6% больше. Вероятность победы 89%. Сколько вы хотите еще ждать и терять деньги?
Такое поведение очень опасно и приводит к внедрению случайных изменений. С одной стороны, это просто трата ресурсов и драгоценного времени на то, что не работает. С другой стороны, внедряются изменения, которые наносят вред бизнесу.
Вы справедливо можете заметить, что если это приводит к внедрению случайных изменений, то внедряются и изменения, которые улучшают бизнес. Вы правы. Но положительные изменения менее вероятны, чем негативные. Представьте себе весь перечень лекарств. Какова вероятность, что, выбирая лекарства наугад, вы вылечитесь, а не наоборот? И помните, что эффект от всех лекарств накапливается.
Решение здесь одно. Всегда ждите завершения теста. Если ваш инструмент не дает однозначной оценки победы, попросите помощи у аналитиков.
Одна из самых поучительных историй произошла осенью 2012 года. Мы очень быстро начали внедрять А/Б-тестирование и запускали несколько тестов в неделю. У всех была эйфория, и все смотрели на результаты по несколько раз в день. Если положительный тренд держался несколько дней, то ура-ура, принимали решение оставлять на сайте.
К ноябрю, спустя месяца два, у нас было очень много нового на сайте. Но в один день продажи просто упали. Мы почти трое суток ночевали на работе, закопавшись в аналитику. В конечном итоге мы пришли к выводу, что каждый такой тест менял поведение людей не в лучшую сторону, но так как мы не ждали завершения теста, то узнать о реальном влиянии на бизнес не могли.
Мы приняли решения откатить все изменения за последние два месяца. Через сутки продажи вернулись на прежний уровень, а мы научились ждать завершения тестов.
Когда вы собираетесь в магазин, то хотите тем или иным образом убедиться, что у вас хватит денег на все покупки, которые собираетесь сделать. Аналогичным образом следует поступать и с экспериментами.
До того, как будет решено начать разработку, необходимо рассчитать минимальный обнаруживаемый эффект (MDE — Minimum Detectable Effect). Например, расчет MDE может показать, что любой рост менее 42% не будет значимым. Здесь стоит спросить себя, а верим ли мы, что новый цвет кнопки поможет поднять продажи на 42%?
По сути, ошибка здесь — это запуск тестов, которые скорее всего не смогут достичь значимых результатов. Это само по себе трата времени и ресурсов.
Расчет MDE является неотъемлемой частью составления дизайна самого эксперимента, где необходимо определить, кто войдет в тест, где будет происходить разделение аудитории на группы и т.д.
В моей сегодняшней практике MDE отсеивает примерно треть гипотез. Давайте приведу пример. Я очень люблю социальное доказательство и все, что с ним связано. Вот пример одного теста с нашего сайта.
Изначально, мы планировали выводить количество забронированных уроков за последний час. Очевидно, что общее количество репетиторов, у которых забронировали уроки за последний час намного меньше, чем тех, у кого бронировали уроки за последние 12, 24 или 48 часов.
Посчитав MDE для всех случаев, стало очевидно, что 48 часов — это идеальный вариант: много репетиторов, привлекательное количество забронированных уроков, достаточный трафик и конверсия. Если бы мы запустили, как изначально планировали, то не было бы даже шанса получить какой-то результат.
А/Б-тесты — хороший инструмент в умелых руках. Как и любой инструмент, эксперименты идеально подходят для одних задач и совершенно бесполезны для других. Уверенное владение таким инструментом и его целесообразное использование помогут расти бизнесу быстрее и добывать новые достоверные знания.
dou.ua
А/Б-тесты являются одним из основных инструментов проверки продуктовых и маркетинговых гипотез. Свой первый тест я запустил в 2011 году. Тогда мы поспорили с моим руководителем, чья идея лучше и принесет больше денег бизнесу. Во многих компаниях тесты являются обязательным этапом внедрения любого изменения в продукт. Это позволяет компаниям оставлять в продукте только то, что действительно полезно для пользователей, партнеров и бизнеса.
Опасные гиппопотамы
А/Б-тестирование всегда начинается с идеи, что тестировать. Идея становится гипотезой, гипотеза — реализацией и тестом. Качество и основа гипотезы во многом определяют успех эксперимента. В свою очередь то, как команда решает, что тестировать, определяет успех всего подхода.HiPPO — это английская аббревиатура, которая означает «Мнение самого высокооплачиваемого человека» (Highest Paid Person’s Opinion). По сути, приходит начальник и говорит, что лучше знает, что надо делать, и вся команда просто должна следовать плану.
HiPPO как метод принятия решения обычно противопоставляется подходу, основанному на данных. Все смотрят на начальника, старшего, лидера. Проблема в том, что каждый человек в разной степени предвзят. Это несомненно мешает принимать верные решения в длительной перспективе.
В реальной жизни это выглядит примерно так. Приходит руководитель и говорит, что его сосед по дачному участку смотрел сайт или использовал продукт и дал несколько дельных советов. Нам обязательно надо все внедрить, но через А/Б-тест. Гипотезы не имеют под собой реальных оснований, хотя идеи звучат великолепно. Да, идея и гипотеза — это не одно и тоже, но об этом в другой раз. Сосед не является представителем целевой аудитории. Эксперимент проигрывает.
Так происходит несколько раз. Эксперименты не выигрывают, тратятся ресурсы, время уходит, ничего не работает. Под удар попадает сама идея экспериментов. Тесты не работают, все это сказки. Компания отказывается от инструмента тестирования и продолжает вслепую внедрять идеи руководителя.
Лучше всего работает независимая методика, алгоритм приоритизации гипотез. Одной из самых распространенных на сегодня является методика RICE. Гипотеза новичка рассматривается и оценивается наравне с гипотезой опытного сотрудника или гендиректора. Никто не может быть более правым, чем фактические данные.
Несколько лет назад у меня был случай, когда junior соседней команды подошел с просьбой дать ему какой-то простой А/Б-тест, чтобы он попробовал его запустить самостоятельно. Мне это ничего не стоило, и я просто вытащил самую технически легкую гипотезу из бэклока. Руководитель узнал об этом, когда разработчик все уже сделал и был готов запускать. Гипотеза руководителю совсем не нравилась, но я все же запустил эксперимент на свой страх и риск. Мне очень-очень повезло, что через месяц тест выиграл. С тех пор руководитель только предлагал свои гипотезы и просил объяснять принципы приоритезации, но никогда больше не блокировал наши тесты.
Копирование кейсов других компаний
В заимствовании, адаптации и даже слепом копировании кейсов и идей других компаний нет ничего плохого. Логика таких решений простая: сработало у них, сработает и у нас, сработало один раз, может сработать и второй. К сожалению, это может как ускорить вас, так и замедлить, и сбить с верного пути.В начале пути обычно именно HiPPO приносят идеи извне. Он прочитал, услышал на конференции, узнал от коллег по рынку новый кейс. Презентация кейса была очень вдохновляющей, сама идея выглядела настолько простой и изящной, что становится непонятно, как же сами до этого не додумались. Нет никаких сомнений, что сработает и у вас.
Дело в том, что решение сработает только, если у вас есть такая же проблема. А это уже не факт. Это как в очереди к врачу обсудить свои симптомы и начать принимать лекарства соседа, но к врачу так и не зайти. Разумеется, что лекарство от того, чего у вас нет, не сработает. Так же и с внедрением чужих решений. В результате, как и с прошлой проблемой, во всем виноваты тесты и зачем вообще их делать, без тестов же все было замечательно.
Решить это поможет наличие списка проблем ваших клиентов, пользователей, посетителей. С актуальным списком проблем вы всегда можете проверить, подходит ли решение для чего-то из списка. Не стоит чинить то, что не сломано.
Года четыре назад я работал в автомобильной тематике, что-то вроде маркетплейса авто. Ко мне временами прилетали идеи, взятые с сайтов автосалонов. Когда у меня не получалось отбиться, мы вынуждены были тестировать эти идеи. Ничего не выстрелило. Люди на интервью так и говорили: «если бы мне надо было это, я бы пошел в салон». Получается, мы тратили время и ресурсы, тестируя подобные вещи.
Досрочное завершение теста
В основе контролируемых экспериментов лежит математика.Представьте, что вы подбрасываете монетку десять раз. 5 раз выпадает орел, и 5 раз — решка. Потом вы сделали изменение, подпилили монетку напильником слегка. Бросаете еще 10 раз. Орел выпадает 6 раз, что скажете? Такое случается? Сколько раз должен выпасть орел, чтобы вы были уверены, что с монеткой стало что-то не так, и орел выпадает чаще?
В разных тестах и при разных условиях используются разные математические методы. Но цель всегда одна — понять, действительно ли результаты эксперимента (орел выпал чаще) вызваны нашими изменениями (мы подпилили монетку).
Досрочное завершение теста — это когда вы бросаете монетку три раза из 10, и неожиданным образом все три раза выпадает орел. «Ну вот оно! Работает! Теперь монетка волшебная, всегда выпадает орел». После этого вы решаете, что делать оставшиеся семь бросков смысла уже не имеет, и так уже все понятно.
В бизнеса желание завершить эксперимент раньше очень усугубляется слепым желанием заработать или избежать потерь. Если видят, что несколько дней положительная динамика, и что каждый день приносит +10% денег, то зачем же продолжать получать +10% только с половины трафика, а не со всего? Аналогично с потерями, каждый день терять 10% очень больно.
Посмотрите на скриншот. Вариант 1 приносит здесь и сейчас на 20.6% больше. Вероятность победы 89%. Сколько вы хотите еще ждать и терять деньги?
Такое поведение очень опасно и приводит к внедрению случайных изменений. С одной стороны, это просто трата ресурсов и драгоценного времени на то, что не работает. С другой стороны, внедряются изменения, которые наносят вред бизнесу.
Вы справедливо можете заметить, что если это приводит к внедрению случайных изменений, то внедряются и изменения, которые улучшают бизнес. Вы правы. Но положительные изменения менее вероятны, чем негативные. Представьте себе весь перечень лекарств. Какова вероятность, что, выбирая лекарства наугад, вы вылечитесь, а не наоборот? И помните, что эффект от всех лекарств накапливается.
Решение здесь одно. Всегда ждите завершения теста. Если ваш инструмент не дает однозначной оценки победы, попросите помощи у аналитиков.
Одна из самых поучительных историй произошла осенью 2012 года. Мы очень быстро начали внедрять А/Б-тестирование и запускали несколько тестов в неделю. У всех была эйфория, и все смотрели на результаты по несколько раз в день. Если положительный тренд держался несколько дней, то ура-ура, принимали решение оставлять на сайте.
К ноябрю, спустя месяца два, у нас было очень много нового на сайте. Но в один день продажи просто упали. Мы почти трое суток ночевали на работе, закопавшись в аналитику. В конечном итоге мы пришли к выводу, что каждый такой тест менял поведение людей не в лучшую сторону, но так как мы не ждали завершения теста, то узнать о реальном влиянии на бизнес не могли.
Мы приняли решения откатить все изменения за последние два месяца. Через сутки продажи вернулись на прежний уровень, а мы научились ждать завершения тестов.
Знать результат заранее
В А/Б-тестировании возможны три варианта результата:- Изменения приносят пользу.
- Изменения вредят.
- Результаты неоднозначны.
Когда вы собираетесь в магазин, то хотите тем или иным образом убедиться, что у вас хватит денег на все покупки, которые собираетесь сделать. Аналогичным образом следует поступать и с экспериментами.
До того, как будет решено начать разработку, необходимо рассчитать минимальный обнаруживаемый эффект (MDE — Minimum Detectable Effect). Например, расчет MDE может показать, что любой рост менее 42% не будет значимым. Здесь стоит спросить себя, а верим ли мы, что новый цвет кнопки поможет поднять продажи на 42%?
По сути, ошибка здесь — это запуск тестов, которые скорее всего не смогут достичь значимых результатов. Это само по себе трата времени и ресурсов.
Расчет MDE является неотъемлемой частью составления дизайна самого эксперимента, где необходимо определить, кто войдет в тест, где будет происходить разделение аудитории на группы и т.д.
В моей сегодняшней практике MDE отсеивает примерно треть гипотез. Давайте приведу пример. Я очень люблю социальное доказательство и все, что с ним связано. Вот пример одного теста с нашего сайта.
Изначально, мы планировали выводить количество забронированных уроков за последний час. Очевидно, что общее количество репетиторов, у которых забронировали уроки за последний час намного меньше, чем тех, у кого бронировали уроки за последние 12, 24 или 48 часов.
Посчитав MDE для всех случаев, стало очевидно, что 48 часов — это идеальный вариант: много репетиторов, привлекательное количество забронированных уроков, достаточный трафик и конверсия. Если бы мы запустили, как изначально планировали, то не было бы даже шанса получить какой-то результат.
Продолжать нельзя сдаться
Все описанные ошибки обычно приводят к тому, что никакого положительного эффекта от А/Б-тестирования нет. После несколько таких ошибок компании сдаются и отказываются от экспериментов как инструмента. Это сравнимо с походом в горы, где в какой-то момент вас не устраивает, как и куда вы идете, и вы решаете выбросить компас. На самом деле компас ни при чем, просто им надо научиться пользоваться.А/Б-тесты — хороший инструмент в умелых руках. Как и любой инструмент, эксперименты идеально подходят для одних задач и совершенно бесполезны для других. Уверенное владение таким инструментом и его целесообразное использование помогут расти бизнесу быстрее и добывать новые достоверные знания.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua