Propensity Score Matching (Causal Inference ч. 2).

Сегодня обсудим то, что это такое, рассмотрим какие-то кейсы и то, как можно интерпретировать то, что получается с помощью этого метода

Итак, представьте, вы раскатили фичу на всех, оценить эффект может быть очень тяжело, либо невозможно по причинам, указанным выше. Например, запустили какой-то функционал, хотите понять эффект спустя какое-то время на срезе тех пользователей, кто пользуется фичой. Но тут у вас возникает вопрос (скорее всего), а с кем сравнивать вообще, как оценить влияние на бизнес? Должно быть понятно, что если мы раскатили фичу на срез пользователей в >=50%, то матчить будет не из кого.

Наверное, вы или ваш менеджер продукта определяет различные сроки проектов, т.е. с этим у нас проблем нет (treatment date, предположим, у нас есть). Это означает, что мы знаем фактическую дату раскатку фичи, формата и так далее, но нам важно честно замерить эффект. Ранее я прикреплял видео по PSM, где аналитик из Маркета рассказывал то, как оценивать эффект.

Как это реализуется? У нас есть срез пользователей, кто является для нас таргетом. Для них нужно подобрать репрезентативный контроль таким образом, чтобы в предпериоде (так же, как и при рандомной семплировании при A/B тестировании) целевые метрики / ковариаты не расходились. В общем случае в различных сегментах наши пользователи могут различаться (например, нашей фичой пользуется сегмент богатых, а мы сравниваем их со всеми, нечестно, получается). На данном этапе мы хотим подобрать максимально похожих пользователей на основе некого значения Propensity Score (прикрепил статейку от X5, тут очень интересно можно прочитать про это) и тут

Алгоритм:
1. Собираем признаковое пространство на сущность, которую мы хотим тестировать с таргетом - отнесение к определенному срезу пользователей (бинарная случайная величина).
2. Определяем вероятность отнесения к определенной группе, можно воспользоваться predict_proba для любого классификатора, в качестве бейзлайна
3. На выходе нам нужно подобрать наиболее подходящие группы по Propensity Score (можно использовать Nearest Neighbors, предварительно обученной на тритменте, поскольку мы предполагаем, что тритмента меньше, чем контроля + нам нужно замерить именно ATT, Average Treatment Effect of the Treated), таким образом получить наложенные друг на друга плотности вероятности ковариат (признаки) и таргета (целевой метрики, например, количество заказов).

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

Classical 1:1 matching without replacement may not be the most suitable approach when the number of individuals enrolled in a study is small, and when an imbalance in terms of treated and untreated subjects is present. Moreover, the initial sample size of the study, which is generally small, can be further reduced, increasing the sampling variability associated with the treatment effect estimate and reducing the accuracy of the findings

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

У метода могут быть проблемы, если сравнивать с классическим A/B тестом (в т. ч. сложность интерпретации, много условий, определенные искажения и смещения

🍪🍪 Если вам было интересно, ставьте реакции, пересылайте друзьям / коллегам, пишите комментарии, а я в следующих постах разберу более подробно другие вариации или разберу статейки по Propensity Scores, различные подходы и др.

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

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 🐳, выложу пост про подборку статей по 🆎