Дизайн 🆎 экспериментов и почему это важно.

😱 Ранее я считал, что важнее всего подводить итоги, но как оказалось не только. Дизайн эксперимента подразумевает определенную структуру, комплекс действий, направленных для корректного запуска и последующего анализа эксперимента. Подразумевается, что разметка уже готова (более подробно хочу рассказать в следующих постах).

🎄 При проектировании A/B эксперимента учитывайте сезонность, например, в Новый Год пользователи могут вести себя по-другому
💡 Нужно определиться с гипотезой. Проводя A/B тестирование, мы всегда говорим о постановке различных гипотез, как на языке бизнеса (в понятном для всех формате), так и на языке статистики, когда говорим про нулевые и альтернативные гипотезы. Важно понимать, что от гипотезы зависит многое. По сути, как мы дальше будем интерпретировать различные варианты.

🙅‍♂️ Риски. Какие могут быть риски для компании? Если что-то резонирующее, которое сразу улетит в СМИ - тест можно перезапускать, можем получить при анализе невалидные результаты. Например, если мы просто убираем точку входа или полностью меняем популярное приложение при раскатке 50/50.

🗒 Определение метрик и теста. А на что мы смотрим, когда подводим итоги? Может есть какие-то целевые, по которым мы хотим принимать решения, а может есть какие-то вспомогательные, которые нам нужны для дальнейшего анализа. Если у нас есть своя A/B платформа, проблемой с подсчетов быть не должно. На этом этапе важно также понимать какой тест мы используем для анализа.

☕ Сегменты пользователей. Хотим мы катиться на всех или нет зависит от сетапа эксперимента, возможно, нам нужно брать определенный срез пользователей (старички/новички, пользователи, обладающие каким-то признаком).

🌳 Дерево принятия решений. Если метрик несколько, мы должны определиться с различными вариантами, когда эксперимент катим, а когда нет. Если метрика серая, то..., а если нет, то. Базово должно фиксироваться до проведения эксперимента.

😁 Определение MDE / размера выборки / длительности эксперимента. Мы должны понять на истории, а действительно ли мы сможем прокрасить эксперимент? По сути, тот же MDE нужен нам для определения примерной длительности эксперимента или ответа на вопрос, а эта метрика чувствительна вообще будет на данном срезе или нет?

🥪 Другие слои. А считаем ли мы корректным проводить эксперимент, если слои забиты, а насколько забиты, все ли окей в этом плане?

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

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

✅ Корректное логирование эксперимента. Можно раскатить на себя, посмотреть, собрать различные события в тестовой группе, попробовать посчитать метрики (просмотр, клик по фиче X, которую мы запускаем на тестовую группу).

🚀 **Запуск эксперимента

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

🍪🍪 Понравился формат, когда спрашиваю про то, о чем хотите видеть посты. Давайте постараемся внедрить. О чем пишем на следующей неделе? Выберу среди топа залайканных комментариев.

Формат:

💻 Пост про какую-то область в ML, практические кейсы в работе аналитика

🆎 Пост про дизайн экспериментов. Про какие-то статьи. Хочу понять, почему так считаем.

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

📝 Если вам нравится формат, могу разбирать различные интересные статьи, только дайте знать.

Можно накидать под этот пост комментариев на несколько недель вперед, возьму в соответствующий спринт *😱***

Где практиковать SQL? 😮 Давно не было постов вообще про SQL. Не знаю даже почему, хотя самый важный инструмент в нашей работе. Представьте, что вы прошли какие-то курсы, примерно понимаете как все решать, знаете основные концепции, но хочется потрогать задачи…

Как доверительные интервалы помогают решать задачи бизнеса?

😏 Всем привет! В этом посте вообще опишу то, с какой ситуацией можно столкнуться, анализируя эксперименты. Представим, что мы задизайнили эксперимент, определили слои, запустили эксперимент, собрали все требования, ожидания, выбрали целевые метрики и вот мы уже подводи итоги эксперимента. Бизнесу важны по большей части деньги и пользовательский опыт. Так вот, смотрим на метрики, видим, что p-value > alpha - уровня значимости, который определили заранее (возможно даже с какими-то поправками), сразу опускаем руки, ведь эффекта не нашли (нет). Как нам ответить на вопрос бизнесу, а что дальше делать с этой информацией?

😎 В дело вступают доверительные интервалы. Вкратце, мы можем понять в каких заданных границах находится истинное среднее (в бизнесе мы всегда работаем с выборочными величинами, а истинное значение мы можем задать через выборочное среднее, z-значение, стандартное отклонение и размер выборки. Если доверительный интервал разницы средних включает 0, то значит, что эффект незначимый, но давайте рассмотрим конкретный пример.

Мы раскатили на любой из поверхностей фичу, ожидали получить рост конверсии в оплату.

```

import scipy.stats as stats
import numpy as np

control_conversions = 500
control_total = 10000
test_conversions = 555
test_total = 10000

control_rate = control_conversions / control_total
test_rate = test_conversions / test_total

effect = test_rate - control_rate

se = np.sqrt((control_rate * (1 - control_rate)) / control_total +
(test_rate * (1 - test_rate)) / test_total)

z_score = effect / se
p_value = 2 * (1 - stats.norm.cdf(abs(z_score)))

ci_low, ci_high = effect - 1.96 * se, effect + 1.96 * se

print('Разница средних, %')
print(np.round(effect, 3) * 100)

print('Доверительный интервал, %')
print([np.round(ci_low, 3) * 100, np.round(ci_high, 3) * 100])

print('p-value')
print(np.round(p_value, 2))

# Разница средних, %
# 0.5
# Доверительный интервал, %
# [-0.1, 1.2]
# p-value
# 0.08
```

😭 Видим, что p-value низкий, можно даже прокрасить CUPED, стратификацией, но давайте посмотрим более детально. Истинное значение конверсии лежит в промежутке от -0.1% до 1.2%, но что значит для бизнеса?

Предположим, что мы сервис доставки продуктов. ARPPU составляет 1000 рублей => мы можем рассчитать эффект в деньгах, возьмем крайние границы доверительного интервала:

```

arppu = 1000
low_effect_arppu = ci_low * control_total * arppu
high_effect_arppu = ci_high * control_total * arppu
print([low_effect_arppu, high_effect_arppu])

# [-6955.767415148702, 116955.76741514866]

```

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

➖ Потенциальный минус: -7 000 рублей➕ Потенциальный плюс: +116 955 рублей

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

Если наберется 150 *🐳*, выложу пост про подборку статей по 🆎****

Где практиковать SQL?

😮 Давно не было постов вообще про SQL. Не знаю даже почему, хотя самый важный инструмент в нашей работе. Представьте, что вы прошли какие-то курсы, примерно понимаете как все решать, знаете основные концепции, но хочется потрогать задачи реальных компаний. Помню, когда сам проходил различные курсы (в том числе всем известный sql-ex, который форсили постоянно), не хватало какой-то практической составляющей, возможно задач с собеседований компаний.

Какие платформы я советую?

1. StrataScratch - здесь представлены задачи различных зарубежных компаний по SQL и не только. Различные вариации оконных функций, подзапросы, сложные структуры и все это заправлено под задачи с собеседований. https://www.stratascratch.com

2. LeetCode - по SQL я встречал не так много задач, но тем не менее, были интересные над которыми можно подумать. Есть нетипичные, которые не решить просто оконкой и взять актуальное значение данных, надо реально подумать. https://leetcode.com/

Понятно, что есть какие-то курсы, про которые я писал выше. Хочу отметить, что я смотрел. Есть DataCamp, кому-то нравится, кому-то нет. Для меня проблема, что большая часть практики - это просто дополнение запроса из предыдущего шага (с нуля что-то ты можешь и не писать вовсе).

У меня был пост с роадмапом, где я затрагивал SQL, поэтому если вам интересно, тыкайте сюда

🍪🍪 В скором времени я планирую выкладывать какие-то практические задачи сюда, с которыми реально может столкнуться каждый аналитик, поэтому, если наберется 100 *🐳*, делаем! Retention, пенетрации, воронки, критерии для A/B тестов и др.

А чем пользовались вы, когда изучали SQL?

Зачем нужен хэш с солью в A/B экспериментах?
😭 Начнем с хэширования. Когда мы запускаем тест, нужно понять, в какую группу попадет пользователь? В контрольную или тестовую? Чтобы сделать это случайным образом, но при этом всегда стабильно, используется хэширование. Берем уникальный идентификатор пользователя, например user_id, пропускаем его через хэш-функцию (чаще MD5), а результат делим по модулю. Например, если результат деления на 2 равен 0, пользователь идет в группу A, если 1, то в группу B. Это гарантирует, что один и тот же пользователь всегда будет попадать в одну и ту же группу.

```

import hashlib

user_id = "12345"
hash_value = int(hashlib.md5(user_id.encode()).hexdigest(), 16)
group = "A" if hash_value % 2 == 0 else "B"
print(group)

```

🧂 Теперь про соль. Если пользователь участвует сразу в нескольких тестах, его распределение в группы может повторяться. Например, в тесте кнопки “Купить” он будет в группе A, и в тесте фильтра товаров он тоже будет в группе A. Это создает пересечения экспериментов и искажает результаты (особенно, когда речь идет про разные слои, которые могут с собой конкурировать). Соль решает эту проблему. Это уникальная строка для каждого теста, которую мы добавляем к user_id перед хэшированием. Она изолирует тесты друг от друга, даже если пользователь участвует сразу в нескольких. То есть соль + хэш позволяет перемешать пользователей псевдорандомом, обеспечивая воспроизмодимость сплитования на платформе.

```

experiment_name = "new_checkout_flow"
salted_id = f"{experiment_name}_{user_id}"
hash_value = int(hashlib.md5(salted_id.encode()).hexdigest(), 16)
group = "A" if hash_value % 2 == 0 else "B"

```

Таким образом, мы разбили на 2 разные группы. Привязались к идентификатору, конкретному эксперименту и сделали псевдорандомизацию. Можно также генерировать на A/A тестах с изменением соли, обеспечивая рандомизацию пользователей. Это не просто взять и четные значения хэша менять на нечетные и наоборот. Посмотрите, как от соли меняется значение конечного хэша + соли.

```

print(int(hashlib.md5(f'salt2_{123}'.encode()).hexdigest(), 16)), print(int(hashlib.md5(f'salt9_{123}'.encode()).hexdigest(), 16))

```

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

И еще один плюс: если вы решите изменить пропорцию распределения, например, сделать 70% пользователей тестовыми, а 30% контрольными, это легко сделать с помощью хэширования. Нужно просто поменять границы.

```

split_percentage = 70
group = "A" if hash_value % 100 < split_percentage else "B"

```

Понравился пост? Если соберется 100 🐳, выложу пост про виды хэшей и чем они различаются (ну или про слои в A/B экспериментах)

😲 Для продуктовых аналитиков нужно находиться на одной волне с продуктом, в котором они работают. Это дизайнеры, продакт-менеджеры, разработчики. Есть бесплатный «онлайн-тренажер» по продуктовому мышлению, на который я натыкался для расширения экспертизы с различными кейсами, подходами к анализу продуктов.

😎 На Хабре есть статья про различные продуктовые кейсы, где можно самому подумать + еще скормить какой-то LLM вариант ответа, тем самым иметь «эталонное решение».

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

А вообще классный вариант просто ходить на собесы, набирать опыт оттуда, обычно на них транслируют фактические проблемы, с которыми сталкиваются различные команды.

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

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

Seeing Statistic Theory

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

🤑 Сейчас я советую сразу присмотреться к курсу по статистике и теории вероятностей от ФЭН ВШЭ. Много практики, хорошо для общего понимания академической статистики и тервера. Будет тяжело, но на выходе получите помимо знаний, структуры особенный эффект после обучения.

♟ Если хотите, разберу относительной новый курс по прикладной статистике от ААА, делал анонс второй части тут

22 *?
Дальше - больше. Всем спасибо, что продолжаете и дальше смотреть за постами, я очень рад этому! Нас уже 3000, блин! С последнего поста про др уже х2 подписчиков ?***

Больше не смогу отправить в красивое время сообщение. Надо было в 11 лет постить…