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

Мастер-класс по SQL уже через 1,5 часа

Вместе с Евгением Буториным, ментором курса «Аналитик данных», мы решим несколько задач по SQL и выполним полноценное ТЗ от клиента. Не пропустите вебинар в 19:00 МСК!

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

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

По многочисленным просьбам — повторяем мастер-класс по SQL

Мы получили огромное количество положительной обратной связи. Прикрепляем комментарии! Спасибо вам 🧡

Мы редко проводим такое, но в этот раз решили сделать повтор вебинара и дать шанс тем, кто очень хотел прийти, но не получилось. 

Напоминаем, что вас ждёт: 
— Разберём SQL как главный инструмент аналитика;
— Решаем задачи по SQL и реальные задачи бизнеса.

❗️ Встречаемся вновь сегодня 8 апреля в 13:00 и 19:00 МСК.

➡️ Прямая ссылка на комнату

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

Как я убрал рутину из ежемесячных отчётов навсегда: Power Pivot + меры в DAX

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

За 5 лет в аналитике я устал от одной и той же боли: обновление отчётов руками. Да, данные в отчёт проливались через Power Query автоматически (через кнопку «Обновить всё»), но метрики были нестандартные.

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

Теперь обновление отчёта занимает 2 минуты: нажимаю «Обновить всё» — и всё готово. Для этого я загрузил данные из Power Query в модель данных и написал меры, которые позволяют «на лету» считать все нужные вычисления.

Вот как это работает:
➖ Загружаешь сырые данные в модель через Power Query или напрямую в модель Power Pivot;
➖ Пишешь меры на DAX (один раз и навсегда);
➖ Строишь график/сводную таблицу — и больше никогда её не трогаешь.

Пример реальной меры, которую я использую — дельта конверсий (в %):

Delta Conv MoM = 

VAR GKG = 
DIVIDE(CALCULATE(sum(query[sales]), ggroup = “ГКГ”), CALCULATE(sum(query[cnt_cl]), ggroup = “ГКГ”))

VAR CG =
DIVIDE(CALCULATE(sum(query[sales]), ggroup = “ЦГ”), CALCULATE(sum(query[cnt_cl]), ggroup = “ЦГ”))

RETURN

CG - GKG

После этого график «Дельта конверсий» живёт своей жизнью — самостоятельно обновляется и пересчитывается в зависимости от выбранных фильтров.

Конечно, это не единственная мера, но потратить на написание мер 30 минут однократно и сэкономить при этом часы на рутинной работе стоит каждой потраченной минуты.

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

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

Забирайте модуль по Excel при покупке курса!

Друзья, мы запустили акцию: покупаете любой курс-профессию → получаете наш полноценный модуль по Excel.

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

📌 Акция действует до 15 апреля включительно на платные курсы Симулейтив (кроме тренингов и магистратуры).

Ваш Excel-бонус уже скучает, успевайте забрать 😉

👉 Оставить заявку

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

Одна строчка в SQL, которая экономит время при каждом обновлении отчёта

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

Раньше, когда нужно было обновить отчёт за последний месяц, я либо тянул ВЕСЬ период данных (гигантский объём), либо вручную правил даты в 20 разных местах запроса.

Оба варианта — боль 😥

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

Как это выглядит:

DECLARE @StartDate DATE = add_months(trunc(sysdate,’mm’),-2);
DECLARE @EndDate   DATE = last_day(trunc(sysdate));

DELETE FROM table WHERE Date BETWEEN @StartDate AND @EndDate;

COMMIT;

INSERT INTO table 

SELECT 
    Channel,
    COUNT(*) AS Leads,
    SUM(CASE WHEN Status = 'Купил' THEN 1 ELSE 0 END) AS Sales,
    SUM(CASE WHEN Status = 'Купил' THEN 1 ELSE 0 END) * 1.0 / COUNT(*) AS ConvRate
FROM MarketingLeads
WHERE Date BETWEEN @StartDate AND @EndDate
GROUP BY Channel;

COMMIT;

Всё. Хочу пересчитать апрель 2024 года — меняю переменные на две даты в начале процедуры и запускаю запрос заново. Никаких правок в 20 местах. При этом другие периоды не меняются, что исключает эффект «плавающих данных».

Возможно это выглядит сложно, но на деле мы не становимся сразу сеньорами (старшими аналитиками), мы учимся постоянно и дорабатываем свои скрипты.

➡️ Записаться на поток с моим менторством (стартуем сегодня!): simulative.ru/data-analyst

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

😁😆😁 опубликовать анонс вебинара по дата сайенс, 13 апреля 19:00 МСК, спикер Мария Жарова. Вебинар про профессию дата-сайентиста с практикой.

Ссылка на регистрацию https://bothelp.cc/mini?domain=simulative&id=29&utm_source=telegram&utm_medium=social&utm_campaign=webinar&utm_content=10-04-2026-web-1304

👍👍👍👍

Вебинар: всё, что нужно знать о профессии дата-сайентиста

Data Scientist — одна из самых востребованных профессий в аналитике, но вокруг неё до сих пор много путаницы: чем она отличается от машинного и глубокого обучения? Когда одной аналитики недостаточно? И что реально нужно уметь, чтобы получить первую работу?

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

На вебинаре расскажем:
➖ Кто такой дата-сайентист и как различать аббревиатуры DS, ML, DL и AI;
➖ Откуда спрос на эту профессию и какие задачи решают DS в бизнесе;
➖ Какие требования предъявляют к джуну;
➖ Построим модели прогнозирования оттока клиентов банка, сравним подходы по метрикам и интерпретируемости, разберём ключевые факторы оттока.

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

💬 Подключайтесь к эфиру, чтобы задать Марии вопросы про карьеру в Data Science, машинное обучение и практические кейсы.

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

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

Почему t-test — это всё, что вам нужно в A/B-тестах

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

В аналитическом сообществе есть негласная иерархия: чем сложнее метод, тем умнее выглядит аналитик. Bootstrap, тест Манна-Уитни, CUPED, байесовские подходы — всё это звучит внушительно на собеседованиях и в статьях на Хабре.

Но на практике в 80% случаев достаточно обычного t-теста.

Что такое t-test и как он работает

T-test проверяет одну простую гипотезу: отличаются ли средние значения метрики в двух группах или нет. Формально он считает t-статистику:

t = (x̄₁ - x̄₂) / √(s₁²/n₁ + s₂²/n₂),
где x̄ — среднее в группе, s² — дисперсия, n — размер выборки.

Дальше по этой статистике считается p-value — вероятность получить такой же или более экстремальный результат при условии, что никакого эффекта нет.

Если p-value < 0.05, эффект считается статистически значимым.

Почему часто всё усложняют

Главный аргумент против t-теста звучит так: «Данные не распределены нормально, значит t-test некорректен». Но на самом деле это не так.

T-test опирается не на нормальность исходных данных, а на нормальность распределения выборочного среднего.

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

На практике при выборке от 1000 наблюдений на группу это условие выполняется почти всегда. А в большинстве продуктовых A/B-тестов выборки именно такого размера или больше.

Однако не стоит пихать t-test во все возможные эксперименты. Иногда он может и не подойти.

Когда t-test действительно не подходит

T-test работает плохо в нескольких ситуациях:

➖ Очень маленькие выборки (до 30 наблюдений на группу). В этом случае ЦПТ ещё не работает в полную силу.

➖ Метрика с экстремальными выбросами — например, выручка, где один крупный платёж может сильно сдвинуть среднее. В таком случае имеет смысл либо сглаживать выбросы и перепроверять результаты тестом Манна-Уитни.

➖ Бинарные метрики с очень низкой конверсией — в этом случае лучше работает z-test для пропорций, хотя при больших выборках разница минимальна.

Во всех остальных случаях t-test справляется.

Зачем тогда все эти сложные методы?

Они решают конкретные задачи — и только их. CUPED снижает дисперсию и позволяет быстрее набрать нужную выборку. Bootstrap помогает строить доверительные интервалы для нестандартных метрик. Линеаризация помогает работать с Ratio-метриками.

Это полезные инструменты. Но они не отменяют t-test, а дополняют его в нестандартных случаях. Браться за них только потому, что «так серьёзнее» — это усложнение ради усложнения. А усложнение ради усложнения в аналитике стоит дорого: дольше согласование, сложнее объяснить бизнесу, выше риск ошибки в реализации.

Простой инструмент, применённый правильно, лучше сложного, применённого без понимания.

➡️ Записаться на курс по A/B-тестам: simulative.ru/ab-test

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