Персонализация в цифрах для B2C рынка (часть 2/3) #presonalization
71% потребителей чувствуют разочарование от одинакового подхода ко всем.
Отсутствие персонализации, конечно разочаровывает. С другой стороны, думаю, что это не влияет на покупки, пока конкурент не начал делать эту саму персонализацию. Просто все знают, что это делать можно и грустно, когда этого не делают, но товары всё ещё нужно где-то покупать. В продвинутом мире есть Amazon, который всем этим обладает, что наверное держит в тонусе всех остальных.
63% потребителей перестают покупать у компаний, которые делают очень слабую (плохую?) персонализацию.
Опять же, чтобы перестать где-то покупать, надо начать покупать в другом месте. Как и прежде утверждение, что надо бежать не быстрее медведя, а всего лишь быстрее конкурента - верное.
72% потребителей взаимодействуют только с теми маркетинговыми сообщениями, которые соответствуют их текущим интересам.
Вообще ничего удивительного в сегодняшнем перегрузе информацией. Если раньше не очень было понятно чем занять время, то теперь совершенно не ясно где его взять.
71% потребителей чувствуют разочарование от одинакового подхода ко всем.
Отсутствие персонализации, конечно разочаровывает. С другой стороны, думаю, что это не влияет на покупки, пока конкурент не начал делать эту саму персонализацию. Просто все знают, что это делать можно и грустно, когда этого не делают, но товары всё ещё нужно где-то покупать. В продвинутом мире есть Amazon, который всем этим обладает, что наверное держит в тонусе всех остальных.
63% потребителей перестают покупать у компаний, которые делают очень слабую (плохую?) персонализацию.
Опять же, чтобы перестать где-то покупать, надо начать покупать в другом месте. Как и прежде утверждение, что надо бежать не быстрее медведя, а всего лишь быстрее конкурента - верное.
72% потребителей взаимодействуют только с теми маркетинговыми сообщениями, которые соответствуют их текущим интересам.
Вообще ничего удивительного в сегодняшнем перегрузе информацией. Если раньше не очень было понятно чем занять время, то теперь совершенно не ясно где его взять.
Персонализация в цифрах для B2C рынка (часть 3/3) #presonalization
Персонализация может снизить CAC до 50%, поднять доход на 5-15% и увеличить эффективность маркетинговых бюджетов на 10-30%.
Похоже на сказку. С другой стороны подозреваю, что здесь всё так же как и с конверсией:
- если было очень плохо, то получим очень хорошие результаты;
- если было нормально, то результаты будут средненькими;
- если и так было хорошо, то результаты будут минимальны, если вообще будут.
Если результаты минимальны, то зачем этим заниматься? Опять же как в старой басне: не важно ты лев или антилопа, но если ты проснулся, то для выживания тебе надо бежать.
Больше цифр и источники по ссылке внизу.
Персонализация может снизить CAC до 50%, поднять доход на 5-15% и увеличить эффективность маркетинговых бюджетов на 10-30%.
Похоже на сказку. С другой стороны подозреваю, что здесь всё так же как и с конверсией:
- если было очень плохо, то получим очень хорошие результаты;
- если было нормально, то результаты будут средненькими;
- если и так было хорошо, то результаты будут минимальны, если вообще будут.
Если результаты минимальны, то зачем этим заниматься? Опять же как в старой басне: не важно ты лев или антилопа, но если ты проснулся, то для выживания тебе надо бежать.
Больше цифр и источники по ссылке внизу.
Первый плюс от CJM
CJM (Customer Journey Map, #CJM) представляет собой набор всех точек касаний компании с клиентом и может быть расширена вообще до всех точек касаний клиента с нашей темой. К тому же точки касаний содержат описание действий, которые делает клиент и/или компания.
Так вот, как минимум создание этого пути легко может показать, что мы что-то такое делаем на "дальних" этапах, о чём клиенты и не догадываются при выборе компании.
Отследить это можно по оценке эмпатии. Если точка имеет хорошую оценку с точки зрения эмпатии, то постарайтесь описать действия в этой точке или результат, который получает клиент в этой точке, как преимущество и обязательно в тест.
CJM (Customer Journey Map, #CJM) представляет собой набор всех точек касаний компании с клиентом и может быть расширена вообще до всех точек касаний клиента с нашей темой. К тому же точки касаний содержат описание действий, которые делает клиент и/или компания.
Так вот, как минимум создание этого пути легко может показать, что мы что-то такое делаем на "дальних" этапах, о чём клиенты и не догадываются при выборе компании.
Отследить это можно по оценке эмпатии. Если точка имеет хорошую оценку с точки зрения эмпатии, то постарайтесь описать действия в этой точке или результат, который получает клиент в этой точке, как преимущество и обязательно в тест.
А/Б тест НЕ решат вопрос сезонности #abtest
Сезонность - это когда спрос на товар/услугу меняется согласно внешним факторам и обычно имеет годовую цикличность.
Во время сезонности, как правило, меняются критерии выбора и/или важность критериев выбора.
Пример №1. В середине ноября, я готов купить подарок на НГ для дочери в США, т.к. я понимаю, что пересылка подарка в Киев замёт +/- месяц. Купить подарок в США во второй половине декабря, я категорически не согласен. Даже если на сайте будет написано, что доставка успеет. Ну не буду я рисковать! Как видим, важность критерия "скорость доставки" сильно возросла.
Пример №2. Тёплое лето... И вдруг жара налетела. Ну как у нас принято, летом никто не ждёт жары, а зимой снег выпадает внезапно. Так вот, жара пришла, спрос на кондиционеры резко вырос. Вам жутко дискомфортно. Если у вас что-то с сердцем или рядом, то дискомфорт становится опасным для здоровья и, возможно, жизни. Цены давно взлетели, люди всё равно покупают. Как видим, важность критерия "цена" падает.
Вывод, который очевиден, но почему-то не всем понятен
А/Б тест ВСЕГДА покажет лучшее решение для текущей ситуации. То есть, для новых критериев и для новой важности критериев. Когда сезон закончится и вернётся «обыденность», то вообще не понятно решение работает или нет. Вполне вероятно, что сделали хуже!
На всякий случай ещё раз: а/б тестирование НЕ решает вопрос сезонности.
Сезонность - это когда спрос на товар/услугу меняется согласно внешним факторам и обычно имеет годовую цикличность.
Во время сезонности, как правило, меняются критерии выбора и/или важность критериев выбора.
Пример №1. В середине ноября, я готов купить подарок на НГ для дочери в США, т.к. я понимаю, что пересылка подарка в Киев замёт +/- месяц. Купить подарок в США во второй половине декабря, я категорически не согласен. Даже если на сайте будет написано, что доставка успеет. Ну не буду я рисковать! Как видим, важность критерия "скорость доставки" сильно возросла.
Пример №2. Тёплое лето... И вдруг жара налетела. Ну как у нас принято, летом никто не ждёт жары, а зимой снег выпадает внезапно. Так вот, жара пришла, спрос на кондиционеры резко вырос. Вам жутко дискомфортно. Если у вас что-то с сердцем или рядом, то дискомфорт становится опасным для здоровья и, возможно, жизни. Цены давно взлетели, люди всё равно покупают. Как видим, важность критерия "цена" падает.
Вывод, который очевиден, но почему-то не всем понятен
А/Б тест ВСЕГДА покажет лучшее решение для текущей ситуации. То есть, для новых критериев и для новой важности критериев. Когда сезон закончится и вернётся «обыденность», то вообще не понятно решение работает или нет. Вполне вероятно, что сделали хуже!
На всякий случай ещё раз: а/б тестирование НЕ решает вопрос сезонности.
Данные всегда однозначны. Выводы всегда не однозначны. (1/3)
Нравится нам это или нет, но люди всегда ищут подтверждение своим идеям, мнениям, гипотезам. Смотря на одни и те же данные, два разных человека с разными взглядами могут видеть доказательства именно своих взглядов.
Нелицеприятный вывод «аналитика что дышло, куда повернёшь... »
Старый анекдот о продавцах
Отправляет обувная компания в Африку продавца разведать рынок. Через время приходит телеграмма «Рынка нет. Все ходят босиком». Спустя год меняется руководство компании и отправляют ещё раз, но уже другого менеджера в Африку с таким же заданием. Через время приходит телеграмма «Рынок безграничен и пуст. Все ходят босиком».
Разберём
«Все ходят босиком» - это данные!
Они не имеют окраски. Просто факт.
Перспективы рынка - это выводы, сделанные двумя разными людьми.
Нравится нам это или нет, но люди всегда ищут подтверждение своим идеям, мнениям, гипотезам. Смотря на одни и те же данные, два разных человека с разными взглядами могут видеть доказательства именно своих взглядов.
Нелицеприятный вывод «аналитика что дышло, куда повернёшь... »
Старый анекдот о продавцах
Отправляет обувная компания в Африку продавца разведать рынок. Через время приходит телеграмма «Рынка нет. Все ходят босиком». Спустя год меняется руководство компании и отправляют ещё раз, но уже другого менеджера в Африку с таким же заданием. Через время приходит телеграмма «Рынок безграничен и пуст. Все ходят босиком».
Разберём
«Все ходят босиком» - это данные!
Они не имеют окраски. Просто факт.
Перспективы рынка - это выводы, сделанные двумя разными людьми.
Данные всегда однозначны. Выводы всегда не однозначны. (2/3)
Есть такое понятие как «полное множество событий». Суть полного множества в том, что сумма вероятностей всех событий полного множества даёт единицу. Более простыми словами: одно из этих событий 100% произойдет.
Пример: полное множество событий подбрасывания монетки не 2 варианта, а 4. Орёл и решка - очевидные варианты. Но есть вероятность, что ребро. Точно нет? А если на пляже на песке бросаем? И последний вариант: монетка может не упасть. Кто-то её схватит и не отдаст. Бред? Это вы с детьми не играли в подбрасывание чего угодно.
Надеюсь пример показательный. Узость нашего мышления, как правило, не позволяет составить полное множество, но стараться надо.
Я уже слышу как кричат «нам главное самые частые события понять, влияние на них приносят результат»… Да, пример с монеткой не показательный для этого аргумента.
Пример 2: есть древня притча о том как слепые мудрецы на ощупь пытались составить портрет слона. В итоге у кого-то слон похож на змею (хобот), у кого-то на столб (нога), у кого-то на верёвку (хвост)...
У Маршака это басня заканчивается ровно так, как она обычно заканчивается в жизни, только вместо рук служебные полномочия и должности:
Возникли распри у слепцов
И длились целый год.
Потом слепцы в конце концов
Пустили руки в ход.
А так как пятый был силен, -
Он всем зажал уста.
И состоит отныне слон
Из одного хвоста!
Как правило мы не знаем не только всех элементов полного множества событий, но и размер самого множества. Простой вывод: не зная размер множества, мы никак не можем определить долю одного события в целом множестве.
Что дальше?
Есть такое понятие как «полное множество событий». Суть полного множества в том, что сумма вероятностей всех событий полного множества даёт единицу. Более простыми словами: одно из этих событий 100% произойдет.
Пример: полное множество событий подбрасывания монетки не 2 варианта, а 4. Орёл и решка - очевидные варианты. Но есть вероятность, что ребро. Точно нет? А если на пляже на песке бросаем? И последний вариант: монетка может не упасть. Кто-то её схватит и не отдаст. Бред? Это вы с детьми не играли в подбрасывание чего угодно.
Надеюсь пример показательный. Узость нашего мышления, как правило, не позволяет составить полное множество, но стараться надо.
Я уже слышу как кричат «нам главное самые частые события понять, влияние на них приносят результат»… Да, пример с монеткой не показательный для этого аргумента.
Пример 2: есть древня притча о том как слепые мудрецы на ощупь пытались составить портрет слона. В итоге у кого-то слон похож на змею (хобот), у кого-то на столб (нога), у кого-то на верёвку (хвост)...
У Маршака это басня заканчивается ровно так, как она обычно заканчивается в жизни, только вместо рук служебные полномочия и должности:
Возникли распри у слепцов
И длились целый год.
Потом слепцы в конце концов
Пустили руки в ход.
А так как пятый был силен, -
Он всем зажал уста.
И состоит отныне слон
Из одного хвоста!
Как правило мы не знаем не только всех элементов полного множества событий, но и размер самого множества. Простой вывод: не зная размер множества, мы никак не можем определить долю одного события в целом множестве.
Что дальше?
Данные всегда однозначны. Выводы всегда не однозначны. (3/3)
Задача ясна: получить полное множество этих самых выводов, мотивов, гипотез. Можно называть как угодно, главное понимать, что результатом этого всего является действие. А именно проверка этих выводов, идей, гипотеза в тестах.
Так вот. Человек, скорее всего, будет делать однозначные выводы, которые будут соответствовать его личному опыту.
Если опыт будет предусматривать более одного варианта, то скорее всего будет выбран самый «близкий» для человека вариант. Редко когда, один человек отдаёт себе отчёт, что бывает очень по разному и мы не знаем как именно.
Неоднозначные выводы скорее будет делать команда, где поощряется «свобода слова».
Если команда очень сработавшаяся и есть идеологический лидер, то скорее всего выводы будут однозначны, т.к. команда находится под влиянием своего лидера.
Для получания множества неоднозначных выводов лучше делать опросы участников теста или сегмента, который исследуем. Эти люди расскажут о своей мотивации и, скорее всего, там будет много очень разных историй.
Таким образом собираем все неоднозначные выводы.
Допустим, получилось собрать неоднозначные выводы, что теперь делать? Тестировать. При чём речь сейчас не только об А/Б тестах, а ещё и о MVP.
Тестируйте решения для пользователей, а не свою карту миру.
Задача ясна: получить полное множество этих самых выводов, мотивов, гипотез. Можно называть как угодно, главное понимать, что результатом этого всего является действие. А именно проверка этих выводов, идей, гипотеза в тестах.
Так вот. Человек, скорее всего, будет делать однозначные выводы, которые будут соответствовать его личному опыту.
Если опыт будет предусматривать более одного варианта, то скорее всего будет выбран самый «близкий» для человека вариант. Редко когда, один человек отдаёт себе отчёт, что бывает очень по разному и мы не знаем как именно.
Неоднозначные выводы скорее будет делать команда, где поощряется «свобода слова».
Если команда очень сработавшаяся и есть идеологический лидер, то скорее всего выводы будут однозначны, т.к. команда находится под влиянием своего лидера.
Для получания множества неоднозначных выводов лучше делать опросы участников теста или сегмента, который исследуем. Эти люди расскажут о своей мотивации и, скорее всего, там будет много очень разных историй.
Таким образом собираем все неоднозначные выводы.
Допустим, получилось собрать неоднозначные выводы, что теперь делать? Тестировать. При чём речь сейчас не только об А/Б тестах, а ещё и о MVP.
Тестируйте решения для пользователей, а не свою карту миру.
Запрашиваю радио молчание
Так уж случается, что гипотеза придуманная утром, скорее всего к вечеру не будет отправлена в А/Б тест. Гипотеза отправится в бэклог, на оценку, на приоритезацию, на проработаку, на чего-то ещё и потом в А/Б тест.
Особенность один. Человеческий мозг странная штука. Когда о чём-то усиленно думаешь, ответ может и не прийти. Стоит переключить внимание на что-то совершенно другое и Эврика!
Особенность два. Так же у людей есть очень характерная черта такая как быть сильными в «заднем уме».
Пример. Вы приняли решение А неделю назад и оно вам казалось самым верным. Через неделю появилась новая информация и вот все вокруг вас осуждают, да и вы сами корите себя за такое решение. Это задний ум.
Эти две особенности приводят к тому, что гипотеза после её начального формирования и вне работы по проработке подвергается изменению.
Я считаю, что это плохо потому что:
- если новые данные (задний ум) противоречат данным в основе гипотезы, то гипотеза должна быть снята вообще или отправлена на проработку повторно. И такое может быть.
- все остальные «улучшения», это уже другие гипотезы.
Подходящий процесс будет таков: написать другую гипотезу, проверить данные, отправить на приоритезацию. И в случае, что новая гипотеза лучше, она будет передана в тестирование раньше. Знания после теста этой новой гипотезы, возможно исключат старую из бэклога навсегда. Но это уже домыслы...
Бюрократия? Возможно…
Вы уверены, что новая гипотеза 100% лучше старой? Зачем вам тогда вообще эти а/б тесты надо.
Так уж случается, что гипотеза придуманная утром, скорее всего к вечеру не будет отправлена в А/Б тест. Гипотеза отправится в бэклог, на оценку, на приоритезацию, на проработаку, на чего-то ещё и потом в А/Б тест.
Особенность один. Человеческий мозг странная штука. Когда о чём-то усиленно думаешь, ответ может и не прийти. Стоит переключить внимание на что-то совершенно другое и Эврика!
Особенность два. Так же у людей есть очень характерная черта такая как быть сильными в «заднем уме».
Пример. Вы приняли решение А неделю назад и оно вам казалось самым верным. Через неделю появилась новая информация и вот все вокруг вас осуждают, да и вы сами корите себя за такое решение. Это задний ум.
Эти две особенности приводят к тому, что гипотеза после её начального формирования и вне работы по проработке подвергается изменению.
Я считаю, что это плохо потому что:
- если новые данные (задний ум) противоречат данным в основе гипотезы, то гипотеза должна быть снята вообще или отправлена на проработку повторно. И такое может быть.
- все остальные «улучшения», это уже другие гипотезы.
Подходящий процесс будет таков: написать другую гипотезу, проверить данные, отправить на приоритезацию. И в случае, что новая гипотеза лучше, она будет передана в тестирование раньше. Знания после теста этой новой гипотезы, возможно исключат старую из бэклога навсегда. Но это уже домыслы...
Бюрократия? Возможно…
Вы уверены, что новая гипотеза 100% лучше старой? Зачем вам тогда вообще эти а/б тесты надо.
Математическое доказательство, почему надо решать проблему клиента
Не секрет, что вопросы определяют направление нашей мысли. Это широко используется в продажах и психологии.
Например, «почему мои гипотезы вечно проигрывают?» и «какие знания я могу получить из этого теста?» — это два принципиально разных вопроса. Они определяют ход мысли и как следствие результат. Это как SQL, только 100500 раз круче. Что спросим, то и получим.
Были на «советских» свадьбах? Ну там где мужчина голова, а женщина шея, куда повернёт, туда голова и смотрит... Вот это всё про одно и тоже.
Какую проблему мы хотим решить нашими гипотезами?
Удивительно, но факт, часть продуктовых менеджеров и маркетологов, говорят, что гипотезы направлены на рост дохода, продаж, новых пользователей и т.д. Грубо говоря, целью любой гипотезы является рост показателей бизнеса. Что в этом ужасного?
Сравните эти два вопроса
«Какую проблему мы решаем?» - это вопрос из предыдущего пункта, и «Чью проблему мы решаем?». Второй вопрос наводит нас (ну меня так точно) на очевидную мысль, что есть проблемы бизнеса и есть проблемы потребителя.
Далее большинство согласится, что «Успешный бизнес решает проблемы (потребности) потребителя». Как-то не комильфо кричать «Да нам пофиг на клиентов, главное чтобы наши показатели росли»...
Собственно математика
Если мы предлагаем гипотезу НЕ на базе проблемы пользователя, то мы угадываем две вещи: проблему пользователя и решение этой проблемы.
Допустим вероятность угадать каждое по отдельности — 50%. Вместе уже 25%. Чувствуете / видите / понимаете как успех отдаляется от нас?
Если гипотеза основана на реальной проблеме, то у нас сильно больше шансов на успех, т.к. угадыванием проблемы мы не занимаемся.
Следствие
Искать проблему надо с помощью классических исследований. Измерять на сколько решение подходит нужно с помощью тестирования.
Не секрет, что вопросы определяют направление нашей мысли. Это широко используется в продажах и психологии.
Например, «почему мои гипотезы вечно проигрывают?» и «какие знания я могу получить из этого теста?» — это два принципиально разных вопроса. Они определяют ход мысли и как следствие результат. Это как SQL, только 100500 раз круче. Что спросим, то и получим.
Были на «советских» свадьбах? Ну там где мужчина голова, а женщина шея, куда повернёт, туда голова и смотрит... Вот это всё про одно и тоже.
Какую проблему мы хотим решить нашими гипотезами?
Удивительно, но факт, часть продуктовых менеджеров и маркетологов, говорят, что гипотезы направлены на рост дохода, продаж, новых пользователей и т.д. Грубо говоря, целью любой гипотезы является рост показателей бизнеса. Что в этом ужасного?
Сравните эти два вопроса
«Какую проблему мы решаем?» - это вопрос из предыдущего пункта, и «Чью проблему мы решаем?». Второй вопрос наводит нас (ну меня так точно) на очевидную мысль, что есть проблемы бизнеса и есть проблемы потребителя.
Далее большинство согласится, что «Успешный бизнес решает проблемы (потребности) потребителя». Как-то не комильфо кричать «Да нам пофиг на клиентов, главное чтобы наши показатели росли»...
Собственно математика
Если мы предлагаем гипотезу НЕ на базе проблемы пользователя, то мы угадываем две вещи: проблему пользователя и решение этой проблемы.
Допустим вероятность угадать каждое по отдельности — 50%. Вместе уже 25%. Чувствуете / видите / понимаете как успех отдаляется от нас?
Если гипотеза основана на реальной проблеме, то у нас сильно больше шансов на успех, т.к. угадыванием проблемы мы не занимаемся.
Следствие
Искать проблему надо с помощью классических исследований. Измерять на сколько решение подходит нужно с помощью тестирования.
Инь и ян А/Б тестирования
Есть две крайности (другие крайности я не встречал, к счастью):
1. Каждая гипотеза должна быть мега-мега обоснована. Это и количественные данные, и качественные исследования, и желательно ещё какой-то пре-тест сделать.
2. Запускаем просто как можно больше тестов, т.к. всё равно никто не знает какая гипотеза выстрелит и пока вы там будете искать обоснования, мы уже с десяток тестов запустим.
Первое очевидно, что истина где-то посередине. Второе очевидно, что середина у каждого своя.
На Reforge вышла прекрасная статья Good Experiment, Bad Experiment, в которой автор Fareed Mosavat в прошлом Dir of Product в Slack рассказывает о своём виденье этой самой середины и границы между хорошими и плохими тестами.
Очень рекомендую прочитать!
Есть две крайности (другие крайности я не встречал, к счастью):
1. Каждая гипотеза должна быть мега-мега обоснована. Это и количественные данные, и качественные исследования, и желательно ещё какой-то пре-тест сделать.
2. Запускаем просто как можно больше тестов, т.к. всё равно никто не знает какая гипотеза выстрелит и пока вы там будете искать обоснования, мы уже с десяток тестов запустим.
Первое очевидно, что истина где-то посередине. Второе очевидно, что середина у каждого своя.
На Reforge вышла прекрасная статья Good Experiment, Bad Experiment, в которой автор Fareed Mosavat в прошлом Dir of Product в Slack рассказывает о своём виденье этой самой середины и границы между хорошими и плохими тестами.
Очень рекомендую прочитать!
Лучший Проверятель Реализации Гипотезы
Считается, что ответственный за всё и вся является Product Manager / CRO Manager / Маркетолог (зависит от типа компании). Этот человек должен следить за качеством реализации гипотезы.
Проблема в том, что функцию выполняет _человек_. А из этого однозначно следует, что этот человек имеет свою субъективную оценку каждого эксперимента «выстрелит» / «не выстрелит». Из этого следует, что отношение к разным экспериментам будет разное.
К экспериментам, в которые верим, будет очень бережное отношение, много внимания деталям и т.д. К экспериментам, в которые не верим, будет более халатное отношение.
Это утрировано, но подсознание работает именно таким образом. Разницу можно увидеть только в сравнении.
Как сделать, чтобы все эксперименты получили максимум внимания?
На самом деле очень просто. Мерилом «клёвости» реализации должен выступать автор гипотезы.
Считается, что ответственный за всё и вся является Product Manager / CRO Manager / Маркетолог (зависит от типа компании). Этот человек должен следить за качеством реализации гипотезы.
Проблема в том, что функцию выполняет _человек_. А из этого однозначно следует, что этот человек имеет свою субъективную оценку каждого эксперимента «выстрелит» / «не выстрелит». Из этого следует, что отношение к разным экспериментам будет разное.
К экспериментам, в которые верим, будет очень бережное отношение, много внимания деталям и т.д. К экспериментам, в которые не верим, будет более халатное отношение.
Это утрировано, но подсознание работает именно таким образом. Разницу можно увидеть только в сравнении.
Как сделать, чтобы все эксперименты получили максимум внимания?
На самом деле очень просто. Мерилом «клёвости» реализации должен выступать автор гипотезы.
О продактах, аналитиках и data-driven подходе в одном диалоге
Аналитик и Продакт:
А: нравится-пилите)
П: нравится
А: так пилите)
П: меня было интересно на сколько реально посчитать это число
А: посчитай-и узнаешь)
А: я не буду
А: мне не нравится прям совсем)
Просто важно помнить, что на сколько бы мы все небыли data-driven, мы остаемся людьми с относительно изученной архитектурой мозга и известными алгоритмами мышления вместе с когнитивными искажениями. Ни больше, ни меньше.
Аналитик и Продакт:
А: нравится-пилите)
П: нравится
А: так пилите)
П: меня было интересно на сколько реально посчитать это число
А: посчитай-и узнаешь)
А: я не буду
А: мне не нравится прям совсем)
Просто важно помнить, что на сколько бы мы все небыли data-driven, мы остаемся людьми с относительно изученной архитектурой мозга и известными алгоритмами мышления вместе с когнитивными искажениями. Ни больше, ни меньше.
Какой framework лучше или больше подходит? #мысли
Во вторник слушал о маркетплейсах и докладчик вспомнил о AARRR. Мне сразу вспомнились старые (обычные воронки), потом вспомнились Growth Loops и конечно же Moments of Truth. Чуть подумав, я решил, что точки контакта и в принципе CJM тоже где-то рядом.
Однажды меня научили интересному упражнению — рефрейминг, что буквально переводится как «изменение рамок».
Суть в том, что всё завязано на восприятии. Например, задача или проблема, или ситуация всегда остаётся неизменной, но меняя своё восприятие, нам кажется, что и что-то изменилось.
Если подходить к AARRR, Growth Loops, MoTs, CJM, etc ровно как разным взглядам на одну и ту же задачу, то вопрос «что лучше» теряет смысл, т.к. каждый новый взгляд может дать новое и возможно лучшее решение.
Во вторник слушал о маркетплейсах и докладчик вспомнил о AARRR. Мне сразу вспомнились старые (обычные воронки), потом вспомнились Growth Loops и конечно же Moments of Truth. Чуть подумав, я решил, что точки контакта и в принципе CJM тоже где-то рядом.
Однажды меня научили интересному упражнению — рефрейминг, что буквально переводится как «изменение рамок».
Суть в том, что всё завязано на восприятии. Например, задача или проблема, или ситуация всегда остаётся неизменной, но меняя своё восприятие, нам кажется, что и что-то изменилось.
Если подходить к AARRR, Growth Loops, MoTs, CJM, etc ровно как разным взглядам на одну и ту же задачу, то вопрос «что лучше» теряет смысл, т.к. каждый новый взгляд может дать новое и возможно лучшее решение.
Волшебные гипотезы и волшебные методы
Когда-то давно-давно, когда я только начинал запускать эксперименты пачками, я охотился на идеи. Я считал, что есть какие-то волшебные гипотезы, которые точно всё решат и эти гипотезы кто-то знает и может поведать.
Опыт говорит о другом:
1. У людей работающих над одним проектом возникают очень похожие идеи. Это становится заметно, если сделать список из 100 идей. На 2-5 идеях, это не заметно.
2. Более интересно и полезно спрашивать не результат (идея / гипотеза), а путь (исследования / аналитика) как этот результат получили. Базовая идея в том, что разные пути дают разные результаты. Если взять на вооружение новый путь (метод исследования), то можно получить новые идеи или новые данные для старых идей.
Вывод: волшебных гипотез не бывает, волшебных методов исследования не бывает, выигрывает тот, кто лучше знает и используют более широкий арсенал методов.
Когда-то давно-давно, когда я только начинал запускать эксперименты пачками, я охотился на идеи. Я считал, что есть какие-то волшебные гипотезы, которые точно всё решат и эти гипотезы кто-то знает и может поведать.
Опыт говорит о другом:
1. У людей работающих над одним проектом возникают очень похожие идеи. Это становится заметно, если сделать список из 100 идей. На 2-5 идеях, это не заметно.
2. Более интересно и полезно спрашивать не результат (идея / гипотеза), а путь (исследования / аналитика) как этот результат получили. Базовая идея в том, что разные пути дают разные результаты. Если взять на вооружение новый путь (метод исследования), то можно получить новые идеи или новые данные для старых идей.
Вывод: волшебных гипотез не бывает, волшебных методов исследования не бывает, выигрывает тот, кто лучше знает и используют более широкий арсенал методов.
Проверка поведения потребителя
Потребитель имеет два ограничения: время для потребления и средства для оплаты потребляемого. Это вроде очевидно.
Пару дней назад осознал, что время и средства должны сходиться к нулю на каком-то промежутке времени.
Практическое использование:
1. берём календарь и/или часы и расписываем день/неделю вашей персоны.
2. берём доход вашей персоны и расписываем бюджет
3. синхронизируем календарь и бюджет.
4. скорее всего в ноль не сойдётся, останется или время, или деньги. А должно сходиться.
Вот собственно становится видно куда можно втиснуть свой продукт.
Потребитель имеет два ограничения: время для потребления и средства для оплаты потребляемого. Это вроде очевидно.
Пару дней назад осознал, что время и средства должны сходиться к нулю на каком-то промежутке времени.
Практическое использование:
1. берём календарь и/или часы и расписываем день/неделю вашей персоны.
2. берём доход вашей персоны и расписываем бюджет
3. синхронизируем календарь и бюджет.
4. скорее всего в ноль не сойдётся, останется или время, или деньги. А должно сходиться.
Вот собственно становится видно куда можно втиснуть свой продукт.
Почему важно проверять А/Б тест руками
Заканчивая статью о чек-листе запуска экспериментов, делюсь отрывком о важности ручного тестирования.
Мы добавили ручное тестирование не сразу, а только после длительного просмотра записей посещений. Оказалось, что делая изменения в одном месте, программисты легко могут что-то сломать в другом не очень очевидном месте. Покрыть весь путь тестами тоже является решением, но...
Как правило тесты пишутся под частые задачи, т.е. это автоматизация. А/Б эксперименты надо запускать быстро и даже ещё быстрее. Так же следует помнить, что количество успешных тестов в среднем от 10% до 30%, потому скорее всего ваша гипотеза проиграет и изменения будут удалены. Автоматизировать то, что скорее всего удалится не очень логично. Потому пункт про тестирование остался и прижился, хотя и претерпел изменения.
Сейчас ручное тестирование это больше о проверке целостного пользовательского опыта. Несколько раз в ходе проверки находили use cases, которые оказывались «поломанными» и приходилось доделывать. Но лучше так, чем перезапуск теста.
Заканчивая статью о чек-листе запуска экспериментов, делюсь отрывком о важности ручного тестирования.
Мы добавили ручное тестирование не сразу, а только после длительного просмотра записей посещений. Оказалось, что делая изменения в одном месте, программисты легко могут что-то сломать в другом не очень очевидном месте. Покрыть весь путь тестами тоже является решением, но...
Как правило тесты пишутся под частые задачи, т.е. это автоматизация. А/Б эксперименты надо запускать быстро и даже ещё быстрее. Так же следует помнить, что количество успешных тестов в среднем от 10% до 30%, потому скорее всего ваша гипотеза проиграет и изменения будут удалены. Автоматизировать то, что скорее всего удалится не очень логично. Потому пункт про тестирование остался и прижился, хотя и претерпел изменения.
Сейчас ручное тестирование это больше о проверке целостного пользовательского опыта. Несколько раз в ходе проверки находили use cases, которые оказывались «поломанными» и приходилось доделывать. Но лучше так, чем перезапуск теста.
Участники экспериментa
Многие часто говорят «пользователь не попал в эксперимент», но на самом деле не отличают «не попал в эксперимент» и «попал в группу А». Дело в том, что и в обоих случаях пользователь не будет видеть изменения сделанные для группы Б.
Смотрите, у нас есть три группы людей:
- Группа А - участники эксперимента, контрольная группа, не видят изменений
- Группа Б - участники эксперимента, экспериментальная группа, видят изменения
- Все остальные - не участники эксперимента, не видят изменений.
Важно отличать участников эксперимента от не участников, потому что сравнивать можно только группу А с группой Б. Сравнивать «тех, кто видел изменения» с «теми, кто не видел» будет большой ошибкой, т.к. «те, кто не видел» могли вообще не соответствовать описанию аудитории, на кого рассчитан эксперимент.
Это удобно объяснять на медицинских примерах:
- Группа А - участники эксперимента, люди больны, НЕ получают тестируемое лекарство..
- Группа Б - участники эксперимента, люди больны, получают тестируемое лекарство.
- Все остальные - случайные посетители больницы, которые не ясно чем больны и больны ли они вообще чем-то. Как и группа А они НЕ получают тестируемое лекарство.
Говорите и думайте правильно - это уменьшает путаницу, улучшает качество рабочей коммуникации, снижает кол-во ошибок.
Многие часто говорят «пользователь не попал в эксперимент», но на самом деле не отличают «не попал в эксперимент» и «попал в группу А». Дело в том, что и в обоих случаях пользователь не будет видеть изменения сделанные для группы Б.
Смотрите, у нас есть три группы людей:
- Группа А - участники эксперимента, контрольная группа, не видят изменений
- Группа Б - участники эксперимента, экспериментальная группа, видят изменения
- Все остальные - не участники эксперимента, не видят изменений.
Важно отличать участников эксперимента от не участников, потому что сравнивать можно только группу А с группой Б. Сравнивать «тех, кто видел изменения» с «теми, кто не видел» будет большой ошибкой, т.к. «те, кто не видел» могли вообще не соответствовать описанию аудитории, на кого рассчитан эксперимент.
Это удобно объяснять на медицинских примерах:
- Группа А - участники эксперимента, люди больны, НЕ получают тестируемое лекарство..
- Группа Б - участники эксперимента, люди больны, получают тестируемое лекарство.
- Все остальные - случайные посетители больницы, которые не ясно чем больны и больны ли они вообще чем-то. Как и группа А они НЕ получают тестируемое лекарство.
Говорите и думайте правильно - это уменьшает путаницу, улучшает качество рабочей коммуникации, снижает кол-во ошибок.
Minimum detectable effect, #MDE
Минимальный обнаруживаемый эффект (Minimum detectable effect, MDE) - это рост конверсии, который можно значимо измерить в результате эксперимента.
Базовая конверсия - текущая конверсия сегмента пользователей, на которых планируется запуск теста. По сути это конверсия будущей группы А.
Рост конверсии - это на сколько мы хотим, думаем, надеемся увеличится конверсия в результате внедрения тестируемых изменений.
Необходимое (имеющееся) кол-во трафика - кол-во участников эксперимента, которое необходимо для достоверного результата.
Так вот эти три числа связаны одной формулой:
- Чем больше базовая конверсия, тем меньше надо трафика, чтобы значимо определить рост.
- Чем больше рост, тем меньше надо трафика, чтобы значимо его определить при той же базовой конверсии.
- Чем больше трафика, тем меньший рост конверсии можно будет определить при
той же базовой конверсии.
Базовую конверсию и имеющийся трафик легко узнать в аналитике. Из этих двух цифр легко можно посчитать минимальный рост конверсии (#MDE), который получится значимо определить.
Перед каждым экспериментом считайте MDE. Бывают случаи, когда MDE = 20%, 50% или даже 300%+. Скорее всего такой рост не получить, а следовательно и эксперимент проводить смысла скорее всего не имеет.
Минимальный обнаруживаемый эффект (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 большой, победить резким движением не получится, будьте осторожны и улучшайте то, что можете.
HiPPO расшифровывается как «highest paid person's opinion» (мнение человека с самой высокой зарплатой). По сути - это мнение начальника.
Опасность в том, что никто заранее не знает какая гипотеза выиграет. «Гиппопотам» тоже не знает, но в силу самой высокой зарплаты и/или должности, его слово имеет больший вес, а иногда вообще может служить распоряжением к исполнению.
Я знаю два способа бороться с HiPPO, если есть осознание проблемы и готовность её решать:
1. Если HiPPO присутствует на совещании, то HiPPO говорит последний, не перебивает и не оценивает мимикой высказывание других.
2. Фреемворк для оценки гипотез учитывает общий голос (среднее или как пожелаете), а голосование происходит анонимно.
Загвоздка в том, что если HiPPO хочет вмешиваться в что тестировать, то помешать будет сложно. Здесь знаю только один способ: HiPPO даётся отдельный голос с большим весом.
Помните, HiPPO большой, победить резким движением не получится, будьте осторожны и улучшайте то, что можете.
Сколько надо трафика для А/Б теста?
Начинающий уровень. Скорее всего у вас очень мало трафика. Сейчас лучше не обращать внимание на предварительный расчет трафика:
- никто не знает на сколько может выиграть тот или иной эксперимент
- у вас даже нет истории экспериментов, чтобы сказать на сколько в среднем у вас эксперименты выигрывают
- вы только начинаете А/Б тесты и это значит, что до этого момента всё делалось на основе чьего-то субъективного мнения, что в свою очередь значит, что конверсию можно увеличивать в разы, так как никто понятия не имеет что работает, а что нет.
Просто начните тестировать и проведите 20, 30, 50 тестов.
Средний/Продвинутый уровень. Этот вопрос не имеет смысла, так как объём трафика зависит от базовой конверсии и роста конверсии. Какой будет рост никто не знает. Потому посчитать сколько нужно трафика никто не может.
Если вы считаете, что можете угадать, то А/Б тесты вам не надо в принципе. Если же вы решили проводить А/Б тесты, то значит вы априори признаете, что не знаете какая гипотеза победит и тем более на сколько.
Более правильный вопрос: какой MDE у нас получается на текущем трафике и текущих метриках за неделю, две недели, четыре недели, шесть и восемь недель? После посмотрите на гипотезу и подумайте, а реально ли эта гипотеза может дать такой рост?
Я понимаю, что никто не знает, но если MDE получится 100% в конечных продажах, то действительно ли вы верите, что данное изменение может удвоить бизнес? Звучит как что-то очень мало вероятное.
Забудьте про трафик, считайте MDE и выбирайте гипотезы для теста с умом.
Начинающий уровень. Скорее всего у вас очень мало трафика. Сейчас лучше не обращать внимание на предварительный расчет трафика:
- никто не знает на сколько может выиграть тот или иной эксперимент
- у вас даже нет истории экспериментов, чтобы сказать на сколько в среднем у вас эксперименты выигрывают
- вы только начинаете А/Б тесты и это значит, что до этого момента всё делалось на основе чьего-то субъективного мнения, что в свою очередь значит, что конверсию можно увеличивать в разы, так как никто понятия не имеет что работает, а что нет.
Просто начните тестировать и проведите 20, 30, 50 тестов.
Средний/Продвинутый уровень. Этот вопрос не имеет смысла, так как объём трафика зависит от базовой конверсии и роста конверсии. Какой будет рост никто не знает. Потому посчитать сколько нужно трафика никто не может.
Если вы считаете, что можете угадать, то А/Б тесты вам не надо в принципе. Если же вы решили проводить А/Б тесты, то значит вы априори признаете, что не знаете какая гипотеза победит и тем более на сколько.
Более правильный вопрос: какой MDE у нас получается на текущем трафике и текущих метриках за неделю, две недели, четыре недели, шесть и восемь недель? После посмотрите на гипотезу и подумайте, а реально ли эта гипотеза может дать такой рост?
Я понимаю, что никто не знает, но если MDE получится 100% в конечных продажах, то действительно ли вы верите, что данное изменение может удвоить бизнес? Звучит как что-то очень мало вероятное.
Забудьте про трафик, считайте MDE и выбирайте гипотезы для теста с умом.