Minimum detectable effect, #MDE

Минимальный обнаруживаемый эффект (Minimum detectable effect, MDE) - это рост конверсии, который можно значимо измерить в результате эксперимента.

Базовая конверсия - текущая конверсия сегмента пользователей, на которых планируется запуск теста. По сути это конверсия будущей группы А.
Рост конверсии - это на сколько мы хотим, думаем, надеемся увеличится конверсия в результате внедрения тестируемых изменений.
Необходимое (имеющееся) кол-во трафика - кол-во участников эксперимента, которое необходимо для достоверного результата.

Так вот эти три числа связаны одной формулой:
- Чем больше базовая конверсия, тем меньше надо трафика, чтобы значимо определить рост.
- Чем больше рост, тем меньше надо трафика, чтобы значимо его определить при той же базовой конверсии.
- Чем больше трафика, тем меньший рост конверсии можно будет определить при
той же базовой конверсии.

Базовую конверсию и имеющийся трафик легко узнать в аналитике. Из этих двух цифр легко можно посчитать минимальный рост конверсии (#MDE), который получится значимо определить.

Перед каждым экспериментом считайте MDE. Бывают случаи, когда MDE = 20%, 50% или даже 300%+. Скорее всего такой рост не получить, а следовательно и эксперимент проводить смысла скорее всего не имеет.

Осторожно! Гиппопотам! #HiPPO

HiPPO расшифровывается как «highest paid person's opinion» (мнение человека с самой высокой зарплатой). По сути - это мнение начальника.

Опасность в том, что никто заранее не знает какая гипотеза выиграет. «Гиппопотам» тоже не знает, но в силу самой высокой зарплаты и/или должности, его слово имеет больший вес, а иногда вообще может служить распоряжением к исполнению.

Я знаю два способа бороться с HiPPO, если есть осознание проблемы и готовность её решать:
1. Если HiPPO присутствует на совещании, то HiPPO говорит последний, не перебивает и не оценивает мимикой высказывание других.
2. Фреемворк для оценки гипотез учитывает общий голос (среднее или как пожелаете), а голосование происходит анонимно.

Загвоздка в том, что если HiPPO хочет вмешиваться в что тестировать, то помешать будет сложно. Здесь знаю только один способ: HiPPO даётся отдельный голос с большим весом.

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

Сколько надо трафика для А/Б теста?

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

Просто начните тестировать и проведите 20, 30, 50 тестов.

Средний/Продвинутый уровень. Этот вопрос не имеет смысла, так как объём трафика зависит от базовой конверсии и роста конверсии. Какой будет рост никто не знает. Потому посчитать сколько нужно трафика никто не может.

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

Более правильный вопрос: какой MDE у нас получается на текущем трафике и текущих метриках за неделю, две недели, четыре недели, шесть и восемь недель? После посмотрите на гипотезу и подумайте, а реально ли эта гипотеза может дать такой рост?

Я понимаю, что никто не знает, но если MDE получится 100% в конечных продажах, то действительно ли вы верите, что данное изменение может удвоить бизнес? Звучит как что-то очень мало вероятное.

Забудьте про трафик, считайте MDE и выбирайте гипотезы для теста с умом.

Ценность и польза продукта

Когда-то очень давно я имел удачу погрузиться в инфобизнесовые проекты. Я быстро вышел из этого, но усвоил один очень важный урок: люди в большинстве своём покупают трансформацию. Т.е. кем человек был до и кем он стал после.

Перечитывая свои конспекты книг и лекций, нашёл вот такие 8 вопросов для целевой аудитории:

1. What does your prospect HAVE in the “Before” state?
2. What does your prospect HAVE in the “After” state?

3. How does your prospect FEEL in the “Before” state?
4. How does your prospect FEEL in the “After” state?

5. What is an AVERAGE DAY like for your prospect in the “Before” state?
6. What is an AVERAGE DAY like for your prospect in the “After” state?

7. What is your prospect’s STATUS in the “Before” state?
8. What is your prospect’s STATUS in the “After” state?

Огромная полезность вопросов в том, что люди будут говорить о том, что они получили в результате использования вашего продукта. Говорят же обычно о самом важном и/или болезненном. Это можно и нужно использовать в разработке продуктовых гипотез, а как следствие и а/б тестов.

Поговорите с пользователями

Однажды один опытный product owner сказал мне: «не надо делать прям исследование, просто поговори с 3 пользователями и этого будет достаточно».

Важный момент в том, что нет необходимости понимать какая часть аудитории отреагирует хорошо или плохо. Именно это и покажет А/Б тест. Важно понять, что подобный use case присутствует и ваше изменение (гипотеза) хорошо вписывается в этот use case.

А может надо понимать какая часть аудитории отреагирует хорошо или плохо?

Вчера написал «аудитории отреагирует хорошо или плохо». Так-то оно так, но не совсем...

Однажды я делал аудит интернет-магазина с ужасной страницей оформления заказа. На одной странице была и форма входа для клиентов, и форма быстрого заказа, и форма полного заказа, и возможность редактировать сам заказ.

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

Так как это был аудит под заказ, то каждую гипотезу я старался подкреплять данными. Я проверил в Google Analytics процент «брошенных корзин». Оказалось, что только около 10-15% бросают оформление заказа.

Как потом выяснилось, это было связано с уникальностью товара. В каком-то смысле это была монополия на определённый бренд. Очевидно, что оптимизация этой страницы потеряла всякий смысл и ценность.

Получается, некоторые гипотезы могут вообще не пройти проверку. Это очень хорошо работает, когда люди на интервью / usability тестах говорят об одном, но не демонстрируют это поведение (аналитика кликов / последовательностей просмотра страниц) на сайте.

Важно отметить, что не все гипотезы так можно проверить, но те, что можно, должны быть проверены обязательно.

Потребности пользователей

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

Пользователи не всегда могут объяснить чего им надо. Так же пользователи не всегда осознают, что им именно надо (потребности), а что хотелось бы (фичи).

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

Один из вариантов обойти это на интервью - это всегда спрашивать зачем вам надо то, что вы утверждаете вам надо.

Привет!
Скоро будет "Usability party" 🙂 Plerdy организует 10.12.2020 бесплатную онлайн конференцию о UX & CRO сайтов. Среди спикеров:
- Oleg Slyusarchuk - Head of Product Design Eleks
- Влад Сиднев - Руководитель отдела CRO Web-promo
- Denis Studennikov - Head of UX/UI Department Турум-бурум
- Igor Sokolov - Co-founder ConversionrateStore
- Андрей Чорный - CEO Plerdy
... и я тоже расскажу полезность.

Конечно ссылка на конференцию https://www.plerdy.com/ru/usability-party/ и также есть UX-игра 🙂 Можно пощупать, что такое плохое юзабилити :) https://www.plerdy.com/ru/start-ux-game/

«Корректных А/Б тестов нет, есть недоанализированные»

А/Б тестирование на малом трафике

1. Математика не особо различает мало у вас трафика или много. Если стат. значимость достигнута, то для данного эффекта трафика достаточно.

2. Это приводит нас к утверждению, что тестировать можно на любом трафике, но гипотезы должны быть разные. Чем меньше трафика, тем более значимые изменения можно измерить, тем более "крутые" гипотезы должны быть.

Что реально делать, если трафика мало?

Ситуация А. Вы никогда ранее не занимались улучшением сайта

1. Имеет смысл заказать какой-то стандартный аудит на основе "лучших практик", а потом протестировать рекомендации крупными кусками. Если сайт не оптимизировали до этого, то должно помочь.

2. Второй вариант. Заняться этим самому или поручить продакту / маркетологу. 100% времени это не займёт, но станет хорошим начинанием, которое вырастет во что-то значимое.

Ситуация Б. Вы уже занимались улучшениями сайта

1. Нет смысла нанимать подрядчика или специалиста. Основные ошибки уже исправлены. Нетривиальные вещи подрядчики скорее не найдут, а на 100% заниматься проектом кроме вас никто не будет.

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

Сколько стоит А/Б тестирование?

Ставлю на то, что вы подумали о команде, зарплатах, платных инструментах и, возможно, о бонусах клиентам за участие в опросах. Но... есть и тёмная сторона Луны.

Тёмная сторона Луны
- 10% успешных А/Б тестов считается ОК по отрасли
- Значит 90% будут «негативны» или «не положительны»
- «Не положительны» - не хватило трафика измерить рост или падение
- Значит, что какая-то часть «никаких» тестов отрицательна, но падение не достаточно сильное, чтобы на нашем трафике это измерить

Это всё значит, что запустив 100 тестов, часть из них навредят бизнесу. Да, мы не будем их оставлять на сайте и убьём по завершении теста... Но...

Но! Пока тесты бегут, 50% трафика подвергается негативному влиянию и снижает показатели бизнеса.

p.s. для самых отчаянных есть задача со звёздочкой: умножьте это влияние на LTV.

Разработка продуктов не происходит в вакууме. Чтобы создать крутой продукт, который будет приносить пользу и клиенту, и бизнесу, нужно использовать комплексный подход. Поэтому строить ожидаемый User Experience надо с учетом трендов в индустрии, цифровых инструментов и хорошей UX-экспертизы.

На канале UXSSR можно подсмотреть как делают UX на нашем и зарубежных рынках, какие тренды стоит использовать, и где их искать, а также как достичь высшего уровня цифровизации бизнеса.

Из полезного и интересного:
1. Дайджесты по бизнес-экосистемам: FinTech, логистика, ритейл, e-commerce.
2. Тренды в ритейле – дарксторы, роботизированные магазины и другое.
3. 5 уровней цифровизации на примере Х5 Retail Group – насколько цифровизирован русский бизнес и куда нам стремиться.
4. Запланированное устаревание вещей – почему вечную лампочку так и не изобрели.
5. Запрет на дарк паттерны – что такое дарк паттерны и почему их запрещают.
6. Разборы российских и иностранных экосистем – Сбер, Airbnb, Amazon… you name it.

Рекомендуем подписаться!
#реклама

Ваше безумие или «сколько надо трафика, чтобы провести А/Б тест?»

Все задаются этим вопросом и в сети есть куча калькуляторов, которые с радостью посчитают для вас тот самый объём трафика, только всё это... эм... иллюзия контроля.

Для расчёта объёма трафика необходимо задать два значения:
1. Базовая конверсия (это то, что у вас есть сейчас) aka baseline.
2. Рост, который вы хотите измерить aka minimum detectable effect. (MDE)

Первое вы можете посмотреть у себя в аналитике. Второе вы посмотреть не можете.

Что же вы можете? Это зависит от уровня вашей осознанности: от спрогнозировать (для любителей контроля и заблуждений) до угадать (для любителей безжалостной реальности).

Если один из двух параметров для расчёта нужного объёма трафика является просто напросто догадкой, то и результат будет уровня догадки.

Что реально делать? Считать трафик не нужно, вы его и так знаете. Формулу надо вывернуть на изнанку и просто посчитать MDE.

MDE может получится 2%, может получится 10%, или даже 50%, а то и 150%... Стоит ли запускать тест, где минимальный рост должен быть 2.5 раза чтобы математика сработала? Вот здесь и проверяется на сколько вы безумны...

Конверсия или продукт?

CRO редко трогают продукт. Часто это только оптимизация UI и уловки аля urgency & social proof. Улучшение продукта может сильно повлиять на привлечение (добавили «тортики без глютена» и привлекли новых клиентов), но CRO не диктует продукту что делать и не строит product road map.

Оптимизация UI и уловки, как правило, не дают огромного роста. Люди всё же покупают продукт, а не это вот всё...

Займитесь упаковкой. Продукт изменить не получается, но как его заворачивать, что писать на этикетках и кому это всё продавать зависит от CRO.

Хорошо, не получилось добавить в тортики глютен, но:
- давайте продавать не торты по 0.5 кг / 1кг, а нарежем мелкими кусками и назовём это пироженки
- давайте продадим пироженки в кофейни
- давайте нарежем торт в форме сердца, положим в красную короку и напишем «для пар»
- а пироженки нарежем в виде животных и напишем «детские»
- а у нас точно только один вариант торта делается? несколько? о, а давайте бахнем «ассорти»...

Улучшайте продукт, не трогая продукт... А двигать кнопки каждый может...

Как убить время и ресурсы на «fake door» тесты

Fake door тесты - это когда у вас есть здание и один вход в него. Люди очень просят сделать второй вход сбоку, т.к. ближе к метро и парковке. Цена вопроса - перепланировка первого этажа полностью, т.к. с той стороны котельная, кухня, бассейн, и т.д. Дорого и сложно в общем.

Надо быстро проверить на сколько это нужно. Делаем крыльцо и фальшивую дверь, а потом считаем сколько людей пытались через неё войти. Ура!

Фигня, ура... На практике fake door тест - это новая ссылка, кнопка, баннер... Задача посчитать сколько людей кликнули, т.к. после клика ничего не работает.

Почему я уверен, что это фигня?
- вы получили CTR X% - это хорошо или плохо?
- как CTR X% отвечает на вопрос «а покупать будут?»

А самое важное что? Верно - принятие решения: будем продолжать или закроем инициативу? О принятии решений в следующий раз...

Как оценивать «fake door» тесты?

Результатом теста является CTR fake ссылки или кнопки, что мы там разместили. От этого и будем отталкиваться.

Получается наш вопрос «Будем продолжать или закроем инициативу?» Вопрос трансформируется в:
1. «CTR является достаточным, чтобы целевая метрика полноценного теста достигла стат значимости?»
2. «Рост целевого показателя является достаточным, чтобы полноценный тест имел смысл?»

Что делать с вопросами?
1. Первое - это достаточно простая задача аналитику покрутить воронку и посчитать MDE.
2. Второе - это менеджерская задача по оценке стоимости полноценного теста и сравнению с ожидаемой выгодой.

И чуть следующий уровень...
1. По хорошему, MDE надо посчитать даже до fake door теста и даже высчитать минимальный CTR, который надо достичь, и задать себе вопрос «а имеет ли fake door тест смысл?». Очевидно, что зависит от ресурсов. Если много разработчиков и нет аналитика, то проще протестировать...

2. Выгода может быть больше цены тестирования, но сравните ожидаемую выгоду с необходимым ростом, заложенным в ваш бизнес план и спросите себя «а не фигнёй ли мы собираемся заняться?»

​​Лучший пример false-positive и false-negative, что я когда-либо видел :)

Идея vs Гипотеза

Самая частая проблема, которую приходится встречать среди junior/middle специалистов - это непонимание отличия между идеей и гипотезой.

Идея - всё, что вам пришло в голову.
Гипотеза - это предположение, которое может быть доказано или опровергнуто, не противоречит имеющимся фактам и знаниям, опирается на имеющиеся факты и знания.

Пример 🍻
Идея - «А давайте начнём пить пиво уже сейчас?»
Гипотезы - «Если мы сейчас начнём на пиво, то фиг мы запустим этот А/Б тест до 6 вечера»

Пример 2 🍀
Идея - «А давайте все идеи формулировать как гипотезы?»
Гипотезы - «Если мы будем все идеи формулировать как гипотезы, то это значительно улучшит качество запускаемых тестов и рост целевых показателей будет больше»

И шо?
- идеи как правило звучат классно и интригующе, хочется попробовать
- гипотезы звучат более реалистично и приводят к вопросу «а надо ли нам это проверять?»

«Продакт придумывает гипотезы»

Можно заменить продакт на CRO или на маркетолога, это всё не важно. Важно, что ожидаем самые лучшие и мощные гипотезы от одного (единственного) человека.

Это ошибка. И встречаю я её очень часто. Почти все консультации, почти вся помощь в найме, почти все собеседования...

Почему это ошибка?
1. Над продуктом / проектом работает команда. Если только один человек может генерировать самые сильные гипотезы, то вопрос в квалификации продуктового дизайнера, аналитиков и исследователей. Допустим, что тоже крайне странно, разработчики не будут генерировать гипотезы.

2. Если мы ожидаем, что один человек магическим образом «знает», какая гипотеза лучше и надёжнее, то зачем нам А/Б тест? Просто берём и внедряем... Стрёмно, нет? Мне стрёмно :)

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

Это позволяет работать на самым-самым до чего можем дотянуться (собрать). Ну и очевидная выгода, что работает процесс, а не «незаменимый» сотрудник.

В общем всё было известно давно до нас, никаких переизобретений велосипедов: «Одна голова хорошо, а две — лучше!»

Лучший инструмент для А/Б тестов и знание математики

У меня есть два тезиса, за которые меня время от времени пытаются гнобить:
1. Если вы не знаете какой инструмент выбрать, то выбирайте любой. А это скорее всего Google Optimize.
2. Вам не надо знать подкапотную математику А/Б тестирования. Смотрите на сообщения инструмента «Выиграл / Проиграл»

Почему же я так считаю?

1. Если вы не знаете какой инструмент выбрать, то скорее всего у вас нет или очень мало опыта в А/Б тестировании. Чтобы получить тот самый опыт, важно начать как можно быстрее.
2. Если вы не знаете какой инструмент выбрать, то это означает отсутствие требований к инструменту. Были бы реальные требования, простое сравнение функционала быстро бы решило вопрос. А если нет требований, значит подойдёт любое.
3. Знание подкапотной математики помогут, если вы будете писать свой инструмент с нуля. В других случаях - это практически бесполезно: вы не можете изменить алгоритм(ы) Google Optimize и/или других инструментов.

Кажется, что выбирать лучший инструмент и разбираться в подкапотной математике - это очень и очень правильно. Дьявол кроется в определении «правильно». Я настаиваю, что скорость движения (начать раньше) в большинстве случаев важнее. За это время успеете сделать больше и получить результаты лучше, чем тот выигрыш от лучшего инструмента и знаний математики.

Запускайте эксперименты, о победе которых вам будет сообщать бухгалтерия, а не система аналитики.

С вашей гипотезой точно что-то не так

Вспомните последний а/б тест, который вы запускали. Какова была ваша цель? Проверить гипотезу?

То есть вы проверяли, что вариант Б в чём-то (конкретная метрика) лучше варианта А? Угадал?

С точки зрения проверки гипотезы это верно. Но с точки зрения бизнеса это верно лишь частично.

На сколько бизнес должен вырасти? На 5%, 50%, 2х, 5х, 10х?

Получается, что вариант Б не просто должен быть лучше варианта А, а ещё лучше на столько, чтобы обеспечить необходимый рост. Или по крайней мере сделать значимый вклад в такой рост, верно?

С такой формулировкой часть бэклога моментально теряет смысл. Все исследования, которые вы проводите начинают играть другими красками. Да и MDE в 30% уже не выглядит как нечто из области фантастики.