Симулейтив

Репрезентативность: когда выборка «говорит правду»

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

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

Репрезентативность — это соответствие выборки генеральной совокупности по ключевым характеристикам. Без неё даже самый тщательный анализ приведёт к ошибочным выводам.

✅ Как это измеряют?

Репрезентативность оценивают стандартизованной разностью d между выборкой и генеральной совокупностью по ключевым признакам:

➖ d < 0,1 — отличная репрезентативность;
➖ d 0,1–0,2 — хорошая;
➖ d 0,2–0,5 — умеренная;
➖ d ≥ 0,5 — плохая, выборке доверять нельзя.

✅ Как обеспечить репрезентативность?

➖ Стратифицированная рандомизация. Делим пользователей на страты — по возрасту, географии, каналу — и рандомизируем внутри каждой страты. Это гарантирует, что обе группы сбалансированы, а не просто «в среднем похожи».

➖ Мониторинг баланса. После запуска теста проверяем, что группы A и B не отличаются по ключевым характеристикам. Доля мобильного трафика 60% в группе A и 45% в группе B — уже повод остановиться и разобраться, а не запускать анализ дальше.

➖ AA-тестирование. Перед реальным тестом запускаем «пустой» тест, где обе группы получают одинаковый опыт. Если находим статистически значимые различия там, где их не должно быть — проблема не в продукте, а в системе рандомизации.

Однажды мы обнаружили, что алгоритм рандомизации крупного маркетплейса систематически направлял новых пользователей в тестовую группу. Новые пользователи конвертировались хуже просто потому, что ещё не знали сайт — и тест показывал «ухудшение», хотя изменение было нейтральным. AA-тест длительностью в одну неделю поймал бы эту проблему ещё до запуска, а не после недели неверных выводов.

⭐️ Именно поэтому на курсе «A/B-тестирование» мы начинаем не с формул значимости, а с проверки самой выборки: стратификация, мониторинг баланса, AA-тесты как обязательный шаг перед любым реальным экспериментом. Программу веду я сам на основе методологии, которую строил в X5, Wildberries и МТС (open-source библиотека Ambrosia).

⭐️ Посмотреть программу курса

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

«ON CONFLICT DO UPDATE command cannot affect row a second time»: как мы теряли данные из-за этой ошибки

Привет! На связи Валерия Елпатьевская, ментор курса «Инженер данных» 👋🏻

Сегодня расскажу о том, с чем недавно сама столкнулась. Ситуация: мы потеряли часть данных, смотрим логи, а там:

ERROR: ON CONFLICT DO UPDATE command cannot affect row a second time

Какой же second time? Как вообще такое возможно? Так вот рассказываю.

Если вы делаете `INSERT ... ON CONFLICT DO UPDATE` большими батчами (пакетами данных), дедуплицируйте входные данные до `UPSERT`.

Допустим, в батче пришли две записи с одним id:

INSERT INTO users (id, updated_at, name)
SELECT id, updated_at, name
FROM staging
ON CONFLICT (id) DO UPDATE
SET
    updated_at = EXCLUDED.updated_at,
    name = EXCLUDED.name;

Если staging содержит несколько строк с одинаковым id, PostgreSQL завершит такую операцию ошибкой, как выше.

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

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

Поэтому перед UPSERT лучше явно определить правило разрешения конфликта и избавиться от дубликатов:

WITH ranked AS (
    SELECT
        *,
        ROW_NUMBER() OVER (
            PARTITION BY id
            ORDER BY updated_at DESC
        ) AS rn
    FROM staging
)
INSERT INTO users (id, updated_at, name)
SELECT id, updated_at, name
FROM ranked
WHERE rn = 1
ON CONFLICT (id) DO UPDATE
SET
    updated_at = EXCLUDED.updated_at,
    name = EXCLUDED.name;

Теперь для каждого id в батче остаётся ровно одна запись — например, самая свежая по updated_at.

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

Ставьте 🔥 и пересылайте тем, кто мог бы столкнуться с этой проблемой ❤️

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

💻 Сценарии использования NULLIF

Вас когда-нибудь спрашивали на собеседовании о функции NULLIF?

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

✅ Что такое NULLIF и как это использовать?

NULLIF — это функция, которая принимает два аргумента и возвращает NULL, если аргументы равны, в противном случае она возвращает первый аргумент. Синтаксис выглядит следующим образом:

NULLIF(выражение 1, выражение 2)

💻 Деление на ноль

Пожалуй, самое полезное, что можно сделать, используя NULLIF — пресечь ошибку деления на ноль.

Это один из самых распространённых вариантов использования. Например, если вы пытаетесь поделить один столбец на другой, и есть вероятность, что во втором столбце (делителе) могут оказаться нули — оберните второй столбец в NULLIF и вы не получите ошибок.

SELECT column1/NULLIF(column2, 0)
FROM table1

То есть когда значение второго столбца равно 0 (аргументы в NULLIF равны), вернется NULL, а не ZeroDivisionError.

💻 Поиск среднего значения

Такая схема будет полезна и при других вычислениях, например среднего значения. Опять же, если есть шанс, что в столбце, по которому считаем среднее, могут оказаться нули, которые не должны влиять на результат — поможет NULLIF.

Например, дана такая таблица:

| column1 | column2 |
|---------|---------|
| 0       | a       |
| 7       | a       |

Выполнив:

SELECT column2, AVG(column1)
FROM table1
GROUP BY column2;

Получим:

| column2 | avg |
|---------|-----|
| a       | 3.5 |

А с использованием NULLIF получим другой результат:

SELECT column2, AVG(NULLIF(column1, 0))
FROM table1
GROUP BY column2;

| column2 | avg |
|---------|-----|
| a       | 7   |

💻 Преобразование пустых строк

Другой вариант использования NULLIF — преобразование пустых строк в NULL. Например, в таблице некоторые столбцы содержат пустые строки, которые необходимо трактовать как NULL — идеально подходящая ситуация для NULLIF:

SELECT NULLIF(column1, '') FROM table1;

Получим NULL, если столбец 1 содержит пустую строку, что эффективно обработает все пустые строки.

💡 В следующий раз, когда вы будете работать над проектом, попробуйте найти, где бы вы могли использовать NULLIF и убедитесь, как он легко поможет решать сложные задачи и избегать больших CASE/WHEN конструкций. Кстати говоря, NULLIF — это тот же CASE/WHEN, так что, возможно, стоит провести ревизию старых проектов и увидеть потенциальные «use» кейсы.

Если вы и раньше использовали NULLIF, расскажите, в каких интересных задачах он вам пригодился? И ставьте 🔥, если было полезно!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

Растим в себе сильного джуна 💪🏻

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

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

На канале «Модель предскажет» я рассказала, что реально ценят в команде — не «уметь бустинг руками написать», а гораздо более приземлённые вещи. Именно они отличают джуна, которого через полгода зовут на новые задачи, от того, за кем приходится всё переделывать.

📌 Читать пост: https://t.me/modprod/68

Сохраняйте, чтобы не потерять!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

Булевы флаги через ::int: один трюк, шесть применений

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

В учебниках мы часто видим, как условную логику реализуют через CASE WHEN ... THEN 1 ELSE 0 END. В боевых запросах то же пишут короче: условие в скобках и приведение к числу. В PostgreSQL любое сравнение это булево значение, а TRUE::int = 1, FALSE::int = 0:

(status = 'active')::int AS is_active,
((age > 18) AND (verified = true))::int AS is_adult_verified

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

💡 Флаг существования после LEFT JOIN

После LEFT JOIN непарные строки получают NULL в колонках правой таблицы. Проверка на NULL, свёрнутая во флаг, отвечает на вопрос «есть ли связанная запись»:

(o.order_id IS NOT NULL)::int AS has_order

Дальше has_order работает и как фильтр, и как метрика: «сколько клиентов с заказом» — просто SUM(has_order).

💡 SUM(флаг) — счётчик, AVG(флаг) — доля

Раз флаг — это 0 или 1, агрегаты читаются напрямую:

SUM(is_active)              -- сколько активных строк
AVG(is_active)              -- доля активных (готовый процент)
COUNT(*) - SUM(has_order)   -- сколько клиентов без заказа

Один проход по таблице вместо трёх запросов с разными WHERE.

💡 MAX(флаг) по группе — «случалось ли хоть раз»

Если внутри группы флаг хоть в одной строке равен 1, то MAX по группе тоже даст 1. То есть MAX(флаг) отвечает на вопрос «было ли такое хотя бы раз»:

SELECT
    user_id,
    MAX((amount > 1000)::int) AS had_big_purchase
FROM orders
GROUP BY user_id

Читается так: «у пользователя был хотя бы один заказ дороже 1000». Без трюка пришлось бы писать самоджойн или коррелированный подзапрос.

Симметрично работает MIN(флаг) = 1 — «условие выполнилось во всех строках группы».

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

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

🤖 Как я использую ИИ?

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

Сегодня я расскажу, как я использую ИИ в работе.

🧠 Еженедельный отчёт
Раньше требовался час, чтобы перебрать Jira руками и перечитать чаты. Теперь агент сам вытаскивает закрытые за неделю тикеты, ходит в Slack, группирует по направлениям, пишет по строке результата на каждый. Я правлю пару строк и публикую. Работает только потому, что для агента написал инструкцию (скилл) + досконально ведём описание задача в Jira.

🧠 Тикеты из встреч
Обычная история — обсудили что-то на встрече, но после никто не завёл задачу/не написал постмит. Сейчас все встречи транскрибируются, агент по записи собирает черновик задачи по шаблону. Человек проверяет и подтверждает.

🧠 Ревью своего ресёрча
Закончил анализ — отдаю агенту: проверить логику, найти места, где данные не тянут вывод. Один такой прогон вскрывает дыры до того, как их увидели стейкхолдеры. Глаз может «замылиться», и свои ошибки в своём ноутбуке не увидишь, а агент видит.

🧠 Продакшн-разработка
Не пет-проекты, а боевые репозитории: SQL и дата-сорсы для Tableau, даги в Airflow. Агент пишет код по тикету, гоняет тесты, проходит CI и ревью на общих основаниях. Доходит до забавного, в истории коммитов в Git уже порой не отличишь, где человек, а где агент. Секрет не в модели: в каждом репозитории лежит файл с правилами/скиллами — стайлгайд SQL, конвенции проекта, как деплоить, как тестировать, какая схема данных и т. д. и т. п. Агент читает всё это в начале сессии и пишет так, как принято у нас.

Ну и конечно, есть разного по мелочи — почитать Confluence, поискать в интернете, собрать google sheet и т. д. и т. п.

А как вы используете ИИ? 🙂

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

VAR — математическая взаимосвязь рядов

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

Анализировать один временной ряд — это хорошо, а два и более — лучше!

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

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

Вот тут на сцену выходит VAR — Vector AutoRegression, векторная авторегрессия.

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

Что это даёт на практике:
➖ Совместный прогноз сразу нескольких метрик с учётом их взаимного влияния.
➖ Причинность по Грейнджеру — можем формально проверить, помогает ли история одного ряда предсказывать другой.
➖ Impulse Response Functions — можно смоделировать «шок» в одной переменной и посмотреть, как он расходится по системе во времени. А подсказывает нам, как изменится зависимая, неуправляемая метрика, если мы "подтолкнем" управляемую.

📈 В этом блокноте показано, как выглядит работа с VAR. На выходе мы имеем коэффициенты системы линейных уравнений, где количество уравнений равно количеству метрик в многомерном ряду, а число членов — это число значимых лагов, то есть, предыдущих значений в каждом ряду.

Эти коэффициенты, по сути, объясняют, какой лаг какой метрики влияет на всю систему.

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

Хотите научиться видеть не отдельные ряды, а целые системы взаимосвязанных процессов? Присоединяйтесь к курсу «Временные ряды», который стартует уже в субботу, 15 августа:

📌 Узнать больше о курсе «Временные ряды»
📌 Подписаться на бота уведомлений

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

Зачем нужна декомпозиция и фильтрация временных рядов?

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

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

Почему же дата-аналитик мгновенно производит эту процедуру в уме?

Потому что компоненты ряда — тренд, сезонность, всплески, не календарная цикличность — дают ответы на основные вопросы аналитики.

Как себя ведет метрика? Растёт в целом? А это не просто сезонный осенний подъём? Этой осенью лучше, чем прошлой осенью?

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

Например, вот я пришел в новую компанию на должность аналитика, меня пускают к данным о продажах. Конечно, я захочу узнать, какова структура спроса — в какие месяцы имеет место рост, а в какие спад. То же насчёт внутринедельной сезонности.

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

Кроме полезных компонентов чаще всего есть в данных и случайная составляющая — шум. Желательно её как-то сгладить, отфильтровать так, чтобы не потерять ценных данных.

Вокруг интереса к теме декомпозиции и фильтрации временных рядов умные люди создали целый подраздел науки — методы, математический аппарат и, конечно, функции на питоне.

💡 Кстати, самый простой способ декомпозировать временной ряд — применить функцию seasonal_decompose(). На вход она получает сам ряд, его модель (аддитивная или мультипликативная) и предполагаемый период сезонности. На выходе получаем расклад по компонентам, который легко визуализируется.

📈 Загляните в этот демонстрационный блокнот, ведь лучше увидеть код и графики, чем читать текст, правда?

Эта функция проста в применении, но не очень аккуратна. На курсе мы внимательно рассматриваем более продвинутые методы и алгоритмы с разбором на питоне. Такой арсенал позволяет делать уже серьёзную аналитику сложных «естественных» рядов, максимально точно разделяя их на компоненты.

📌 Узнать больше о курсе «Временные ряды»
📌 Подписаться на бота

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS