😢 Думал, что выкладывал сюда эту статью, но нет :(

50 оттенков линейной регрессии, или почему всё, что вы знаете об A/B тестах, помещается в одно уравнение

Авторы предлагают рассмотреть привычные нам методы A/B тестов с точки зрения уравнения линейной регрессии.

Формула, которая используется на протяжении всей статьи

Y = b0+ b1D + e, где D - принадлежность к группе теста или контроля (1 и 0), b0 - матожидание в контроле, b0+b1, матожидание в тесте

Что в статье?

1. Про стандартную оценку эффектов, ATE (Average Treatment Effect)

2. CUPED

3. Стратификация

4. Все в одном уравнении, такое тоже есть, все через модель линейной регрессии.

5. Пример на Python, оценка теста, используя модель линейной регрессии.

В общем, статья хорошая, ставлю лайк 👍

Важен ли SQL бизнесу?

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

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

🧐 А в чем проблема?

Давайте разберем на примере. У нас есть 2 кандидата.

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

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

❓ Вопрос, кому отдавать предпочтение?

Ответ с точки зрения найма: никому

Кажется, что мы ищем специалиста, который сочетает в себе два этих качества, но таких, правда, не большинство

Поинт в том, что какое-то n количество кандидатов отправляются «подучить», а по факту - аналитическое мышление - это менее тривиальная задача, чем просто на искусственных данных написать пару запросиков, что-то покрутить в пандасе (документация, чек)

Провести аналитику и сформулировать четкий вывод - вот что нужно.

😭 К сожалению, пока непонятно, как с этим можно бороться, чтобы ускорить процесс найма…

🧀 А вы что думаете по этому поводу, пишите в комментариях

Используете ли вы трекеры времени для продуктивной работы? Если да, то какие? Сколько примерно вы потратили дней / месяцев / лет, чтобы их внедрить в свою жизнь? Чувствуете ли вы импакт от этого?

🍅 У части людей, например, внедрено для работы Pomodoro. Это когда ты бьешь рабочее время на короткие интервалы для работы и отдыха. Базовый вариант - это когда одна сессия выглядит следующим образом: 25 минут работаешь, 5 отдыхаешь. Требуется больше времени, чтобы быть в фокусе, хотя можно разбить на более длительные сессии. В этой статейке 70 минут работаешь, 20 минут отдыхаешь, 40 минут еще чил. Суммарно 10.5 часов на работу, 3.3 часов на отдых. Итог ~ 14 часов на сессии.

🧠Я склоняюсь в сторону Deep Work - это когда у тебя рабочая сессия длится несколько часов. Фокусированно сидишь над задачей / задачами без отвлечения. На каком-то из часов начинаешь замечать, что делать достаточно. Главное - это подготовить рабочее место, предварительно отключив раздражители, приготовиться к сессии и плотно сидеть и работать, deep work... А еще важнее, на первых этапах, вырабатывая привычку - НЕ ВСТАВАТЬ (очевидно, по каким-то делам / встречкам это делать не получится, но сессию в календаре под это дело забить можно или стремиться к этому). Если брать 4 часа на сессию, а сессий 3, получается 12 часов на сессии.

📖 Дополнительные материальчики для чтения:

🔗LINK 🔗
🔗LINK 🔗

Если вам нравится формат таких постов, ставьте реакции, пишите комментарии

😵 Выбросы в A/B тестах. Проблема при дизайне, подведении результатов, планировании следующих экспериментов.

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

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

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

Почему?

Разные группы (в одной есть тритмент, в другой нет), мы по сути перемешиваем группы и ищем квантиль обеих групп.

Что можно с этим сделать?

1. Убрать выбросы на предпериоде, топ n пользователей по целевой метрике в тесте

2. Заменить значение выбросов на максимальное значение по квантилям. Пример: пользователь принесу сервису 100 рублей, 99% квантиль - 80. Пользователя мы не убираем, заменяем значением 80. Более подробно про это могу написать, проведем симуляции, посмотрим как ведут себя распределения и др.

Материалы:

Как улучшить ваши A/B-тесты: лайфхаки аналитиков Авито.

АБ тесты и подводные камни при их автоматизации

Хорошая статья на Medium, про попытки исключения различным образом выбросов

Это одна из многих проблем, которая есть при проведении экспериментов.

🎲 Что такое predict_proba?

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

predict_proba выдает на выходе вероятности отнесения к какому-либо классу. Мы решаем задачу с Propenity Score Matching, нам нужно в первой итерации (как бы сокращая размерность) для каждого объекта выборки определить вероятность отношения к тритменту (то есть определить 1 - пользователь совершил какое-то действие).

🤔 Как работает?

1. Сначала мы вычисляем линейную комбинацию векторов признаков и весов (с определенным байесом).
2. Результат подается в функцию активацию, например, классический вариант, это сигмоида (для бинарной классификации) и softmax (для многоклассовой классификации).
3. Определяем вероятности.

🐍 Пример отрабатывания вручную

 
from sklearn.datasets import make_classification
from sklearn.linear_model import LogisticRegression

X, y = make_classification()
lr = LogisticRegression()

lr.fit(X, y)

z = np.dot(X, lr.coef_.reshape(-1, 1)) + lr.intercept_

model_predict = lr.predict_proba(X)[:5, 1]

naive = 1 / (1 + np.exp(-z)).flatten()[:5]

print(model_predict)
print(naive)

🥰 Как видим, результаты идентичные (для вероятностей). Можно также поставить трешхолды и определить 1 или 0, чтобы замерять качество полученных моделей.

Дополнительные материалы:

1. How to Use Logistic Regression predict_proba Method in scikit-learn
2. CatBoost. Predict Proba
3. Predict_proba examples in MLflow - October 2024

❤️ Понравился пост? Поддержи бустом, пиши комментарии. Если наберется много реакций, выпущу пост про различные функционалы качества, функции ошибки в машинном обучении или про Sequential Testing 🔥

🤔 Почему важно делать просто в продукте?

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

Вы идете к кому-то из списка выше, договариваетесь, считаете, но тут возникает момент истины, что любые процессы стоят денег / времены для команды. То есть команда будет тратить время на разработку чего-то нового, жертвуя тем, что можно было сделать проще. Например, добавить один виджет / сделать что-то простое и увидеть инкремент на бизнес или посмотреть на исследования других компаний, в т.ч. конкурентов. Тут можно еще затронуть базово концепцию MVP (Minimal Valuable Product), но тут, скорее, вопрос приоритезации и то, что случайно есть риск зарубить хорошие жирные гипотезы (есть же декомпозиция, все дела...)

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

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

❤️ А что вы думаете по этому поводу, сталкивались ли вы с подобным? Если наберется много реакций продолжу дальше писать про продуктовые штуки.

ПОДДЕРЖАТЬ БУСТОМ

Ждём сообщения от заказчиков, смежников, только так. Никаких похвал, только это. Высшая благодарность 👍

#мемы

Seeing Statistic Theory

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

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

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

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

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

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

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

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

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

Зачем нужен хэш с солью в 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 🐳, выложу пост про подборку статей по 🆎