Propensity Score Matching: когда A/B-тест невозможен

Привет! На связи Илья Ковалёв, старший аналитик данных в Dodo Brands и автор канала про аналитику кусочек пиццы 👋🏻

Сегодня поговорим про один метод, который на первый взгляд может показаться ультимативным, но на самом деле он, как и прочие методы, применим не везде — Propensity Score Matching.

В чём суть метода?

Представьте ситуацию: вы запустили новую фичу, но не для всех пользователей случайно, а только для тех, кто сам её активировал. Классический A/B-тест не сработает — группы изначально разные. Активные пользователи включили фичу, пассивные — нет.

Вопрос: как понять, влияет ли фича на метрики, или разница только из-за того, что группы изначально были разными?

PSM решает эту проблему. Метод позволяет найти для каждого пользователя из тестовой группы похожего «близнеца» из контрольной группы. Похожего по всем важным характеристикам: траты, активность, история покупок и т. д.

Вот краткий алгоритм:

Шаг 1: строим модель, которая предсказывает вероятность попадания в тестовую группу

Берём характеристики пользователей (возраст, город, количество заказов, средний чек) и строим логистическую регрессию. Она предсказывает вероятность попадания в тестовую группу — это и есть Propensity Score.

Шаг 2: мэтчим пользователей по Propensity Score

Для каждого пользователя из тестовой группы ищем пользователя из контрольной с максимально близким Propensity Score.

Шаг 3: сравниваем метрики

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

Когда PSM работает хорошо?

1️⃣ Есть много признаков, которыми можно описать пользователей
Больше данных → точнее модель → лучше мэтчинг.

2️⃣ Группы пересекаются по характеристикам
Если в тестовой группе только VIP-клиенты, а в контроле их нет — мэтчинг не сработает. Нужно, чтобы для каждого пользователя из теста нашёлся похожий в контроле.

3️⃣ Решение о попадании в группу зависит от наблюдаемых факторов
Если пользователь активировал фичу из-за факторов, которые мы можем измерить (активность, возраст, город) — отлично. Если из-за чего-то скрытого (настроение, рекомендация друга) — PSM это не учтёт и возникнет смещение.

Как проверить, что мэтчинг работает?

Недостаточно просто проверить баланс групп по характеристикам. Нужна валидация на историческом периоде.

Примените PSM к данным ДО воздействия. Например, фичу запустили 1 июня — сделайте PSM на данных за май. Если хорошо подобранные фичи показывают «эффект» там, где его быть не может — проблема в скрытых факторах, плохом мэтчинге или в сверхвысокой чувствительности.

Так, на выборках 100k+ пользователей возникает проблема: любая мизерная разница становится статистически значимой. P-value < 0.05 при разнице в 0.01% — технически значимо, но практически шум.

Решение: не использовать всю выборку. Можно определить MDE (минимальный детектируемый эффект, например +2%), расчитать нужный размер выборки под этот MDE и ограничить выборку до этого размера - т.е. взять случайные 50k вместо всех 500k.

Так вы не будете детектить шум как значимый эффект.

На что ещё стоит обратить внимание

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

2️⃣ Работайте с выбросами. Перед построением модели сглаживайте или убирайте выбросы. Экстремальные значения могут исказить Propensity Score и ухудшить матчинг.

3️⃣ Используйте Caliper Matching. Не мэтчите пользователей, если разница в Propensity Score больше порога (например, 0.01). Лучше потерять часть данных, чем получить плохие пары.

4️⃣ Всегда проверяйте качество мэтчинга на историческом периоде. Это единственный способ убедиться, что метод мэтчит без смещения.

PSM — мощный инструмент, когда рандомизация невозможна. Однако не стоит бездумно пихать его в любой эксперимент. Рассматривайте каждый кейс индивидуально: начиная с методов оценки и заканчивая метриками и фичами.

📈 Симулейтив | ВК | YouTube

Как работать с датами и временем в аналитике

Всем привет! На связи Александр Грудинин, ментор курса «Аналитик данных» 👋🏻

Сегодня поговорим про тему, которая кажется простой, но на практике входит в топ источников багов в аналитике — работа с датами и временем.

Самое неприятное, что ошибки с датами сложно заметить. Метрика считается, график строится, всё выглядит правдоподобно... но цифры неверные.

Примеры буду показывать на PostgreSQL, но логика применима и к другим БД.

🟠 DATE vs TIMESTAMP

DATE — просто календарная дата: 2025-03-15
TIMESTAMP — дата + время: 2025-03-15 14:30:00

Почему важно различать? Вот классический баг:

WHERE created_at = '2025-03-15'

Заказ в '2025-03-15 10:30:00' сюда НЕ попадет!

➖ Рабочий вариант #1 — приведение к дате:

WHERE created_at::date = '2025-03-15'

➖ Рабочий вариант #2 (есть мнение, что так лучше, но я сам использую предыдущий):

WHERE created_at >= '2025-03-15' AND created_at < '2025-03-16'

🟠 Часовые пояса — главная боль

Пользователь из Москвы сделал заказ в 1:30 ночи 15 марта. На сервере в UTC это записалось как 14 марта 22:30. Один заказ, два дня. Умножьте на тысячи заказов 🙃

Конвертируем UTC в московское время:

SELECT
 (created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Europe/Moscow')::date AS order_date,
 COUNT(1) AS orders_count
FROM orders GROUP BY 1

В pandas то же самое:

# Указываем что данные в UTC
df['created_at'] = pd.to_datetime(df['created_at']).dt.tz_localize('UTC')
# Конвертируем в Москву
df['created_at_msk'] = df['created_at'].dt.tz_convert('Europe/Moscow')`

Важно:
➖ tz_localize = «эти данные уже в таком поясе, запомни»
➖ tz_convert = «пересчитай из одного пояса в другой»
Перепутаете — и получите сдвиг на несколько часов во всех данных 🙂

🟠 Ещё одни грабли — формат дат

Дата 03/04/2025 — это 3 апреля или 4 марта? Pandas может угадать неправильно. Всегда указывайте формат явно:

df['date'] = pd.to_datetime(df['date'], format='%d/%m/%Y')

Чек-лист для проверки:

#️⃣ Проверяйте тип данных — DATE или TIMESTAMP?
#️⃣ Выясняйте, в каком часовом поясе хранятся данные в источнике данных
#️⃣ Договоритесь с командой о едином часовом поясе для отчётов
#️⃣ Явно указывайте формат при парсинге дат

Ставьте 🔥 и сохраняйте шпаргалку к себе!

📈 Симулейтив | ВК | YouTube

Через 2 часа — вебинар, как стать универсальным аналитиком

Подключайтесь в 19:00 МСК и узнайте, почему fullstack-подход становится стандартом, какие задачи теперь решает один специалист вместо трёх и за что на самом деле платят деньги в аналитике. Вебинар проведёт Илья Ковалёв, старший аналитик данных в Dodo Brands и автор канала кусочек пиццы. Присоединяйтесь!

➡️ Регистрация

📈 Симулейтив | ВК | YouTube

5 SQL‑ошибок, которые продолжают ломать запросы даже у опытных аналитиков

Привет, коллеги! С вами снова Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

Сегодня разберём ещё пять ошибок, которые встречаются куда чаще, чем кажется.

1️⃣ Использование SELECT * в продовых запросах

SELECT * — это самый частый запрос, который я пишу, но не всё так просто. Да, на этапе исследования данных это очень удобно. Ты видишь все столбцы и понимаешь структуру таблицы, но в проде SELECT * — это лишние данные, которые нагружают темп и память.

Например, у нас есть таблица с пользователями и транзакциями:

SELECT *
FROM transactions t
JOIN users u ON t.client_id = u.client_id

Сделать SELECT * для изучения и проверки — правильное решение, но записывать такую конструкцию в созданную таблицу нельзя. Если в таблицу users добавят поле с большим текстом — например, выводы ИИ о клиенте — то во-первых, запрос сломается, так как появится новое поле. А во-вторых, если заменили содержимое существующего поля, то запрос внезапно станет в 10 раз тяжелее.

Правильно отбирать только нужные столбцы:

SELECT t.client_id, t.amount, u.segment
FROM transactions t
JOIN users u ON t.client_id = u.client_id

2️⃣ Неправильная работа с NULL в условиях

NULL — это не значение, это пустота. И многие забывают, что сравнения с NULL работают иначе, чем сравнение с заполненными полями.

Например, вам нужно отобрать всех клиентов, кроме клиентов с тестовым емейлом. Если написать:

WHERE email <> ‘test@example.com’

То строки, где email = NULL, не попадут в выборку, хотя логически должны. Это частая ошибка, на которой ловят новичков. Чтобы правильно отобрать клиентов, используйте:

WHERE email <> ‘test@example.com’ OR email IS NULL

или

WHERE nvl(email, ‘N/A’) <> ‘test@example.com’

3️⃣ Фильтрация после JOIN вместо фильтрации до JOIN

Очень часто нам нужно объединить таблицы и отфильтровать их одновременно. Многие начинающие аналитики делают так:

SELECT *
FROM users u
LEFT JOIN transactions t ON u.client_id = t.client_id
WHERE t.amount > 100

Фильтр превращает LEFT JOIN в INNER JOIN и убивает значения из таблицы users, так как отфильтровывает все данные после объединения. Но пользователи без транзакций вам тоже нужны. Чтобы сделать правильный запрос и ничего не потерять, используйте фильтрацию внутри JOIN:

LEFT JOIN transactions t 
    ON u.client_id = t.client_id
    AND t.amount > 100

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

4️⃣ Использование HAVING вместо WHERE

Путаница между WHERE и HAVING — это вечная проблема. Запомните, HAVING — это фильтр после группировки. Давайте рассмотрим на примере:

SELECT employee_id, SUM(salary)
FROM salary
GROUP BY employee_id
HAVING SUM(salary) > 1000

В данном запросе результат будет покажет только сотрудников с общей зарплатой более 1000 за весь период. То есть фильтрация будет после агрегации. Но если вам нужны только те сотрудники, которые каждый месяц получают более 1000, то есть условие до агрегации, то вам нужно использовать:

SELECT employee_id, SUM(salary)
FROM salary
WHERE salary > 1000
GROUP BY employee_id

Выглядит похоже, но смысл совершенно разный.

5️⃣ Использование UNION вместо UNION ALL

UNION, в отличие от UNION ALL, сверяет все строки и удаляет дубли. Поэтому использование UNION значительно замедляет запрос. Если вам не нужно удалять дубли, то не пишите:

SELECT client_id FROM table1
UNION
SELECT client_id FROM table2

Вместо этого используйте:

SELECT client_id FROM table1
UNION ALL
SELECT client_id FROM table2

Ставьте 🔥, если было полезно, и сохраняйте к себе, чтобы не допускать эти ошибки!

📈 Симулейтив | ВК | YouTube

Как CUPED сократил нам время эксперимента с 3 недель до 10 дней

Привет, на связи Аслан Байрамкулов, автор курса по A/B-тестированию 👋🏻

На заре своей карьеры в A/B я столкнулся со следующей ситуацией. Мы упёрлись в потолок, тесты шли по 3 недели, очередь росла. И как сказал в старом интервью Олег Дерипаска: «Так больше продолжаться не может». Вот как мы вышли из данной ситуации.

Кейс: тестируем новую логику ранжирования в каталоге.
Основная метрика: revenue per user.

PM хочет результат через неделю. Классический дизайн эксперимента требовал от нас эксперимента с длительностью 21 день, но у нас просто не хватало трафика для достижения того же результата по надёжности оценки эффекта за 1 неделю, как этого хотел бизнес.

PM расстроен, мы тоже, потому что параллельно в очереди ещё 4 эксперимента, и каждый будет стоять по 3 недели. Но всё равно как-то надо придумывать решение данной проблемы.

В нашем случае revenue per user — метрика с довольно большой дисперсией. Есть пользователи с чеком 100 ₽, а есть с чеком 80 000 ₽. Эта естественная вариативность «забивает» сигнал от нашего воздействия. Мы ищем разницу в 3%, а шум — в разы больше.

И нам на помощь пришел CUPED.

Идея простая. У каждого пользователя есть исторические данные до эксперимента — его пре-экспериментальная выручка. Тот, кто тратил много до теста, скорее всего будет тратить много и во время теста. Эта предсказуемая часть — шум, а не эффект нашей фичи.

CUPED вычитает эту предсказуемую часть из метрики. Формально:

Ŷ_cuped = Y − θ · (X − X̄)

где X — пре-экспериментальный revenue, θ — коэффициент, минимизирующий дисперсию.

В результате мы буквально вдвое сократили время эксперимента, не меняя ни трафик, ни дизайн, ни метрику. Просто умнее использовали данные, которые уже у нас были.

Где CUPED не поможет

Справедливости ради отмечу, что метод не волшебный. Если корреляция данных в пред- и пост-периодах слабая, то выигрыш будет минимальным. Например, для метрики «совершил ли пользователь первую покупку» предэкспериментальных данных просто нет. Для новых пользователей — тоже. Поэтому CUPED отлично работает в ситуациях с высокой корреляцией данных до/после эксперимента и на уже активных/существующих объектах, но плохо на всякого рода регистрациях и первых действиях.

Что это дало нам: пропускная способность экспериментов выросла почти вдвое. Раньше за квартал мы прогоняли 4-5 тестов последовательно. После внедрения CUPED — 8-9. Это не просто ускорение одного теста — это кумулятивный эффект на скорость принятия решений во всём продукте.

В курсе по A/B-тестам мы не только разбираем математику CUPED, но и пишем весь необходимый код на Python, который можно подключить к своему пайплайну для решения ваших задач. Плюс разбираем случаи, когда CUPED не помогает.

🔥 Записывайтесь уже сейчас: simulative.ru/ab-test

📈 Симулейтив | ВК | YouTube

Присоединяйтесь к мастер-классу по SQL

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

На бесплатном мастер-классе c Евгением Буториным разберём, что такое SQL и почему без него не стать востребованным специалистом. А главное — перейдём к практике: будем решать задачи по SQL и разбирать реальные бизнес-кейсы.

На мастер-классе расскажем и покажем:
🟠 Что такое SQL и почему это основа работы с данными;
🟠 Почему аналитикам важно владеть этим инструментом;
🟠 Как решать практические задачи по SQL разного уровня сложности;
🟠 Как применять запросы к реальным бизнес-задачам: от сегментации клиентов до расчёта метрик;
🟠 Какие фишки и подходы используют в крупных компаниях на примере Альфа-Банка.

❗️ Встречаемся 7 апреля в 19:00 МСК.

💬 Подключайтесь к эфиру, чтобы задать Евгению вопросы про SQL и карьеру в аналитике и разобрать свои кейсы!

➡️ Зарегистрироваться на мастер-класс

📈 Симулейтив | ВК | YouTube

6 вопросов на собеседовании джуна: что я реально спрашиваю и каких ответов жду

Привет, аналитики! С вами Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

Когда мы говорим о собеседованиях, то очень важно понимать уровень позиции, на которую идет набор. В зависимости от этого необходимо корректировать ожидания. Я не жду от джуна идеального SQL на уровне сеньора и 5 лет опыта. Мне важно понять:

😶 Понимает ли человек базовые принципы;
😶 Умеет ли думать;
😶 Готов ли учиться и не боится ли данных.

Вот мои любимые вопросы, которые я задаю почти всем кандидатам, которые хотят попасть в мою команду. И сразу — какие ответы меня реально радуют:

1️⃣ «Расскажи о себе и почему ты хочешь стать аналитиком данных?»

Что я жду: человек объясняет, как он понял, чем аналитик отличается от разработчика/маркетолога/финансиста. Почему данные — это именно то, чем ему хочется заниматься. Приводит 1–2 примера из жизни/курса, например: «Когда я сделал дашборд по продажам на курсе и увидел, где компания теряет 30%, я понял, что хочу этим заниматься».

2️⃣ Базовый SQL-вопрос:

«Есть таблица orders (id, user_id, amount, order_date). Напиши запрос, который покажет топ-5 пользователей по сумме заказов за последний месяц».

Что я жду: понимание GROUP BY + ORDER BY + LIMIT и знание, как работать с датами (например, WHERE order_date >= date ’2026-03-01’). Не обязательно идеальный синтаксис, главное — логика.

3️⃣ «Как бы ты посчитал средний чек и медианный чек? В чём разница?»

Что я жду: чёткое объяснение: средний = SUM(amount) / COUNT(*), медианный — 50-й перцентиль, и почему медиана важнее при выбросах — один клиент на 500 тыс. руб. может сильно исказить средний чек.

4️⃣ «Представь: тебе дали таблицу с продажами за год. Там 15% пропущенных значений в колонке amount. Что будешь делать?»

Что я жду (один из вариантов):
➖ Сначала посмотрю, почему они пропущенные (возможно, техническая ошибка).
➖ Если техническая — заполню медианой или средним по сегменту.
➖ Если бизнес-логика — оставлю как NULL или создам отдельную категорию «неизвестно». Главное, чтобы человек не сказал просто «не буду учитывать пустые строки».

5️⃣ Мини-кейс (самый важный вопрос):

«Продажи в категории “кредиты” упали на 25 % за последний месяц. Что ты сделаешь первым делом?»

Что я жду (структура ответа):
🟠 Проверить данные — не ошибка ли в выгрузке;
🟠 Разложить по сегментам — найти группу клиентов, в которых произошло падение;
🟠 Посмотреть динамику предыдущих лет — возможно, сезонный фактор;
🟠 Сформулировать 2–3 гипотезы.
Кто начинает сразу с «запустим рекламу» — это сразу минус. Мне нужен аналитик, а не советчик.

6️⃣ Поведенческий вопрос:

«Были ли у тебя конфликты на прошлых местах работы. Как их урегулировал?»

Что я жду: честную историю. Важно услышать, как человек справился с ситуацией, кого обвинил в конфликте, как долго продолжался конфликт и повлиял ли на рабочий процесс?

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

🟠 Записаться на поток с моим участием: simulative.ru/data-analyst

📈 Симулейтив | ВК | YouTube

SQL-фишки и ошибки: RANK(), DENSE_RANK(), ROW_NUMBER() и BETWEEN

Всем привет! С вами Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

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

1️⃣ Разница между RANK(), DENSE_RANK() и ROW_NUMBER()

Эти три функции часто путают, но на самом деле они используются в абсолютно разных ситуациях. Давайте разберёмся:

➖ ROW_NUMBER() присваивает уникальный номер каждой строке, даже если значения одинаковые. Игнорирует дубликаты, просто нумерует по порядку. Применяется, когда нужны уникальные ID для строк, например, для пагинации. Также часто применяется при дедупликации.

Например, нам нужно найти топ-5 продаж по сумме:

SELECT id, product, amount, ROW_NUMBER() OVER (ORDER BY amount DESC) AS rn FROM sales;

В результате, если два товара по 100 рублей, один получит 1, другой 2 и т. д. То есть будет 1, 2, 3. Комбинируйте с CTE или подзапросом для удаления дублей.

➖ RANK() присваивает ранг с учётом дубликатов — одинаковые значения получают один ранг, но следующий пропускается. Применяется, когда важна «ничья», как в спортивных рейтингах или топах с пропусками.

Например, нам нужно определить ранг продуктов по продажам в категории:

SELECT id, product, amount, RANK() OVER (PARTITION BY product ORDER BY amount DESC) AS rank FROM sales;

Результат: если у вас две строки с продажами по 100 рублей, то оба будут иметь ранг 1, а следующий 3. То есть будет 1, 1, 3.

➖ DENSE_RANK() — как RANK, но без пропусков. Дубли получают один ранг, а следующий идёт подряд.

Например, нам нужно определить ранг по датам продаж:

SELECT id, product, date, DENSE_RANK() OVER (ORDER BY date) AS dense_rank FROM sales;

Результат: если у вас 2 ранга выпали на одну дату, то оба будут равны 1, следующий 2 (не 3). То есть будет 1, 1, 2.

2️⃣ BETWEEN
Оператор BETWEEN проверяет, входит ли значение в диапазон. Он применяется для фильтрации дат, чисел, строк:

WHERE date BETWEEN '2023-01-01' AND '2023-12-31'

Например, нам нужно собрать продажи в диапазоне сумм:

SELECT * FROM sales
WHERE amount BETWEEN 50 AND 100;

Результат будет включать и 50, и 100, и все что между ними.

Частые ошибки:
➖ BETWEEN включает оба значения. Если вам не нужно включать оба из них или одно из них, то используйте > и/или <.
➖ Особенности работы с датами и временем. Если данные в витрине указаны с временем (‘2023-01-01 00:00:00’), может between ‘2023-01-01’ пропустить их. Используйте TRUNC(date) или >= AND <.

Надеюсь, что теперь вы знаете, чем отличаются эти функции и когда и как их применять. Ставьте 🔥, если было полезно!

📈 Симулейтив | ВК | YouTube