Conversion And Analytics
480 subscribers
3 photos
1 file
20 links
Канал о том как аналитика и работа над конверсией увеличивают вашу или не вашу прибыль. с наилучшими пожеланиями, @gudkovsa
Download Telegram
Математическое доказательство, почему надо решать проблему клиента

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

Например, «почему мои гипотезы вечно проигрывают?» и «какие знания я могу получить из этого теста?» — это два принципиально разных вопроса. Они определяют ход мысли и как следствие результат. Это как SQL, только 100500 раз круче. Что спросим, то и получим.

Были на «советских» свадьбах? Ну там где мужчина голова, а женщина шея, куда повернёт, туда голова и смотрит... Вот это всё про одно и тоже.

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

Сравните эти два вопроса
«Какую проблему мы решаем?» - это вопрос из предыдущего пункта, и «Чью проблему мы решаем?». Второй вопрос наводит нас (ну меня так точно) на очевидную мысль, что есть проблемы бизнеса и есть проблемы потребителя.

Далее большинство согласится, что «Успешный бизнес решает проблемы (потребности) потребителя». Как-то не комильфо кричать «Да нам пофиг на клиентов, главное чтобы наши показатели росли»...

Собственно математика
Если мы предлагаем гипотезу НЕ на базе проблемы пользователя, то мы угадываем две вещи: проблему пользователя и решение этой проблемы.

Допустим вероятность угадать каждое по отдельности — 50%. Вместе уже 25%. Чувствуете / видите / понимаете как успех отдаляется от нас?

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

Следствие
Искать проблему надо с помощью классических исследований. Измерять на сколько решение подходит нужно с помощью тестирования.
Инь и ян А/Б тестирования

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

Первое очевидно, что истина где-то посередине. Второе очевидно, что середина у каждого своя.

На Reforge вышла прекрасная статья Good Experiment, Bad Experiment, в которой автор Fareed Mosavat в прошлом Dir of Product в Slack рассказывает о своём виденье этой самой середины и границы между хорошими и плохими тестами.

Очень рекомендую прочитать!
Лучший Проверятель Реализации Гипотезы

Считается, что ответственный за всё и вся является Product Manager / CRO Manager / Маркетолог (зависит от типа компании). Этот человек должен следить за качеством реализации гипотезы.

Проблема в том, что функцию выполняет _человек_. А из этого однозначно следует, что этот человек имеет свою субъективную оценку каждого эксперимента «выстрелит» / «не выстрелит». Из этого следует, что отношение к разным экспериментам будет разное.

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

Это утрировано, но подсознание работает именно таким образом. Разницу можно увидеть только в сравнении.

Как сделать, чтобы все эксперименты получили максимум внимания?

На самом деле очень просто. Мерилом «клёвости» реализации должен выступать автор гипотезы.
О продактах, аналитиках и data-driven подходе в одном диалоге

Аналитик и Продакт:
А: нравится-пилите)
П: нравится
А: так пилите)
П: меня было интересно на сколько реально посчитать это число
А: посчитай-и узнаешь)
А: я не буду
А: мне не нравится прям совсем)

Просто важно помнить, что на сколько бы мы все небыли data-driven, мы остаемся людьми с относительно изученной архитектурой мозга и известными алгоритмами мышления вместе с когнитивными искажениями. Ни больше, ни меньше.
Какой framework лучше или больше подходит? #мысли

Во вторник слушал о маркетплейсах и докладчик вспомнил о AARRR. Мне сразу вспомнились старые (обычные воронки), потом вспомнились Growth Loops и конечно же Moments of Truth. Чуть подумав, я решил, что точки контакта и в принципе CJM тоже где-то рядом.

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

Суть в том, что всё завязано на восприятии. Например, задача или проблема, или ситуация всегда остаётся неизменной, но меняя своё восприятие, нам кажется, что и что-то изменилось.

Если подходить к AARRR, Growth Loops, MoTs, CJM, etc ровно как разным взглядам на одну и ту же задачу, то вопрос «что лучше» теряет смысл, т.к. каждый новый взгляд может дать новое и возможно лучшее решение.
Волшебные гипотезы и волшебные методы

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

Опыт говорит о другом:

1. У людей работающих над одним проектом возникают очень похожие идеи. Это становится заметно, если сделать список из 100 идей. На 2-5 идеях, это не заметно.

2. Более интересно и полезно спрашивать не результат (идея / гипотеза), а путь (исследования / аналитика) как этот результат получили. Базовая идея в том, что разные пути дают разные результаты. Если взять на вооружение новый путь (метод исследования), то можно получить новые идеи или новые данные для старых идей.

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

Потребитель имеет два ограничения: время для потребления и средства для оплаты потребляемого. Это вроде очевидно.

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

Практическое использование:
1. берём календарь и/или часы и расписываем день/неделю вашей персоны.
2. берём доход вашей персоны и расписываем бюджет
3. синхронизируем календарь и бюджет.
4. скорее всего в ноль не сойдётся, останется или время, или деньги. А должно сходиться.

Вот собственно становится видно куда можно втиснуть свой продукт.
Почему важно проверять А/Б тест руками

Заканчивая статью о чек-листе запуска экспериментов, делюсь отрывком о важности ручного тестирования.

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

Как правило тесты пишутся под частые задачи, т.е. это автоматизация. А/Б эксперименты надо запускать быстро и даже ещё быстрее. Так же следует помнить, что количество успешных тестов в среднем от 10% до 30%, потому скорее всего ваша гипотеза проиграет и изменения будут удалены. Автоматизировать то, что скорее всего удалится не очень логично. Потому пункт про тестирование остался и прижился, хотя и претерпел изменения.

Сейчас ручное тестирование это больше о проверке целостного пользовательского опыта. Несколько раз в ходе проверки находили use cases, которые оказывались «поломанными» и приходилось доделывать. Но лучше так, чем перезапуск теста.
Участники экспериментa

Многие часто говорят «пользователь не попал в эксперимент», но на самом деле не отличают «не попал в эксперимент» и «попал в группу А». Дело в том, что и в обоих случаях пользователь не будет видеть изменения сделанные для группы Б.

Смотрите, у нас есть три группы людей:
- Группа А - участники эксперимента, контрольная группа, не видят изменений
- Группа Б - участники эксперимента, экспериментальная группа, видят изменения
- Все остальные - не участники эксперимента, не видят изменений.

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

Это удобно объяснять на медицинских примерах:
- Группа А - участники эксперимента, люди больны, НЕ получают тестируемое лекарство..
- Группа Б - участники эксперимента, люди больны, получают тестируемое лекарство.
- Все остальные - случайные посетители больницы, которые не ясно чем больны и больны ли они вообще чем-то. Как и группа А они НЕ получают тестируемое лекарство.

Говорите и думайте правильно - это уменьшает путаницу, улучшает качество рабочей коммуникации, снижает кол-во ошибок.
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.

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