AB тесты и все вот про это вот все – Telegram
AB тесты и все вот про это вот все
1.88K subscribers
23 photos
1 video
4 files
249 links
Полезная информация об A/B тестировании. По любым вопросам можно писать - @ealexandr
Download Telegram
Графики, без опечаток
Как устроена экспериментальная платформа у Linkedin?

Оказывается, в тех-блоге Linkedin подробно описано как устроена инфраструктура их АБшницы изнутри. Я думаю какую-то аннотацию писать бессмысленно, просто прочтите заголовки вот этих 3 статей:

- A/B testing at LinkedIn: Assigning variants at scale
- Our evolution towards T-REX: The prehistory of experimentation infrastructure at LinkedIn
- Making the LinkedIn experimentation engine 20x faster
Проведение A/B для оптимизации SEO

Как задизайнить a/b для оптимизации ранжирования в поисковой выдаче (гугла, яндекса, другого поисковика)?

Это довольно таки распространенный вопрос и решение лежит в плоскости создания синтетических контролей. Вариантов здесь целое множество: хочешь бери байевские временные ряды (prophet или causal impact), хочешь что-то более традиционное (arima или, в частности, sarimax), а можно еще Diff-in-Diff.

Синтетические контроли редко используются на практике в силу проблем, связанных с обучением модели и последующей интепретацией. Тем не менее про подход Diff-in-Diff, часто используемый в социологических иссследованиях, вполне развернуто написали Airbnb:

Читать статью на medium
Как-то посмотрел отчет коллег по результатам AB теста. И в нем целевой показатель - конверсия из сессии, в которой был показан вариант эксперимента (тестовый или контрольный) в сессию с заказом. В чем проблема? А в том, что в данном случае измерять в сессиях неправильно. И вот почему.
Одно из важнейших условий проведения AB теста - независимость наблюдений. И у нас, например, перекраска кнопки "В корзину" из красного в синий, это изменение показывается постоянно.
Если пользователь утром зашел на сайт и увидел новую кнопку, мы засчитали сессию с показом. Когда он снова вечером снова зайдет на сайт и снова увидит новую кнопку, снова будет засчитана сессия с показом, итого уже две. В таком случае у нас получились два измерения, и они одно из них зависимо от другого - так как второй сессии могло не быть без первой. То же самое может быть с заказами - может быть много сессий в заказом у одного пользователя.
Таким образом, у нас нарушается обязательное требование о независимости измерений. В данном случае мы должны были считать конверсию из пользователя, увидевшего кнопку, в пользователя, совершившего заказ.
Когда останавливать A/B-тест? Часть 1: MDE

«Сколько ждать?» – самый частый вопрос, который приходится слышать до и во время проведения эксперимента.

Мы написали новую статью (правильнее было бы назвать это руководством) про то, как стоит подходить к решению этой задачи. А именно от чего в первую очередь зависит прогнозируемое время и как это считать + с кодом на питоне.

В первой части рассматривается концепция Fixed time Horizon, которая основана на расчете MDE. Следующая часть выйдет через несколько недель. А может и раньше, следите за обновлениями в этом канале

Читать статью на медиуме
Только сегодня досмотрел митап от EXPF и СберМаркет - https://youtu.be/1blbhx9BYxk.
Для меня самым интересным был доклад Виталия Черемисина про чувствительность метрик. Виталий очень доступно все разжевал и рассказал о том, как оценивать эту самую чувствительность метрик. Ниже небольшой конспект этой части его выступления.

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

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

2. Выбрать несколько значений uplift. Шаг может быть разным, исходя из эмпирического опыта.

3. И по каждому из значений uplift нужно произвести операции:
- В одной из выборок (пусть она будет B) увеличить значение метрики на величину uplift. Это нужно делать не коэффициентом умножить на вреднее, а некоторым пользователям добавить конверсии, каким-то убрать - в результате получится полноценная выборка с дополнительными конверсиями.
- Делать множественные подвыборки (например, 1000) из обеих групп, сравнивать их показатели, рассчитывать pvalue.
- В результате у нас получится 1000 значений pvalue. Считаем, какой в каком проценте из них pvalue был ниже 0,05. Например, их будет 65%. Вот это процент и есть чувствительность нашей метрики при увеличении на некоторую величину.
- Фиксируем данные. И то же самое теперь производим с остальными значениям uplift.

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

Для чего это можно использовать:
1. Чтобы сделать вывод, нужно при проводить эксперимент. Например, выяснится, что, чтобы получить чувствительность 80%, нужно увеличить конверсию на 30%, что считается невозможным при данных изменениях. Значит, на данный момент нужно отказаться от тестирования данной гипотезы.
2. Чтобы приоритизировать гипотезы для проведения экспериментов. Проверив чувствительность многих метрик и предполагая их увеличение на определенный процент, можно понимать, какие гипотезы про какие метрики являются более перспективными с точки зрения возможности увидеть положительный эффект. Становится понятно, с каких метрик и каких гипотез лучше начать тестирование изменений.
Forwarded from Product Analytics
Как увеличить мощность критериев для A/B-тестирования, используя машинное обучение? Дима Лунин, аналитик AvitoTech, подробно рассказал в своей статье, а ещё:
🔹 что такое CUPED-метод и как улучшить CUPED-алгоритм;
🔹 как использовать Uplift-модель в качестве статистического критерия;
🔹 методы и критерии, разработанные и придуманные командой AvitoTech.
Небольшой чек-лист для проведение АБ теста. Полезно им руководствоваться, чтобы не упустить какую-нибудь "мелочь".
https://www.notion.so/AB-dc3c2f5b1c394124ba65ef7f6100bbee
Когда останавливать A/B-тест? Часть 2: Monte Carlo

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

Читать статью на медиуме
Отличная статья по приоритизации гипотез, разбираются несколько фреймворков, их плюсы и минусы: https://cxl.com/blog/better-way-prioritize-ab-tests/.
Собственно, это не только для AB теста полезно, и для любых фич, нововведений, даже если по ним нет возможности провести тест.
Как раскатывать фичи в A/B с помощью подхода CRL

Все мы привыкли, что фазы раскатки фичи в A/B следуют планомерному увеличению траффика по ходу эксперимента (например, с 1% до 100%). В этом подходе мы хотим учесть, что на маленькой доле траффика много не потеряем на случай, если вдруг целевые метрики просели. Если все ок, то выкатываемся на полную. Такой подход понятен, он работает как часы. Однако, в таком подходе все равно всегда есть риск, что плохой эффект заметен будет не сразу, а чуть погодя. В первую очередь это может коснуться метрик лояльности (например, spu – sessions per user)

В Microsoft и других крупных компаниях практикуется альтернативный подход, в котором фазы лишь условно следуют этому правилу. Подход именуем как Controlled Rollout (CRL). Условность в том, что раскатка зависит не от доли траффика, а от аудитории. Пользователей можно поделить на 4 сегмента: Dogfood, Internal, Insiders, Production.

- Dogfood – по сути внутренняя разработка, оунеры фичи и интересанты
- Internal – внутренние сотрудники, которые могут исчисляться сотнями или тысячами в зависимости от размера компании
- Insiders – внешние пользователи/потребители продукта, которые ранее проявляли интерес к новшевствам сервиса и готовые получать их как можно раньше
- Production – все внешние пользователи

Для каждой аудитории выделены свои критерии и чекеры, говорящие об успешной фазе раскатки и не везде нужно ориентироваться на целевые (OEC) метрики, как это принято при поэтапной раскатке, постепенно увеличивая долю траффика. Что это за метрики и как устроена методология – можно почитать в пейпере
Интересно, когда обычный AB тест заменяется "когортным анализом". Мы все знаем, что ничего это не даст, но делаем вид, что экономим время.
Видимо, чтобы получить ответ типа "Лучше бы провели AB тест". Тем временем прошёл месяц.
Друзья, проводите эксперименты
How Airbnb Safeguards Changes in Production
Статья от Airbnb про их процесс выкатки A/B-тестов:

Introduction
По мере того, как Airbnb выросла до компании с более чем 1200 разработчиками, количество платформ и каналов для внесения изменений в наш продукт — и количество ежедневных изменений, которые мы вносим в прод, — также значительно выросло. Перед лицом этого роста нам постоянно необходимо масштабировать возможности обнаруживать ошибки до того, как они попадут в рабочую среду. Однако ошибки неизбежно ускользают от предварительной проверки, поэтому мы также вкладываем значительные ресурсы в механизмы для быстрого обнаружения ошибок, когда они все же попадают в прод. В этом статье мы рассмотрим причины и фундамент системы защиты изменений в рабочей среде, которую мы называем безопасным развертыванием (Safe Deploys). В двух следующих постах будет подробно рассказано о технической архитектуре, о том, как мы применяли ее к традиционным A/B-тестам и развертыванию кода соответственно

https://medium.com/airbnb-engineering/how-airbnb-safeguards-changes-in-production-9fc9024f3446