📌 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

📌 Подготовка данных к анализу

Этот пост логично бы смотрелся в цикле про АБ перед проверками, но я чёт упустил 🙂 поэтому пусть будет не номерной, а просто как памятка.

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

Этот процесс включает в себя несколько шагов:

1️⃣ Трансформируй типы данных. В первую очередь проверь все ли данные соответствуют своим типам: целочисленные — интеджерам, с плавающей точкой — флоатам, категориальные — факторам, даты — датам.

2️⃣ Преобразуй потери и пропуски. Все NA’s стоит обработать. Тут есть несколько подходов. Если в масштабах датасета их не много, возможно проще их будет удалить. Если удалять не хочется, замени NA’s средними или медианными значениями столбца (этот процесс называется импутацией). С NULL'ами по ситуации, иногда их не надо трогать, иногда можно импутировать.

3️⃣ Почисти выбросы. Чистить выбросы или нет — зависит от данных. Чаще всего чистить придётся, но ориентируйся на цели анализа. Если ты анализируешь деньги, то дважды подумай можешь ли выкидывать экстремально высокие чеки, или это сломает тебе картину. Возможно, лучше будет их импутировать.

Если решишь срезать, то тут есть несколько популярных методов. Я чаще всего срезаю выбросы по порогу 1.5*IQR, но можно использовать и ±2 или ±3 SD, а R вообще умеет идентифицировать выбросы напрямую из боксплота boxplot.stats(df$metric)$out (в Python такого аналога не завезли).

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

📌 5. T-тест. Проверка распределения

Второе ограничение T-теста подразумевает, что выборочные средние должны быть нормально распределены.

Долгое время (да и сейчас не редкость) в интернетах активно форсилась позиция, что T-тест ограничивается нормальным распределением выборки. Это не так. В основе этого ограничения лежит та самая ЦПТ.

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

Функция для генерации средних:

generate_sample_means <- function(data, sample_size, n_samples) {
  sample_means <- numeric(n_samples)
  for (i in 1:n_samples) {
    sample <- sample(data, size = sample_size, replace = TRUE)
    sample_means[i] <- mean(sample)
  }
  return(sample_means)
}

def generate_sample_means(data, sample_size, n_samples):
    sample_means = []
    for _ in range(n_samples):
        sample = np.random.choice(data, size = sample_size, replace = True)
        sample_means.append(np.mean(sample))
    return sample_means

Теперь это распределение можно тестировать. Для этой цели используют два популярных критерия:

✅ Шапиро-Уилка. Проверяет соответствие выборки нормальному распределению.

✅ Колмогорова-Смирнова. Проверяет соответствие выборки заданному распределению, в том числе нормальному.

Тесты:

# тест Шапиро-Уилка
shapiro.test(df)

# тест Колмогорова-Смирнова на нормальность
ks.test(df, "pnorm", mean = mean(df), sd = sd(df))

import numpy as np
from scipy import stats

# тест Шапиро-Уилка
shapiro_test = stats.shapiro(df)

# тест Колмогорова-Смирнова на нормальность
ks_test = stats.kstest(df, 'norm', args=(np.mean(df), np.std(df)))

Но даже если выборочные средние не распределены нормально, мы можем попробовать обойти это ограничение методами выравнивания. Об этом поговорим дальше.

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

#ABtest

📌 6. T-тест. Выравниваем распределение

Иногда выборочные средние могут распределиться не нормально, а нам прям очень надо. Эту проблему можно пофиксить

Чтобы попытаться выровнять распределение, мы можем использовать много методов — от простого логарифмирования и стандартизации, до рангового преобразования и трансформации Йео-Джонсона.

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

☝️ Главный нюанс, который стоит знать про BCT (Box-Cox transformation) — он не работает с отрицательными значениями. В коде последней строкой фикс для таких случаев.

🧐 Суть метода, под капотом, заключается в поиске идеального значения суперпараметра лямбда, который определяет как именно трансформировать данные. Лямбда подставляется в формулу к каждому значению в данных. Если лямбда нулевая, то формула логарифмирует значения, если не нулевая — возводит данные в степень лямбды.

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

Вот так это выглядит в R (версия для Python в комменте):

library(MASS)
library(car)

# Вычисляем лучшее значение лямбды
par(mfrow = c(1, 1))
boxcox_result <- boxcox(df$metric ~ 1, lambda = seq(-3,3,0.1))

# Сохраняем его
best_lambda <- boxcox_result$x[which.max(boxcox_result$y)]

# Применяем преобразование
df$metric_transformed <- car::bcPower(df$metric, best_lambda)

# При наличии отрицательных значений, смещаем нашу метрику на минимальную величину +1
df$metric <- df$metric+ abs(min(df$metric)) + 1

📎 У меня на гитхабе есть демка такого преобразования (R).

#ABtest

Знакомтесь, это Остин и Тимон - мои помощники)

Пятница всё-таки, давайте разбавим ленту своими бандитами ⬇️🙂

📌 8. T-тест. Интерпретация теста

Вдогонку к предыдущему посту, будет не лишним немного рассказать как интерпретировать T-тест.

Пост для любителей разобраться чуть глубже.

Базово его результат выглядит как-то так:

Two Sample t-test

data:  money by var
t = -14.679, df = 998, p-value < 2.2e-16
alternative hypothesis: true difference in means between group A and group B is not equal to 0
95 percent confidence interval:
 -10.869281  -8.305884
sample estimates:
mean in group A mean in group B 
       15.49617        25.08376

🧐 Что тут происходит?

✅ t. Это значение t-критерия, по которому вычисляется p-value. То, что значение отрицательное, означает что среднее группы A меньше среднего B.

✅ df: Степени свободы. Они нужны для расчёта t-критерия.

✅ p-value: Наш ключевой показатель, вероятность получить такую разницу средних, если бы на самом деле различий не было. Или нам можно идти в казино, или выиграла альтернативная гипотеза (средние не равны, варианты различаются).

✅ 95% доверительный интервал: Доверительный интервал для различия средних значений находится между -10.8 и -8.3, со знаком минус. Т.е. с 95% уверенностью можно сказать, что среднее значение группы B выше среднего значения группы A на величину от 8.3 до 10.8.

✅ Оценки выборочных средних: Среднее значение для группы A составляет 15, а для группы B - 25. Та самая средняя дельта.

#ABtest

📌 Как запускают тесты

На прошлой неделе было много технической базы, на этой будет поменьше 🙂

А пока прервёмся на что-то попроще. Давай порассуждаем как вообще происходит запуск теста в команде. Рассмотрим пример компании, где тесты плюс-минус поставлены на поток.

✅ Всё начинается с идеи. Как я уже говорил, идеи приходят от команды или рождаются в процессе исследования продукта и поведения юзеров.

Чтобы идея превратилась в аналитический артефакт, с которым можно работать, её нужно задокументировать. Так она становится гипотезой. Для ведения документации, я обычно создаю отдельную ветку в confluence (скорее всего у тебя в команде он тоже есть).

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

✅ Когда у тебя появляются картинки, ты идёшь в свою сплит-систему и создаёшь тест. В любой системе, кастомной или сторонней, обычно нужно завести ID теста/вариантов и описания вариантов.

✅ После этого нужно поставить задачу на разработку. В задаче нужно оставить ID теста и вариантов, продублировать описание вариантов, приложить картинки. Чем более полно ты опишешь задачу, тем больше вероятность получить то что заказывал.

✅ Когда тест запустят на стороне разработки, обязательно сверься с базой и убедись что всё летит как надо (скорее всего у тебя в БД есть таблица типа ab_test, где хранятся данные по юзерам, тестам и вариантам).

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

В общем-то это всё. Это один из самых частых флоу, который я встречал. Но он, естественно, не всегда такой и у тебя будут свои нюансы на каждом шаге. Иногда у твоей сплитовалки нет интерфейса и ты “заводишь” тест напрямую в задаче на разработку, иногда это сторонняя система со своими правилами.

Но т.к. АБ — это твоя территория, тебе и менеджерить весь процесс 🙂