Присоединяйтесь сегодня к вебинару по использованию ИИ

В 19:00 МСК вместе с Мариной Ермак разбираем бизнес-кейс и решаем задачу с помощью нейросетей — от туманной формулировки и построения гипотез до их проверки и визуализации метрик. Все материалы вы сможете повторить в прямом эфире, ждём вас!

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

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

Пройдите опрос и получите подарок!

Мы хотим лучше узнать нашу аудиторию, чтобы делать наш продукт и контент ещё полезнее. Заполните небольшой опрос (займёт не более 5 минут) и получите полезный материал в подарок.

✍🏻 Пройти опрос

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

Запустили Telegram-канал про Data Science и машинное обучение

В нём практикующие ML/DL-инженеры рассказывают доступным языком про прод, пайплайны, метрики, ошибки, фичи, архитектуры и реальные бизнес-кейсы.

В канале вы найдёте:
➡️ Разборы ключевых концепций и подходов в ML/DL на языке инженера;
➡️ Кейсы из продакшена: что сработало, что сломалось, какие выводы сделали;
➡️ Факапы, которые помогут не наступать на те же грабли;
➡️ Карьерные маршруты: какие скиллы нужны ML/DL-инженеру и как их системно прокачивать.

Кому будет полезно:
➖ Действующим ML/DL-инженерам и дата-сайентистам, которые хотят глубже в архитектуры, прод и инженерные практики;
➖ Начинающим ML‑инженерам и DS, которые ищут понятные ориентиры, реальные кейсы и честный взгляд на профессию;
➖ Аналитикам и дата-инженерам, планирующим переход в ML/DL и не желающим тонуть в разрозненных материалах.

Если вы хотите расти как инженер и собирать работающие ML/DL‑системы — присоединяйтесь!

✅ Подписаться

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

Новый курс: Data Scientist с нуля до профи

Data Scienсe — это самая высокооплачиваемая сфера в IT: симбиоз навыков из аналитики и инженерии данных, машинного и глубокого обучения. Таких специалистов немного, и на рынке они очень ценятся. Теперь вы можете стать одним из них!

Мы объединили опыт практикующих экспертов, чтобы за 8 месяцев вы:

➖ Освоили полный стек инструментов аналитики и инженерии данных: от SQL, Python и Pandas до Docker, Airflow и ETL-пайплайнов;
➖ Погрузились в мир ML и DL: от регрессии, кластеризации и рекомендательных систем до архитектур нейронных сетей, обработки текста (NLP) и компьютерного зрения (в продвинутом тарифе);
➖ Решили реальные бизнес-кейсы: только практика от действующих аналитиков, которая ляжет в ваше портфолио.

Кому подойдёт курс:

👨‍💻 Новичкам в профессии: с нуля получите востребованную специальность и полный набор навыков для уверенного старта с зарплатой 90 000 — 170 000 ₽ на начальных позициях.
👨‍💻 Аналитикам с опытом: углубитесь в машинное обучение и глубокое обучение нейросетей, сможете прокачаться на текущем месте или перейти на позицию Data Scientist (специалиста по данным), вырастете в доходе.
👨‍💻 Специалистам смежных сфер: научитесь работать с данными, чтобы принимать обоснованные решения, и сможете перейти на позицию Data Scientist (специалиста по данным).

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

👉 Записаться на поток со скидкой 30%: simulative.ru/data-scientist

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

Вебинар: почему 80% новичков в IT выбирают именно аналитику данных

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

На вебинаре с Павлом Беляевым, тимлидом группы дата-аналитиков в Яндекс eLama, разберём, составим понятный план старта в профессии, а также потренируемся в решении тестовых заданий.

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

О чём расскажем на вебинаре:
➖ Почему аналитика — самый понятный вход в IT;
➖ Какие навыки реально нужны, и что не нужно учить;
➖ Сколько зарабатывают начинающие аналитики;
➖ Как выйти на первую работу без опыта;
➖ Реальный путь входа в профессию.

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

💬 Если вы хотите сменить профессию, устали от текущей работы или просто ищете стабильный доход — приходите на вебинар!

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

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

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

Я познакомился с A/B-тестами в теории в 2015-2016 году, а серьёзную практику получил в маркетинговой аналитике Яндекса: мы тестировали гипотезы по водителям, клиентам и тарифам. Именно этот опыт — первый взгляд на практическую сторону работы с гипотезами — дал понимание, что можно не просто тестировать, а выстроить data-driven систему на основе гипотез и тестов.

Это понимание я переиспользовал в X5, где систематизация работы с экспериментами дала огромные плоды: выросли и качество, и скорость работы. Мы создали методологию и внутренний инструмент, через который проходило большинство тестов компании.

В МТС идея инструмента превратилась в open-source библиотеку Ambrosia, которой в настоящее время пользуется большое количество людей из разных компаний.

Курс — логическое продолжение этого пути: передать не просто инструмент, а мышление, которое за ним стоит. Жду вас на курсе, где мы пройдём весь путь от гипотезы до внедрения экспериментов с понятными и эффективными метриками.

👉 Забронировать место: simulative.ru/ab-test

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

Глобальные контрольные группы

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

У аналитиков время от времени просят оценить эффект всех запущенных фич за год. Может показаться, что если сложить аплифты всех успешных A/B-тестов, то мы как раз и получим искомый результат.

На самом деле нет.

Проблема в том, что мы привыкли оценивать эффекты изолированно — для каждой отдельной фичи в рамках каждого конкретного эксперимента. Но мы забываем про совокупный эффект (Cumulative Effect) и взаимодействие изменений.

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

Чтобы понять, как все наши изменения в сумме влияют на пользователя на длинной дистанции, обычного A/B-теста недостаточно. Нам нужна глобальная контрольная группа (ГКГ/ГЦГ).

ГКГ (global holdout group) — это сегмент пользователей, который изолируется от всех (или большинства) изменений и маркетинговых коммуникаций на длительный срок.

Если в классическом тесте мы держим контроль 2 недели, то ГКГ живет 3, 6 или 12 месяцев. Это наша «тихая гавань» в шторме релизов.

Как это работает на практике?

Механика внедрения обычно делится на два типа, у каждого свои плюсы и минусы.

🏘 Тип 1. Статическая ГКГ (Static Holdout)

Вы просто отрезаете кусок аудитории (например, 5% по User ID) и «замораживаете» их навсегда.

➕ Плюс: идеально чистые данные для расчета LTV — вы точно знаете историю каждого пользователя.

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

🎢 Тип 2. Ротируемая ГКГ (Rolling Holdout)

Пользователи попадают в контроль на фиксированное время (например, на 90 дней), а затем возвращаются в общую массу, заменяясь новыми.

➕ Плюс: выборка всегда свежая, нет смещения (bias).

➖ Минус: сложнее математика. Вы не можете оценить эффекты длиннее окна ротации.

Главное ограничение использования ГКГ: «Мы теряем деньги!»

Внедрение ГКГ — это всегда битва с заказчиками. Маркетинг кричит: «Если мы не отправим промокоды этим 5% людей, мы недополучим миллионы выручки!».

Здесь важно объяснить два момента:
🟠 Мы не теряем, мы инвестируем в знание.
🟠 Без ГКГ мы летим вслепую. Мы можем тратить бюджет на SMS, которые не приносят инкрементальной выручки. Стоимость ГКГ — это плата за то, чтобы не сжигать бюджет впустую на остальной базе.

Эффект может быть обратным. Бывают кейсы, когда глобальная контрольная группа показывает LTV выше, чем основная база. Это значит, что ваши коммуникации настолько назойливы, что вы не зарабатываете, а теряете деньги на маркетинге. Без ГКГ вы бы никогда об этом не узнали.

Резюмирую: если ваш продукт предполагает длительные отношения с клиентом (подписка, банкинг, e-commerce, телеком) — локальных тестов мало. Локальный тест отвечает на вопрос: «Как эта кнопка влияет на клики сегодня?» ГКГ отвечает на вопрос: «Становится ли наш бизнес здоровее от всего, что мы делаем?».

Ставьте реакции, если было полезно!

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

A/B-тест в коммуникациях: реальный кейс, результаты и главная ошибка, которую мы недооценили

Привет, коллеги! На связи Евгений Буторин, руководитель CRM-аналитики в Альфа Банке 👋🏻

Делюсь свежим (и поучительным) кейсом из нашей практики по A/B-тестам. Мы тестировали изменения в push + email-цепочке, чтобы поднять пост-коммуникационную активность клиентов.

😶 Что тестировали

Гипотеза: новая версия сообщения (более персонализированный текст + эмодзи + вечерний тайминг) даст больший прирост (lift) в активности или активации клиентов, чем старая.

➖ Группа A (контроль): старая коммуникация
➖ Группа B (тест): новая версия

Метрики:
➖ Активность клиента в Т0 — активность в месяце отправки коммуникации;
➖ Активность клиента в Т1 — активность клиента на следующий месяц после отправки коммуникации.

😶 Выборка и дизайн

Целевая база: 100 тысяч клиентов. Группы стратифицировали по активности, сегменту, времени жизни клиента, тарифу и каналу привлечения.

Период проведения: 1 месяц проведения + 1 месяц вызревания.

😶 Результаты на первый взгляд

Группа B показала рост активности на 11% в Т0 и на 7% в Т1. На первый взгляд мы решили, что пилот успешен, пока не сравнили профили клиентов по сторонним коммуникациям.

😶 Главная ошибка

При стратификации мы не учли параллельные коммуникации вне этого пилота. Даже при том, что на A/B-группы по этому тесту коммуникации были строго разделены, клиенты продолжали получать триггерные рассылки, другие промо, емейлы и SMS от параллельных кампаний, win-back и сервисные рассылки.

В итоге в группах A и B оказалась разная «загрязнённость» дополнительными касаниями: в B случайно попало на 15–20% больше параллельных коммуникаций, чем в A. Это создало искажённое представление об успешности пилота — часть lift’а мы приписали нашей новой версии, хотя на деле был эффект синергии (или каннибализации) от других каналов.

Как исправляли постфактум:
🟠 Собрали полную историю всех коммуникаций (1 месяц от запуска пилота) по каждому клиенту;
🟠 Ввели новую стратификационную переменную «communication load» с типом и количеством касаний;
🟠 Перестратифицировали обе группы заново, создав чистые эквивалентные группы;
🟠 Заново пересчитали эффекты от пилота: реальный эффект нашей коммуникации упал до +4% в Т0 и +1% в Т1.

Положительный результат пилота сохранился, но значения значительно снизились.

😶 Что теперь делаем обязательно

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

Хотите строить эффективные тесты и избегать ошибок? Записывайтесь на курс по A/B-тестированию, где под руководством опытного специалиста вы начнёте проводить эксперименты, которые покажут вам реальные выводы и приведут к выгодным решениям!

📈 Записаться на курс: simulative.ru/ab-test

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

Присоединяйтесь к решению тестовых заданий сегодня в 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