Зачем нужен хэш с солью в 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 экспериментах)

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

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

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

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

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

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

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

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

А чем пользовались вы, когда изучали 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 🐳, выложу пост про подборку статей по 🆎

Вопрос с собеседования в продуктовую команду

🍴 Всем привет! Этот пост будет сочетать в себе две темы: практические продуктовые кейсы + вопрос с собеседования. В компании вы можете столкнуться с тем, что какая-то метрика (возьмем для примера конверсию в покупку) упала (например, увидели в отчетности или посмотрели в данных), вопрос, почему такое может быть? Сформулируйте ряд гипотез, на что бы вы посмотрели в первую очередь?

Давайте попробуем разогнать в комментариях.

Следующий пост (если наберется 100 🐳) - будет решение, как бы я подступился к этой задаче

UPD: Давайте возьмем сервис размещения объявлений для примера

Вы набрали достаточное количество реакций, поэтому привожу 1 кейс - это когортный анализ в SQL.

☕️ Этот подход важен, когда нужно понять, что происходит с пользователями спустя какое-то время после их взаимодействия с продуктом. Например, они пользуются новой фичей или заходят в продукт через 1, 7, 14, 30 дней после регистрации? Когортный анализ помогает ответить на такие вопросы.

🍪🍪 Пример задачи

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

🤔 Что сделаем?

1. Разделим пользователей на когорты по дате регистрации.
2. Посчитаем, сколько пользователей из каждой когорты совершили хотя бы одно действие через 0, 1, 7, 14 и 30 дней.
3. Рассчитаем удержание в процентах относительно размера когорты.

with cohort_base as (
    select
        u.user_id,
        date(u.registration_date) as cohort_date,
        datediff(e.event_date, u.registration_date) as days_since_registration
    from users u
   left join events e
        on u.user_id = e.user_id
    where e.event_date is not null
),
cohort_activity as (
    select
        cohort_date,
        days_since_registration,
        count(distinct user_id) as active_users
    from cohort_base
    where days_since_registration between 0 and 30
    group by cohort_date, days_since_registration
),
cohort_size as (
    select
        date(registration_date) as cohort_date,
        count(distinct user_id) as cohort_size
    from users
    group by cohort_date
)
select
    ca.cohort_date,
    ca.days_since_registration,
    round(ca.active_users * 100.0 / cs.cohort_size, 2) as retention_rate
from cohort_activity ca
join cohort_size cs
    on ca.cohort_date = cs.cohort_date
order by ca.cohort_date, ca.days_since_registration;

😱 Что делает этот запрос?

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

cohort_activity - считаем количество уникальных пользователей, которые были активны через 0, 1, 7, 14 и 30 дней после регистрации, для каждой когорты.

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

🐸 Рассчитываем удержание (retention_rate) как процент активных пользователей от общего числа зарегистрированных в когорте.

Можно выявить, как изменения в продукте (новая фича, интерфейс) влияют на удержание пользователей. Если retention сильно падает после первых дней, это сигнал, что пользователи теряют интерес или сталкиваются с трудностями.

Обратная задача рассчитать Churn Rate, нужно просто сделать 1 - Retention Rate

Если наберется 100 🐳, выложу еще пост с практическим применением SQL, есть еще что рассказать 🔥

Да, я 🤔

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

Формат:

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

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

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

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

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

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

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

🎄 При проектировании A/B эксперимента учитывайте сезонность, например, в Новый Год пользователи могут вести себя по-другому

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

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

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

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

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

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

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

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

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

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

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

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

Подглядывание в 🆎 тестах. Я ошибся, я могу один раз ошибиться?

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

В чем основная суть?

Предположим, мы запустили эксперимент, который должен идти 14 дней (так мы определили по дизайну). Возьмем для примера базовый t-test для двух выборок.

Вдруг мы решили посмотреть на результаты, видим значимое изменение. По сути (если мы знаем формулу для t-test'а или другого статистического критерия), накопительно на каждый день можем посчитать статистику и увидеть, что, например, в 4 день (ладно-ладно, в 7), мы увидели значимое изменение. Пришла в голову гениальная мысль отрубить тест и экстраполировать выводы, но так, очевидно делать нельзя, и вот почему:

1. Мы рассчитывали сроки эксперимента в зависимости от трафика. Чем меньше пользователей, тем сильнее шум.
2. Доверительный интервал получается весьма широким, мы можем не до конца быть уверенными в эффекте (та же история может случиться и в обратную сторону, p-value от статистики (например, разницы средних) может "отскочить" от промежутка (0, alpha). Если бы мы подсмотрели, мы сделали неправильное решение.
3. На симуляциях мы повышаем ошибку первого рода (FPR) достаточно сильно. Подглядывание даже может имитировать подбрасывание монетки (по факту, мы проверяем несколько гипотез, что за 1, 2, 3, ... n день средние различаются, тем самым мы рискуем ошибиться. Подробнее можно посмотреть тут

Что можно посмотреть по этому поводу?

1. Статья от GoPractice..
2. Видео от Анатолия Карпова.
3. Пост от ProductSense на Facebook

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

🐳🐳🐳 100 реакций на пост и разгоняем дальше 🐳🐳🐳

😏 Итоги года

🚶‍♂️ х2.2 подписчиков с начала года. Дальше - больше. Ставим таргет на х2 к концу следующего года.

😱 104 публикаций за год. Обещаю повысить эту цифру к следующему году, чтобы влиять на вовлеченность пользователей

🎄 Всем спасибо! Хороший выдался год! Желаю каждому карьерных успехов, интересных задач и сочных офферов

🐳 4.5к реакций за год? Интересно, можем ли сделать +2-3% к этой метрике?

😑 А что интересного случилось у вас за этот год? Пишите в комментариях

Как проводите новогодние праздники? Отдыхаете / обучаетесь / работаете?

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

Как я вижу для себя:

1. Сделать для новичков
2. Сделать для продолжающих (а как можно расти еще быстрее, что нужно делать, чтобы расти)
3. Объединить несколько форматов.

Все зависит от вас! Ставьте много 🐳(200?) и я начну двигаться к разработке данного формата.

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

https://t.iss.one/boost/zasql_python

Недавно наткнулся на подкаст, где обсуждалась важная тема для аналитиков. Там говорили о том, что всех аналитиков условно можно разделить на две категории: “аналитики-калькуляторы” и “аналитики-партнеры”. Захотелось поделиться своими мыслями.

➕ 🟰 Аналитики-калькуляторы - это те, кто выполняет задачи, которые им ставят. Считают данные, строят отчеты, собирают чарты и системы, которые потом менеджмент использует для дальнейшей работы. И это не плохо, потому что без базовой аналитики никуда. Адхоки, регулярные отчеты, которые лежат в основе процессов, - это база. Но проблема в том, что у многих такой подход становится потолком. Они не понимают, зачем их данные нужны бизнесу, что именно решают их чарты или отчеты. Если не задумываться об этом, можно долго работать в таком режиме. Хотя с другой стороны, это может быть отличным временем для прокачки технических навыков и понимания основ.

🍪 🍪 Аналитики-партнеры - это уже другой уровень. Они не просто считают и отдают результаты, а берут на себя ответственность за влияние этих данных на бизнес. Они понимают, для чего нужны те или иные задачи, предлагают решения, которые не только закрывают запросы, но и приносят реальную пользу. Здесь уже важны не только технические навыки, но и способность общаться, правильно доносить идеи до людей из разных отделов, выбирать подход к каждому, чтобы убедить в правильности решений. Это те, кто видят шире, чем просто таска.

Как вырасти до аналитика-партнера? [мое мнение]

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

2️⃣ Адаптация коммуникации. Мы часто забываем, что общаемся с людьми, которые могут не знать, что такое p-value или зачем ты используешь тот или иной метод. Людям из бизнеса важно понимать результат: как это повлияет на их задачи, принесет ли прибыль или решит проблему. Умение говорить на языке разных команд - аналитиков, маркетинга, продукта - это ключ к тому, чтобы становиться партнером.

3️⃣ Активная позиция и фильтрация задач. Когда задач много, важно понимать, какие из них действительно решают проблему, а какие - просто затыкают дыру в имеющемся процессе. Аналитик-партнер не просто выполняет запланированные таски, а задает вопросы: “А это точно решит проблему?”, “Какое влияние это окажет?”, “Можно ли сделать проще или эффективнее?”. При этом нужно уметь фильтровать входящие запросы. Не все задачи стоит брать в работу, но те, которые ты принимаешь, важно выполнять так, чтобы не пришлось переделывать или добавлять правки. Инициативность здесь тоже играет роль: иногда ты можешь предложить свой вариант решения, который окажется лучше исходного.

4️⃣ Учиться у тех, кто уже разбирается в области. Коллеги, которые давно работают в компании или просто сильнее тебя в каких-то аспектах, – это ценный источник знаний. Если ты не понимаешь, как работает тот или иной процесс, не бойся задавать вопросы. Работать в паре над задачами – это тоже хороший способ быстрее разбираться в сложных темах.

Что думаете, корректно ли делить аналитиков именно так? Конечно, есть те, кто работает исключительно в операционной зоне, и это тоже важная часть. Но здесь речь именно про тех аналитиков, которые могут влиять на развитие бизнеса своими инициативами. Если интересно, ставьте 1️⃣0️⃣0️⃣ реакций (завез еще кастомные), и я разберу что-нибудь ещё - подкаст, статью или, может быть, ваш запрос. А в комментариях будет круто почитать ваши мысли, делитесь!

Заскулил питона at the gym

В 10 классе начал тягать железо в тренажерном зале. Понравилось, хожу до сих пор. (по крайнем мере я стараюсь).

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

В Яндексе есть тренажерка, в которой я обычно зависаю 2-3 раза в неделю. Для себя выбираю оптимальный формат по тренировкам в зависимости от загруженности: ходить утром или вечером.

Утром сложно пересилить себя и не поспать подольше
(опять же речь про дисцпилну).
А я сова 🦉
Под конец работы чувствую себя уставшим, но появляется еще время что-то поделать, например, подготовиться к экзаменам в магистратуру.

Вечером обычно ходит много людей и тренировка может заканчиваться в 22-23, остается только доехать до дома и ночью(либо в течение дня) находить свободное время для изучения нового

А как вы совмещаете хобби с работой?
Поделитесь своим опытом?

#личнаяжизнь@zasql_python