Присоединяйтесь к решению тестовых заданий сегодня в 19:00

Павел Беляев ждёт вас на вебинаре! На примере тестового задания из Magnit Tech мы потренируемся работать со списками товаров и заказов, особенно актуальными для e-commerce.

Мы попрактикуемся:
🟠 Фильтровать выборку разными видами условий;
🟠 С помощью оконной функции выбирать текущее состояние товара в исторических данных;
🟠 А также увидим, как использовать JOIN-объединение таблиц в качестве фильтра.

➡️ Зарегистрироваться на вебинар

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

4 реальных кейса применения оконных функций

Всем привет! Я Павел Беляев, ментор курса «Аналитик данных» и ведущий канала Тимлидское об аналитике 👋🏻

Хочу показать несколько примеров применения оконок из реальной практики аналитиков Яндекс eLama.

1️⃣ Последняя запись в исторических данных

Если имеем дело с таблицей, которая обновляется не перезаписью с нуля, а добавлением новых строк для объектов, которые изменились, вот как можно взять последнюю строку:

SELECT *
FROM
(
    SELECT *
        MAX(updated_at) OVER (PARTITION BY payment_id) AS last_update
    FROM payment
)
WHERE updated_at = last_update

Здесь payment — таблица, содержащая транзакции пользователя. Одна строка отражает состояние транзакции на момент добавления строки, т. е. на дату updated_at. Каждая транзакция имеет уникальный идентификатор payment_id, но он не уникален в рамках всей таблицы.

2️⃣ Топовые юзеры

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

SELECT *
FROM
(
   SELECT d, w, user_id, revenue,
      ROW_NUMBER() OVER (PARTITION BY d ORDER BY revenue DESC) AS rn  -- нумеруем юзеров в порядке убывания их оборота
   FROM
   (
      SELECT DATE(date_paid) AS d, 
        dateName('weekday', date_payed) AS w,
        user_id, 
        SUM(revenue) AS revenue
      FROM datamart.financial_activity
      GROUP BY 1,2,3
   )
)
WHERE rn<=15 -- Количество топовых юзеров за каждый день
   AND w='Wednesday' -- День недели. Часто пользователи активничают ритмично, например по средам.
ORDER BY d DESC, revenue DESC

3️⃣ Lifetime value

LTV часто выбирают как главную метрику компании (North Star Metric). Оконкой можно вывести LTV юзера на каждый момент времени — например, когда он совершает очередной платеж.

SELECT user_id, date_paid, 
  turnover,
  SUM(turnover) OVER (PARTITION BY user_id ORDER BY date_paid) AS LTV
FROM datamart.money
ORDER BY date_paid DESC

Заметим, что при такой записи выводится LTV на момент date_paid, а не текущий LTV. Так что можно следить за скоростью его роста.

4️⃣ Скользящее среднее

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

Тогда в течение месяца мы её ещё не знаем. Простой прогноз можно состряпать как скользящее среднее за предыдущие месяцы.

В ClickHouse прошлые значения выводит функция lagInFrame():

SELECT period, SUM(act_amount) am,
  lagInFrame(am,1,0) OVER (ORDER BY period ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS am1,
  lagInFrame(am,2,0) OVER (ORDER BY period ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS am2,
  lagInFrame(am,3,0) OVER (ORDER BY period ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS am3,
  (am1 + am2 + am3)/3 AS am_avg,
FROM   datamart.money
GROUP BY ALL

Ставьте огоньки, если пригодится в работе!

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

Вебинар: почему компаниям больше не нужны «узкие» специалисты

Ещё недавно компании нанимали отдельно аналитиков данных, специалистов по визуализации и дата-инженеров. Сегодня бизнесу нужен человек, который может закрыть задачу от запроса до внедрения — без передачи по цепочке и потери контекста.

На вебинаре с Ильей Ковалёвым, старшим аналитиком данных в Dodo Brands и автором канала кусочек пиццы, разберём, почему fullstack-подход становится стандартом, какие задачи теперь решает один специалист вместо трёх и за что на самом деле платят деньги в аналитике.

➡️ Зарегистрироваться на вебинар

На вебинаре расскажем:
➖ Как выросли требования к аналитикам;
➖ Почему бизнес ищет специалиста, который понимает данные, умеет общаться с заказчиком и сам собирает решение;
➖ Реальные примеры задач, которые раньше делали три человека, а теперь делает один;
➖ Главные ошибки новичков: уход только в SQL/Python, непонимание бизнес-задач и страх ответственности.

❗️ Встречаемся 31 марта в 19:00 МСК

💬 Подключайтесь к эфиру, чтобы задать Илье вопросы про fullstack-аналитику, карьерные траектории и переход от узких ролей к комплексным задачам.

➡️ Зарегистрироваться на вебинар

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

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