На тему MDE и продолжительности эксперимента в свое время подробно писал Искандер из EXPF - часть 1, часть 2

Статьи с разбором самых распространенных ошибок при проведении AB-тестов. Часть 1. Часть 2

Две статьи Сбера про оффлайн АБ тесты. Акцент сделан на подборе клиентов для групп и оценке их схожести. Статья 1, Статья 2

Новая статья с Gopractice про дизайн AB-тестов. Пошагово разобрана последовательность работы - https://gopractice.ru/data/design-ab-test/

Вы же знаете про "папки", да? Новый виток промоутирования каналов в телеграм, когда делятся сразу пачкой каналов.

Хочу поделиться сокровенным. У меня есть подборка каналов, которые я читаю чтобы понимать как формировать актуальную повестку конференций. Эти каналы очень нишевые, достаточно сложные по контенту, там редко пишут, а порой не пишут вообще. Там есть каналы моих украинских друзей, которые раньше были на русском языке, а сейчас нет. Авторы этих каналов - хеды аналитики, сильные, но непопулярные продакты и просто увлеченные данными люди. Там несколько крутых каналов в которых менее 200 человек)

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

Отдельно скажу, что я не включил в этом список @internetanalytics, потому что здесь я все меньше пишу про аналитику как таковую. Но я добавил в подборку наш чат с вакансиями для аналитиков @analysts_hunter и канал с анонсами конференций @MateMarketing_official.

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

Вот подборка https://news.1rj.ru/str/addlist/idNbBqp9eAphNjUy

Это не рекламный пост. Это просто шорт лист.

Обращусь к админам пабликов. Если вы заметите рост аудитории, буду рад обратной связи и посту с вашей стороны о нашей весенней конференции по продуктовой аналитике aha.matemarketing.ru.... И самое важное. Спасибо вам за классный контент

Вышло продолжение ответов на вопросы по A/B-тестам от Валерия Бабушкина.
- Часть 1
- Часть 2

И список материалов, о которых говорил Валерий.

Еще пара статей про дизайн AB тестов:
- https://habr.com/ru/companies/otus/articles/734768/ - пошаговая инструкция от OTUS
- https://towardsdatascience.com/design-of-experiment-basics-if-you-build-them-they-will-come-cc6a227a0543 - статья Анатолия Зайцева, сооснователя Retentioneering

На AHA приятно наблюдать, что уже на втором докладе по A/B тестам зал переполнен, десятки человек стоят на лестницах, сидят на пуфиках, на полу. И народ ещё подходит.

Был доклад про Вариокуб в главном зале, инструмент для проведения A/B - тестов от Яндекса. Данил Валгушев рассказал про устройство под капотом, тезисно:

- Построен на критерии Манна-Уитни, рассказал, почему выбрали именно его.
- Пользователи делятся не только на группы, но и на более мелкие бакеты, сразу же, но не в момент анализа. Это позволяет делать расчеты быстрее, бакеты нивелируют выбросы и равные значения при ранжировании. Также бакетирование дает возможность сравнивать и средние значения с помощью критерия Манна-Уитни.
- Количество бакетов: от 20 до 100. Необходимые метрики рассчитываются в бакетах, а потом уже бакеты ранжируются и т.д.

Что еще интересно, запускается бета-тест Вариокуба для АппМетрики. Отправить заявку можно на лендинге.

Недавно сильно озадачился проведением AB-тестов, где исследуемая метрика - CTR (количество кликов/на количество показов). Тут проблема в том, что показы клики не являются независимыми наблюдениями, так как один и тот же пользователь может несколько раз увидеть наш рекламный баннер и несколько раз кликнуть.

В это ситуации можно применять t-test с расчетом дисперсии дельта-методом.
Материалы:
- Статья раз
- Статья два
- Статья три

Начал пересматривать доклады по АБ тестам с Aha 23.
Немного про доклад Как в Ozon построили процесс-комбайн АВ-тестирования... Вячеслава Коськина.

В целом, построение некой методологии, системы принятия решений делать / не делать АБ тест, библиотеки кода - это как бы само собой разумеющееся.

А что показалось наиболее интересным - специально выделенные валидаторы, которые одобряют запуск эксперимента и контролируют корректность результатов. И впечатлили цифры - до запуска валидаторы "заворачивают" до 20% экспериментов, и в 10% находят ошибки в расчетах итогов. Эффективность налицо.

Мысленно так прикидываешь результаты своей работы...😰

Продолжаем следить на нашим отечественным Оптимайзом. Собственно, Вариокуб растит функционал платформы и, наверное, перерастет продукт корпорации добра.
Что появилось нового. Теперь можно запускать эксперименты для рекламных блоков РСЯ на сайтах.
Текст новости здесь.

🎣 Что такое z-score и p-value?

Об этом на примере рыбалки (😁) классно рассказывается вот в этой статье, время прочтения ~20 минут

Главный герой, Антон, решил затестить две удочки; на обе он поймал по 300 экземпляров рыб. Кроме того, для каждой рыбы Антон записывал её вес. Теперь он хочет определить, какая из этих удочек эффективнее…

В статье автор:
– Немного рассказывает о нормальном распределении
– Буквально на рыбах , используя SciPy, показывает, как выглядит центральная предельная теорема в действии
– Рассказывает про z-score и p-value и высчитывает их для приведённого выше примера
– Это всё подкрепляется графиками, построенными с помощью seaborn и кодом к ним. Причем код имхо будет понятен даже новичкам)

Ставим огонечек 🔥 на этот пост (давайте наберём 70?) и отправляемся читать статью🙂

Spotify представляет свою систему для проведения АБ-тестов. Это будет коммерческая платформа, которой смогут пользоваться сторонние компании - Confidence.
Текст новости здесь. А сам сервис находится здесь.

Как известно, Google Optimize в ближайшем будущем покинет нас. И достаточно остро сейчас стоит проблема, чем же его заменить.
Наш коллега Александр Игнатенко собрал свой рейтинг аналогичных сервисов, которые могут подойти на эту роль. По особенностям написано не очень много, но есть ссылки на сервисы и каждый сможет по ним перейти, чтобы уже детально ознакомиться с ними.

Собственно, статья

Сегодня, кого не спросишь, все продукты дата-драйвен, проводят 100500 экспериментов в наносекунду. Все красиво звучит на конференциях и пресс-релизах.
Да вот иногда встречается такое, что АБ-тест является не инструментом, который поможет определит истинность наших гипотез (фантазий). А становится просто дополнительным формальным этапом для раскатки новой фичи. Все же проводят эксперименты, вот и мы проводим. Тут имею ввиду скорее не какие-то глобальные изменения в продукте, а про фичи, влияющие на какой-нибудь небольшой функционал.
И, если по недоразумению, наш заветный p-value > 0.05, после некоторых обсуждений фича все равно будет раскатана на всех пользователей, так как "ну мы же уже все сделали, зачем откатываться, и, вообще, я уверен(а), что будет хорошо". А, если решение принимается вопреки результатам и рекомендациям аналитики, зачем мы тратим силы на ненужный по итогу эксперимент?
Потому что ритуал такой!
Что ж я туплю...
Карго-культ?

Когда мы говорим об АБ-тестах, чаще всего речь идет про общую логику, метрики, критерии, продолжительность - т.е. технику, механику.
И редко встречаются публикации и выступления на тему вроде "Как понять, что гипотеза должна проходить через АБ-тест". Знаю, что в крупных компаниях и в зрелых продуктовых командах это вопрос решается через установленную процедуру. Но они редко делятся таким знанием.
А если перевернуть вопрос и поставить его так - "Когда гипотезу не нужно проверять с помощью АБ-теста". Если нормально описать такие случаи, мы сможем себя и окружающих избавить от кучи ненужной работы.

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

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

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

1. Технические фичи не влияют на продуктовые и бизнес-метрики, они обходятся без АБ-теста.
2. Очень мелкие изменения, не влияющие на продукт.
3. Проблема, которую мы хотим решить, незначительная.
4. Изменения редко попадают в поле зрения пользователя, например, на третьем экране или в подвале сайта, из-за этого резко сокращается аудитория.
5. Слабая гипотеза
6. Гипотеза не подходит под критерии хорошей гипотезы (расскажу чуть ниже).
7. Когда ты просто делаешь жизнь пользователя чуть лучше:
- ускорение загрузки страницы
- что-то починили, исправили баг, поправили дизайн
8. Небольшой стартап растет на десятки-сотни процентов и в нем постоянно происходит много изменений.
10. Есть очень сильный продукт (например, главный экран приложения) и небольшие изменения не смогут ухудшить пользовательский опыт.
11. Когда охват фичи минимальный и он не масштабируется.
12. Не нужно тестировать базовый функционал в индустрии, например, в соцсети внедрение комментариев или реакций к постам.
13. На этапе дизайна оказалось, что нам потребуется 1-2-100500 лет, чтобы протестировать гипотезу.
14. Не удается подобрать метрику, которая поможет.
15. Ресурсы, которые нужно потратить на эксперимент, будут больше выгоды, которую ожидаем получить.

Подниму вопрос выбора метрик для A/B-теста. Это один из ключевых этапов подготовки эксперимента. И, подозреваю, что он может быть самым недооцененным. К сожалению, выбору метрик уделяется меньше внимания, чем хотелось бы.

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

Для себя сформулировал набор вопросов, которые помогают понять, правильные ли метрики выбраны. Не идеально, но работает.
1. Какова цель нашего эксперимента?
2. На какую часть пути пользователя на нашем сайте / в приложении мы воздействуем?
3. Что пользователь в этом сценарии делает сейчас?
4. Какое поведение мы ожидаем от пользователя в тестовой группе, внося свои изменения?
5. Что в этом поведении должно измениться, чтобы мы поняли, что наш эксперимент приносит желаемый результат?
6. Можем ли мы какой-то метрикой оценить это изменение? Это и будет главная метрика эксперимента.
7. А можем зафиксировать такое изменение? Если нет, то нужно искать косвенные метрики (возвращаемся назад на пару шагов), которые могут нам помочь понять, что мы добиваемся необходимого результата.
8. Насколько мы предполагаем увеличить (уменьшить) нашу метрику.

В Linkedin у коллеги Романа Смирнова из Ламоды подсмотрел ссылку на его же статью по сравнению методов удаления выбросов при анализе A/B тестов. Тема интересная и чувствительная - случалось, что выбросы разворачивали результаты наоборот. Собственно, статья