А/Б-тесты: как работать с типичными ошибками на старте

Меня зовут Сергей Гудков, я 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 года. Мы очень быстро начали внедрять А/Б-тестирование и запускали несколько тестов в неделю. У всех была эйфория, и все смотрели на результаты по несколько раз в день. Если положительный тренд держался несколько дней, то ура-ура, принимали решение оставлять на сайте.

К ноябрю, спустя месяца два, у нас было очень много нового на сайте. Но в один день продажи просто упали. Мы почти трое суток ночевали на работе, закопавшись в аналитику. В конечном итоге мы пришли к выводу, что каждый такой тест менял поведение людей не в лучшую сторону, но так как мы не ждали завершения теста, то узнать о реальном влиянии на бизнес не могли.

Мы приняли решения откатить все изменения за последние два месяца. Через сутки продажи вернулись на прежний уровень, а мы научились ждать завершения тестов.

Знать результат заранее

В А/Б-тестировании возможны три варианта результата:

  1. Изменения приносят пользу.
  2. Изменения вредят.
  3. Результаты неоднозначны.

Что значит неоднозначны? Это когда эксперимент не выиграл и не проиграл. Утверждать, что А и Б равны, является ошибкой. Вы можете бросить монетку всего два раза. Будет ли этого достаточно, чтобы проверить, как сработало подпиливание монетки?

Когда вы собираетесь в магазин, то хотите тем или иным образом убедиться, что у вас хватит денег на все покупки, которые собираетесь сделать. Аналогичным образом следует поступать и с экспериментами.

До того, как будет решено начать разработку, необходимо рассчитать минимальный обнаруживаемый эффект (MDE — Minimum Detectable Effect). Например, расчет MDE может показать, что любой рост менее 42% не будет значимым. Здесь стоит спросить себя, а верим ли мы, что новый цвет кнопки поможет поднять продажи на 42%?

По сути, ошибка здесь — это запуск тестов, которые скорее всего не смогут достичь значимых результатов. Это само по себе трата времени и ресурсов.

Расчет MDE является неотъемлемой частью составления дизайна самого эксперимента, где необходимо определить, кто войдет в тест, где будет происходить разделение аудитории на группы и т.д.

В моей сегодняшней практике MDE отсеивает примерно треть гипотез. Давайте приведу пример. Я очень люблю социальное доказательство и все, что с ним связано. Вот пример одного теста с нашего сайта.

Изначально, мы планировали выводить количество забронированных уроков за последний час. Очевидно, что общее количество репетиторов, у которых забронировали уроки за последний час намного меньше, чем тех, у кого бронировали уроки за последние 12, 24 или 48 часов.

Посчитав MDE для всех случаев, стало очевидно, что 48 часов — это идеальный вариант: много репетиторов, привлекательное количество забронированных уроков, достаточный трафик и конверсия. Если бы мы запустили, как изначально планировали, то не было бы даже шанса получить какой-то результат.

Продолжать нельзя сдаться

Все описанные ошибки обычно приводят к тому, что никакого положительного эффекта от А/Б-тестирования нет. После несколько таких ошибок компании сдаются и отказываются от экспериментов как инструмента. Это сравнимо с походом в горы, где в какой-то момент вас не устраивает, как и куда вы идете, и вы решаете выбросить компас. На самом деле компас ни при чем, просто им надо научиться пользоваться.

А/Б-тесты — хороший инструмент в умелых руках. Как и любой инструмент, эксперименты идеально подходят для одних задач и совершенно бесполезны для других. Уверенное владение таким инструментом и его целесообразное использование помогут расти бизнесу быстрее и добывать новые достоверные знания.

👍НравитсяПонравилось7
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Що б порекомендували почитати по а/б тестам або курси якісь?

Багато чого різного є. На яке питання хотіли б знайти відповідь?

Хоча... є книга яку я рекомендую для оптимізації конверсії більше ніж для А/Б тестування, але там є розділ про тести и дуже гарно показана роль тестів як частини процессу.

«Добавьте в корзину. Ключевые принципы повышения конверсии веб-сайта» (978-5-91657-193-6) Дуже давно не зустрічав книгу в наявності, но бачив в Інтернеті можна скачати.

Наприклад, цікавили більш практичні питання типу як максималізувати кількість а/б тестів, які регулярно ганяються.

Дякую за книжку.

К сожалению пока таких не встречал.

А/Б-тесты — хороший инструмент в умелых руках

В умелых руках и ххх — балалайка. Вот только под понятием «умелые руки» в данном случае преполагается, что есть некий волшебный способ угадать, какая половина результатов полезна, а какая — неверна. С тем же успехом можно считать финансово эффективной рулетку в казино, вам просто нужны «умелые руки», знающие когда и на что поставить.

А правда в том, что А/Б тесты опасны тем же, чем и полезны: они тестируют только один фактор, но не зависимые. И что ещё опаснее, они не тестируют зависимость во времени, когда одно и то же воздействие оказывается одновременно и вредным, и полезным.

Пример: с точки зрения А/Б тестирования, героин — лучшее средство от простуды.

> что есть некий волшебный способ угадать, какая половина результатов полезна, а какая — неверна.
К сожалению, это правда, волшебного способа угадать нет. Потому и приходится тестировать. Если бы, да кабы, да такой волшебный метод существовал, то в А/Б тестировании не было бы никакой необходимости.

> И что ещё опаснее, они не тестируют зависимость во времени, когда одно и то же воздействие оказывается одновременно и вредным, и полезным.
Это зависит исключительно от дизайна самого эксперимента.

> Пример: с точки зрения А/Б тестирования, героин — лучшее средство от простуды.
Да, можно спроектировать тест так, что это окажется правдой. А можно спроектировать иначе. Как ответ зависит от вопроса, так же и результат теста зависит от гипотезы.

Вот и я так говорю, что без метаданных А/Б тестирование опасно. Оно даст результат близкий к просто случайному. С героином всё верно — реально ж помогал, и его допустили в медицину, и всё ещё так делают, правда с его аналогами.

Что вы подразумеваете под метаданными в этом конкретном случае и почему без них тесты дадут результат близкий к случайному?

Что цель эксперимента — поиск источников зависимостей, а не просто удачного варианта. И гипотеза должна быть подкреплена теорией, ну или теоретической гипотезой, иначе просто огромен соблазн и легка возможность отсечь «неправильные» данные.

Пример из давнего прошлого: Приватбанк решил, что ради популяризации банковских карт обслуживать только тех клиентов, у которых есть карта. В том числе юридических лиц. Эксперимент был признан удачным — 70% согласились. А на деле это полная задница: ради непонятной выгоды потерять 30% клиентов на ровном месте.

Я бы не оценивал эксперименты других компаний. Просто потому что мы не знаем целей и условий.

Что цель эксперимента — поиск источников зависимостей, а не просто удачного варианта.

Здесь вы в корне не правы. Цель эксперимента именно в опровержении нулевой гипотезы, т.е. подтверждении, что связь между двумя событиями (изменение в варианте Б и изменение целевой метрики) есть.

И гипотеза должна быть подкреплена теорией

Я бы сказал желательно подкреплена, чем должна. Это поможет увеличить шансы успеха в эксперименте.

Я лишь пример привёл. Я не неправ не «в корне», а лишь с вашей точки зрения. Если ПРОДАВАТЬ услугу тестирования — то да, я не прав, так я слона не продам :)

А вот если извлекать пользу из самого теста, тут уже нужно 99% теории и/или опыта, и 1% практики. И чаще всего в практике нет необходимости.

Что дейстивтельно тяжело в АБ тестах: отслеживаение желательного и нежелательного результата. Он зачастую совсем не мгновенный, чёрта лысого вы дёшево протестируете АБ тестом по всей последовательности AIDA, ибо это потребует с высокой достоверностью отслеживать результат на каждом этапе.

Пример: ОБЕЩАНИЯ. Да, хорошее обещание может вызвать интерес. Но как только выясняется, что наврали с три короба, клиент уходит и больше не вернётся. В то же время, АБ тест показывает резкий рост числа переходов на одном из этапов воронки. И когда нет ни теории ни опыта, крыть такие результаты нечем, они получают время-деньги на своё повторение и развитие.

Я лишь пример привёл. Я не неправ не «в корне», а лишь с вашей точки зрения. Если ПРОДАВАТЬ услугу тестирования — то да, я не прав, так я слона не продам :)

Хорошо. «С моей точки зрения», А/Б тест — это метод статистической проверки, и дальше уже по определению это лишь опровержение нулевой гипотезы. Всё остальное — это как и зачем его использовать.

Абстрактный пример про AIDA звучит хорошо, но не убедительно, потому что вопрос в деталях: цели, ожидания, гипотеза, трафик, метрики, сама воронка и много чего другого.

Лично мне, это звучит как «а вот молоток плох в забивании шурупов...». Ну да, наверное молоток не самый лучший инструмент, да и к задаче «забивание шурупов» есть вопросы...

А/B тестирование допускает, что во время эксперимента состав трафика остается равномерным.

Если августе в интернет-магазине ради теста в меню категорию «детские товары» расположить выше, то это приведет к росту заказов. Но на отрезке это может показать обратный эффект.

Это само собой, А/B тест эффективен только на краткосрочном эксперименте, хотя бы потому что он дорог. Прежде всего дорог в организации, равно как и чреват ошибками сырых версий, от которых не избавиться, каждый новый тест — грабли.

Не веришь — купи что-нить на prom.ua, там вечно какие-нить сюрпризы. За последний год мне пришлось накатать 6 багрепортов. А за все годы до того — ни единого. И это при том что я там не частый гость. Угадай с одного раза, а публичен ли способ подать багрепорт :)

Простите, почему он дорог? Очевидно, что инструмент имеет стоимость, но почему дорог, а не дёшев, или приемлемая цена?

Я правильно прочитал, что баги на Проме за последний год, вы относите на А/Б тесты?

Когда интерфейс меняется до невменяемости каждую неделю, да, я считаю, что надо мной проводят эксперименты. Но запустить эксперимент много ума не надо, а вот чтобы это всё не распадалось как Плутоний 239 — тут уж надо времяденег.

Да, так и есть (скорее всего так и будет). Это решается на уровне гипотез: хотим ли мы тестировать что-то для детей в момент сезона «скоро в школу». Если хотим, то зачем? Какова гипотеза и т.д.

Давайте тільки не «державною», а українською. Бо ДОУ це не державна інституція щоб вимагати використання державної мови. Натомість ми прагнемо розвивати україномовне середовище, правда ж?
Є одне але. Ступінь володіння українською мовою в усіх різна, тому якість текста і, як наслідок, легкість його сприйняття читачами може впасти (це я критично дивлюся на свої спроби писати довгі тексти українською). А редакторів та коректорів на ДОУ немає. Чи готові ми пожертвувати якістю?

Подписаться на комментарии