📌 1. Интро

По результатам опроса, в ближайшие 2 недели мы поговорим про АБ-тесты:

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

⚡️В конце, при желании, порешаем реальный тест.

И в качестве введения в тему, немного теории — что это вообще такое и зачем оно надо ⬇️

Смысл АБ довольно прост: мы делим юзеров на несколько групп (этот процесс называется сплитование), в одной ничего не трогаем — это наш контроль, в других что-то меняем. Сравниваем, и принимаем решение как лучше.

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

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

Доставай тетрадочку, на курсах тебе такого не расскажут 🙂

#ABtest

📌 2. Дизайн теста, ч.1

Тест, по определению, проверяет какую-то идею. По умному эта идея называется гипотезой.

📎Гипотезы могут появляться просто как идеи или их может приносить команда (продакты, проджекты или дизайнеры), но чаще гипотезы вытекают из твоих рисёрчей. Когда ты исследуешь какую-то проблему или анализируешь фичу, хорошим тоном считается в выводах описать идеи по решению проблемы или улучшению фичи. Вот эти идеи — уже гипотезы.

Кстати, генерирование гипотез по итогам рисёрча отличает хорошего аналитика от не. Новички, как правило, вообще не заморачиваются с выводами. Итак таблицы есть — заказчик разберётся (спойлер — не разберётся).

Когда гипотеза ясна, первым шагом в подготовке теста является документирование. В аналитическом сообществе мы называем этот артефакт дизайном теста (ДТ).

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

ДТ все заполняют по разному, кто как. Структура, которую я покажу здесь, моя авторская, я начинал её делать года 4 назад, она постепенно эволюционировала, и вот финальная версия на сегодня. Моим командам нравится, пользуйтесь и в своих 🙂

Эту часть заполняет заказчик гипотезы ⬇️

1️⃣ Гипотеза.
Тут мы описываем суть идеи, что хотим поменять и зачем.

2️⃣ Описание вариантов.
Что меняем в тестовом варианте. Иногда, в зависимости от твоей системы, нужно проставить id вариантов перед стартом, это ты уже потом в доку добавишь.

3️⃣ Чего ожидаем от теста.
Ожидаем больше заказов или хотим увеличить возвращаемость, повысить средний чек и т.д. Эта инфа тебе понадобится чуть дальше, при выборе метрик.

4️⃣ Ограничения.
Если есть, тут стоит указать. Проводим только на определённом гео или платформе и т.д.

#ABtest

📌 2. Дизайн теста, ч.2

Дальше ты берёшь наработки заказчика и напильник, и начинаешь детализировать:

5️⃣ Ключевая метрика / ОЕС.
По началу будет достаточно просто выбрать метрику, на которую тест должен повлиять сильнее всего. Конверсия в регу, в покупку, средний чек, общий доход и т.д. Выбирай вдумчиво, это важный шаг. Со временем, вместо одной ключевой метрики ты придёшь к ОЕС (overall evaluation criterion), это такая штука, которая получается при взвешивании переменных. Об этом потом поговорим, тема немного сложнее чем кажется.

6️⃣ Дополнительные метрики.
Укажи пару-тройку дополнительных метрик, которые тоже нужно мониторить, но они чуть менее важны чем ключевая. Не перебарщивай с набором метрик, бери только важное, иначе утонешь в интерпретации ☝️

7️⃣ Базовое значение ключевой метрики и её вариативность.
Как базу обычно берут среднее, а вариативность это стандартное отклонение. Не бери большой период, 2-4 недели истории будет достаточно. Нужно чтобы значения были свежими.

8️⃣ MDE (minimum detectable effect).
Наши ожидаемые изменения ключевой метрики по итогам теста. Это никак не вычисляется, обычно на опыте просто 🙂
Например, мы хотим провести тест на конверсию, мы верим в гипотезу, она разрывная. Наша конверсия обычно 5%, мы хотим поднять её тестом до 7%. Вот эта разница и есть MDE. Указывать можно как в % так и в п.п. (проц. пунктах). Чем ниже MDE, тем дольше проводить тест, но тем выше вероятность получить стат. значимый результат. Если мы слишком завысим MDE, то тест будет быстрым, но скорее всего, не значимым.

9️⃣ Валидация MDE.
Так как понять какой MDE брать? Обычно эффект никто не валидирует (потому что далеко не во всех компаниях развита культура тестов), но я поклонник метода через сигмы — MDE не должен быть выше 2-3 стандартных отклонений, это снижает реалистичность, MDE ниже одного отклонения, возможно, слишком мал и тест может затянуться. Тут надо балансировать. Вернемся к этому в п.11

1️⃣0️⃣ Рассчитываем выборку.
У нас есть всё что нужно для расчёта размеров теста: базовая метрика и MDE. Ещё в настройках указывают доверительный уровень (0.05), мощность (0.8) и направление (”two.sided”). Обычно их редко меняют без серьезных оснований, чаще ставят дефолтные. В R выборка считается функцией power.prop.test(), в Python statsmodels.NormalIndPower(). В конце поста ссылка на пример.

1️⃣1️⃣ Расчёт сроков теста.
На основании рассчитанных объёмов выборки и средних показателей трафика можно прикинуть сроки проведения теста. Есть нюансы — тест не должен быть короче 1 полной недели, чтобы включить выходные. Если тест слишком долгий, попробуй увеличить MDE.

1️⃣2️⃣ Добавление в трекинг.
Если нужно, можно добавить новые ивенты в разметку, особенно когда тестируем новую фичу. Как минимум нужна индикация, что юзер увидел фичу. Ивенты на новой фиче ещё могут помочь понять воронку и прибавить ещё гипотез, даже если тест не даст положительных результатов. Например, можно будет понять ошибки в дизайне фичи, и перезапустить тест после их исправления.

Вот здесь можно посмотреть пример заполненного дизайна: ПРИМЕР ДИЗАЙНА ТЕСТА

#ABtest

📌 3. Экспресс-курс статистики для АБ

Классическая механика расчёта АБ-тестов основывается на стат. критериях.

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

✅ Распределение — способ описания того, как разбросаны значения в наборе данных. Распределение бывает разных видов, но нас пока интересует только нормальное.

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

✅ Выбросы — это экстремально большие или маленькие значения в наборе данных, которые могут искажать общие результаты. В АБ с выбросами осторожно.

✅ Статистические тесты — не путать с АБ-тестами. Стат. тесты это инструменты, с помощью которых мы проверяем заранее заданные статистические гипотезы. Их много разных. У каждого стат. теста есть нулевая гипотеза, и задача теста её отклонить или не. Т.е. по простому, стат. тесты позволяют нам делать различные проверки наших данных, например, проверку на нормальность распределения, или гомогенность дисперсий.

✅ ЦПТ (Центральная предельная теорема) — фундамент статистики: “при достаточно большом размере выборки, распределение средних значений выборочных данных будет приближаться к нормальному распределению, независимо от формы распределения исходной популяции.”

✅ P-value — главный термин в контексте АБ, это вероятность получить такие же, или ещё более выраженные отличия, при условии, что верна нулевая гипотеза.

✅ Ошибка первого рода — ситуация, когда мы отклоняем нулевую гипотезу, хотя на самом деле она верна. В АБ это значит что мы радуемся победе тестового варианта, но на самом деле он не выиграл.

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

P.S. эту базу, кстати, часто спрашивают на собесах, сохрани и не теряй 🙂

#ABtest #собесы

📌 Созвоны

Пока ты перевариваешь базовую теорию АБ, давай немного отдохнём и обсудим действительно важные вещи 🙂

Вот ты прошёл свои первые собесы, получил оффер и вышел на работу. Сидишь такой с утра, пьёшь кофе и заглядываешь в рабочий календарь…

Созвоны — любимая часть работы 😅.

Их плотность может варьироваться от ежедневных до раза в неделю.

✅ Самый популярный у аналитиков это планинг. Его ставят раз в неделю, в понедельник-вторник, чтобы раскидать задачки на спринт (интервал в 1-2 недели, в который ты планируешь свою работу).

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

В зависимости от структуры, ты планируешься с продактом или в команде аналитики.

✅ Не самый частый у аналитиков — дейли. Короткий созвон, на 15-30 минут, обычно каждый день утром. Задача — свериться с планами и сообщить о каких-то, блокирующих задачу, факторах.

✅ Синхро — не самый популярный созвон, по сути похож на дейли, только подольше и раз в неделю. Они взаимозаменяемые.

✅ Груминг — чистка бэклога (общего списка задач), груминг тоже довольно редкий созвон у аналитиков, но как по мне зря. Иногда очень полезен, т.к. часто бывает что задачи просто зависают — они уже не так нужны как казалось, но смотрят на тебя и бесят.

✅ И мой фаворит — ретро. Это созвон по итогам пары спринтов. Психо-разгрузочный, где команда обсуждает что им понравилось, а что нет. Тут ты можешь ныть сколько угодно, бомбить что бесит отсутствие документации, или что ты ничего не сделал за спринт потому что было лень. Или наоборот порадоваться своей продуктивности или похвастаться новым девайсом. Или успехами в Доте. Или просто постить фотки своего кота.

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

📌 4. T-тест. Проверка дисперсий

С теорией разобрались, едем дальше.

Для расчёта АБ существует много методов. Мы рассмотрим самые популярные, которые чаще других применяются на практике. И начнём, конечно, с T-теста Стьюдента / Уэлча.

‼️ Кстати, тоже частая тема на собесах.

Нулевая гипотеза Т-теста предполагает, что средние значения переменной в выборках равны. Отклонение гипотезы (p-value < 0.05) это наша желаемая цель.

Я часто подхожу к расчётам через T-тест. Он простой и довольно точный. Из минусов — имеет пару ограничений (но и инструменты для их обхода).

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

Для проверки дисперсий обычно используют какой-то из критериев:

✅ Бартлетта. Он чувствителен к нормальности распределения;

✅ Левена. Менее чувствителен к нормальности, самый популярный тест;

✅ Флигнера-Килина. Не чувствителен к отклонениям от нормальности и выбросам, подходит для ненормального распределения;

Нулевые гипотезы всех критериев похожи, они предполагают, что дисперсии в выборках равны. Т.е. нам эту гипотезу отклонять не хочется (цель p-value > 0.05).

Но вне зависимости от результатов, мы можем обойти это ограничение. Оно присутствует у Стьюдента, но его нет у Уэлча. Т.е. технически, нам всё равно какая там дисперсия получится 🙂

В коде далее df — датасет, metric — метрика, столбец который проверяем, var — категория варианта.

Проверка дисперсий в R и Python:

library(car) # библиотека с тестом Левена

bartlett.test(metric ~ var, df) # тест Бартлетта
leveneTest(metric ~ var, df) # тест Левена
fligner.test(metric ~ var, df) # тест Флигнера-Килина

from scipy.stats import bartlett, fligner, levene

# тест Бартлетта
bartlett_result = bartlett(df[df['var'] == 'A']['metric'], df[df['var'] == 'B']['metric']).pvalue

# тест Левена
levene_result = levene(df[df['var'] == 'A']['metric'], df[df['var'] == 'B']['metric']).pvalue

# тест Флигнера-Килина
fligner_result = fligner(df[df['var'] == 'A']['metric'], df[df['var'] == 'B']['metric']).pvalue

#ABtest