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

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

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

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

Примеры буду показывать на 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 | 📱 Канал о DS

5 навыков фуллстек-аналитика

Привет всем! Я Павел Беляев, ментор курса «Fullstack-аналитик» и автор канала Тимлидское об аналитике 👋🏻

Итак, мы осознали, что глобальная задача фуллстека — проводить данные по всему конвейеру:

Сбор — Обработка — Визуализация — Анализ

Каков минимальный набор навыков для такой работы? Давайте разберёмся.

1️⃣ Бизнес-анализ: перевод с «менеджерского» на технический язык данных (и обратно)

Заказчик не говорит: «Построй мне витрину данных». Он говорит: «У нас падают продажи, почему?».

📌 Что нужно уметь: разбираться в основных бизнес-процессах, понимать воронки, юнит-экономику и ловко применять метрики (LTV, CAC, Retention, ROI и т. д.).

Курс по фуллстеку начинается с модуля «Продуктовые метрики и методы аналитики», который раскрывает суть бизнес-анализа: что анализировать, зачем и как.

2️⃣ Data Analytics: подготовка данных

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

📌 Что нужно уметь: SQL. Не просто SELECT/FROM, а уверенное владение JOIN, группировками, подзапросами и оконными функциями. SQL — это главный инструмент для создания качественных витрин данных.

Базовый и продвинутый SQL вместе с огромным количеством близких к реальности задач-примеров даётся в программе курса. Упор на практику особенно важен для постижения этого ремесла.

3️⃣ Data Engineering: добыча сырья

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

📌 Что нужно уметь: базовый Python (библиотеки requests и pandas). Умение подключаться к БД и обращаться к API. Знакомство с Apache Airflow (писать даги и таски, скрипты ставить на расписание).

Блок по дата-инженерии в составе курса проясняет всё, что необходимо для сбора данных.

4️⃣ BI и визуализация: упаковка результата

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

📌 Что нужно уметь: владеть современной BI-системой (Superset, PowerBI, Metabase и/или DataLens). Понимать принципы визуализации и назначение видов диаграмм (точечные, круговые, гистограммы и т. д.) и уметь собирать удобные интерактивные дашборды.

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

5️⃣ И главный мета-навык: системное мышление. Умение видеть связь между тем, как криво заполнена CRM, и тем, как это исказит финальный график на дашборде. Полноценная способность, даже чутьё — приходит только с опытом, но системное обучение нужным инструментам и умениям — необходимая база для его развития.

✅ Записывайтесь на курс «Fullstack-аналитик»: simulative.ru/fullstack-analyst

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

Ошибка при работе с GROUP BY и HAVING в SQL 💻

Буквально на днях в чате студентов курса-профессии «Аналитик данных» обсуждали интересную тему — почему следующий запрос выводит ошибку?

SELECT company_id, count(*) as cnt
FROM users 
GROUP BY company_id
HAVING cnt > 10

Казалось бы, все логично: мы считаем количество пользователей для каждой компании, а затем оставляем только те компании, у которых более 10 пользователей. Однако всё не так просто.

Дело в том, что фильтрация HAVING выполняется системой ещё до того, как произойдёт присвоение алиаса cnt. Поэтому на момент выполнения команды HAVING, система еще понятия не имеет, что это за столбец cnt такой. И выдаёт ошибку:

ERROR: column "cnt" does not exist

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

SELECT company_id, count(*) as cnt
FROM users 
GROUP BY company_id
HAVING count(*) > 10

Вообще говоря, алиасы столбцов можно использовать только в ORDER BY, в других случаях можно нарваться на ошибку. Хотя есть исключения — например, мы обучаем студентов на СУБД PostgreSQL, а в ней можно использовать алиасы также и в GROUP BY.

Но студенты из чата, которые уже устроились аналитиками и работают с другими СУБД (например, MySQL или MS SQL Server), совершенно справедливо отметили, что в них использовать алиасы с GROUP BY нельзя — тоже выдаст ошибку.

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

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

⭐️ Хотите и вы стать крутым аналитиком, которого ищут работодатели? Записывайтесь на курс-профессию — за 10 недель вы получите всё необходимое для старта в профессии и будете готовы к любому собеседованию 🔥

🛎️ Записаться на следующий поток «Аналитика данных»: simulative.ru/data-analyst

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

Привет! На связи Евгений Буторин, ментор интенсива по SQL 👋🏻

Вам хочется попробовать себя в аналитике, но непонятно, кто такой аналитик на самом деле, что нужно уметь на старте и почему все вокруг твердят именно про SQL? Сегодня вечером приходите на мой вебинар — разберём это на реальных примерах и задачах.

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

Если присматриваетесь к аналитике или хотите понять, с чего начать, приходите!

📆 21 июля, 19:00 МСК, онлайн
➡️ Ставьте напоминание в календарь, чтобы не забыть!

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

✍🏻 Задача: ежедневный отчёт о продажах

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

Порешаем задачу вместе?

Проверяем базу: SQL, дедупликацию, инкрементальную загрузку и Data Quality.

Данные:
Есть таблица orders: (order_id INT, order_date DATE, updated_at TIMESTAMP, status VARCHAR, amount DECIMAL), где amount — сумма заказа в валюте.

Бизнес-требования:
👉🏻 Отчёт формируется каждый день в 09:00 за вчерашний день.
👉🏻 В расчёт берём только заказы со статусом paid.
👉🏻 Из-за ретраев микросервисов бывают дубли order_id. Если статус менялся, учитываем последнее состояние (updated_at макс).
👉🏻 Нужно посчитать: кол-во заказов, сумму выручки, средний чек.

Что нужно сделать:
✍🏻 Написать SQL-запрос (дедупликация + фильтр + агрегаты);
✍🏻 Спроектировать таблицу-витрину (поля + типы данных);
✍🏻 Описать 3-4 шага пайплайна загрузки;
✍🏻 Добавить 2 проверки качества данных (Data Quality).

Формат ответа: тезисно. Код для дага в Airflow не нужен.

Попробуйте решить самостоятельно в комментариях, а завтра разберём вместе!

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

💻💻💻💻💻 Как работает ML-инженер: от «пиццы в поиске» до модели в проде

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

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

На вебинаре вы:
➡️ Поймёте, чем ML-подход отличается от обычной разработки — на примере того, как устроен поиск;
➡️ Разберётесь, как устроен пайплайн ML-проекта и где в нём место ML-инженера;
➡️ Увидите, где ML реально работает в индустрии: беспилотный транспорт, голосовые помощники, генеративные сети, рекомендательные системы, финтех, медицина;
➡️ Узнаете тренды профессии в 2026 году и разберётесь, что реально нужно знать джуну на старте.

📆 22 июля, 19:00 МСК, онлайн
✅ Поставить напоминание в календарь

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

Разбор задачи: ежедневный отчёт о продажах

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

Вчера я давала задачу на ежедневный отчёт о продажах, сегодня несу решение 👇🏻

SQL-запрос:

WITH deduped AS (
    SELECT *, 
           ROW_NUMBER() OVER(PARTITION BY order_id ORDER BY updated_at DESC) as rn
    FROM orders
    WHERE order_date >= CURRENT_DATE - INTERVAL '1 day' 
      AND order_date < CURRENT_DATE
),
metrics AS (
    SELECT 
        COUNT(*) AS total_orders,
        SUM(amount) AS total_revenue,
        ROUND(AVG(amount), 2) AS avg_check
    FROM deduped
    WHERE rn = 1 AND status = 'paid'
)
SELECT 
    CURRENT_DATE - INTERVAL '1 day' AS report_date,  -- бизнес-дата отчёта
    total_orders,
    total_revenue,
    avg_check,
    NOW() AS created_at                               -- метка времени загрузки
FROM metrics;

* ROW_NUMBER по order_id + сортировка по updated_at даёт последнюю версию заказа. Фильтр rn = 1 AND status = 'paid' применяется после дедупликации.

Схема таблицы:

CREATE TABLE daily_sales_report (
    report_date DATE PRIMARY KEY,
    total_orders INT,
    total_revenue DECIMAL(15,2),
    avg_check DECIMAL(10,2),
    created_at TIMESTAMP DEFAULT NOW()
);

PRIMARY KEY гарантирует одну строку на день. Типы DECIMAL защищают от ошибок округления.

Шаги пайплайна:

✅ Extract → забираем orders за вчерашний день (инкрементально по дате);
✅ Transform → дедупликация, фильтр paid, агрегаты (тот самый SQL);
✅ Load → UPSERT (INSERT ... ON CONFLICT DO UPDATE) по report_date;
✅ Schedule → запуск в 09:00.

* Важно помнить про идемпотентность: повторный запуск пайплайна не дублирует строки и не ломает метрики.

Data Quality проверки:

✅ total_orders > 0 и total_revenue >= 0;
✅ report_date уникален (нет дублей дат в витрине).

* Опционально: алерт, если выручка отклоняется >50% от предыдущего дня.

Понравилось решение? Больше таких задач решаем на курсе «Инженер данных» с моей менторской поддержкой — вы научитесь строить надёжные пайплайны для компаний и освоите необходимые инструменты для их создания. И самое главное — все задачи построены на реальных кейсах бизнеса!

⚙️ Записаться на курс: https://simulative.ru/data-engineer

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

💻💻💻💻 Настраиваем оркестрацию без Airflow — тянем файлы из Telegram по расписанию

Сегодня вечером ждём вас на стрим! Валерия Елпатьевская, инженер данных в Альфа-Банке, разберёт, как настроить регулярную загрузку файлов из Telegram-канала через API и обойтись без Airflow. Валерия соберёт рабочую оркестрацию на тасках: покажет, куда и как складывать сами файлы и как собрать метаданные к ним.

Что сделаем:
1️⃣ Настроим таски, которые по расписанию забирают новые файлы из Telegram-канала через API;
2️⃣ Разложим файлы в S3-подобное хранилище, а метаданные сохраним отдельно;
3️⃣ Соберём всё в рабочую оркестрацию — без единой строчки Airflow.

Заодно покажем, как обойти ограничение Telegram на выдачу API-ключа — без танцев с бубном.

📆 24 июля, 19:00 МСК, онлайн
➡️ Поставить напоминание в календарь

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

✨ Чистим документы одной кнопкой ✨

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

Думаете, дата-инженер — это человек, который просто переливает данные из одной базы в другую?

Это всё ещё является частью работы дата-инженера, но со временем начали появляться новые задачи. Сегодня всё больше задач связано с AI и RAG-системами. Данные всё ещё нужно «переливать», но только уже в векторные базы, при этом не ломая индекс. При этом желательно подумать об эффективности пайплайна и не делать одно и то же дважды.

Представьте: вчера вы проиндексировали 100 тысяч документов, а сегодня несколько из них изменились. Что делать?

Удалить всё и векторизовать заново? Долго и дорого. К тому же в продовой среде приведёт к временной недоступности документов.

Просто добавить новые векторы? Получим дубликаты.

Здесь на помощь приходит Record Manager из LangChain. Его задача — отслеживать, какие документы уже были проиндексированы, и понимать, что с ними произошло при следующем запуске пайплайна.

Самый простой вариант (для тестов) — InMemoryRecordManager:

record_manager = InMemoryRecordManager(
    namespace="documents"
)
record_manager.create_schema()

В реальных проектах, конечно, используют record manager, который пишет информацию в базу данных, например, в SQLRecordManager. Но принцип работы у них один.

При индексации каждому документу задаётся уникальный идентификатор, например путь к файлу или ID записи в базе данных. Дальше достаточно передать этот ключ в функцию индексации с помощью source_id_key="source".

Самое интересное под капотом! После разбиения документа на чанки RecordManager вычисляет хэш для каждого чанка и сохраняет его вместе с информацией об источнике. При следующем запуске он снова вычисляет хэш и сравнивает с уже сохранённым.

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

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

Именно такие детали редко обсуждают, когда говорят про RAG. А ведь именно они являются залогом надёжной системы, которую можно безопасно запускать в продакшене.

Такие детали — не сломать индекс, не задублировать чанки и не пересчитывать эмбеддинги зря — мы разбираем на курсе «Инженер данных». Если хотите строить RAG-пайплайны, которые выдерживают продакшен, а не разваливаются на втором запуске, — приходите: 26 июля завершается набор!

✅ Записаться на курс: simulative.ru/data-engineer

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

Поймай все метрики 📈

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

⭐️ Поймайте метрику в нашей игре: https://simulative.ru/metrics-game

Сколько метрик собрали? Делитесь в комментариях ⬇️

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

Вебинары этой недели 🔥

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

📌 28 июля, 19:00 МСК — «Превращаем SQL-проект в первый кейс для портфолио»

Если вы уже пробовали решать задачи на SQL, следующий шаг — научиться превращать их в проекты, которые можно показать работодателю. На вебинаре разберём это на практике вместе с Евгением Буториным, ментором бесплатного интенсива по SQL и руководителем CRM-аналитики развития клиентской базы в Альфа Банке.

➡️ Напоминание в календарь

📌 30 июля, 19:00 МСК — «Решаем задачи с собеседований в Яндекс»

Если вы хотите потренировать алгоритмическое мышление и заодно поискать разные подходы к одной и той же задаче, этот вебинар для вас! Вместе с Павлом Беляевым порешаем 5 занимательных задач на Python — одна из них из реального тестового задания на позицию в Яндексе.

➡️ Напоминание в календарь

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

💻💻💻💻💻 Превращаем SQL-проект в первый кейс для портфолио

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

На вебинаре разберём это на практике вместе с Евгением Буториным, ментором бесплатного интенсива по SQL и руководителем CRM-аналитики развития клиентской базы в Альфа Банке.

Что будет на вебинаре:
➡️ Разберём финальный SQL-проект и подход к его решению;
➡️ Поймём, как оформить проект так, чтобы он выглядел сильным кейсом в портфолио;
➡️ Заодно разберём ещё одно реальное тестовое задание на джуна — посмотрим, что там нужно, кроме SQL;
➡️ Обсудим, что сейчас происходит на рынке и как заходить в аналитику в 2026 году.

📆 28 июля, 19:00 МСК, онлайн
➡️ Поставить напоминание в календарь

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

💻💻💻💻💻 Решаем задачи с собеседований в Яндекс

Если вы хотите потренировать алгоритмическое мышление и заодно поискать разные подходы к одной и той же задаче, этот вебинар для вас! Вместе с Павлом Беляевым порешаем 5 занимательных задач на Python — одна из них из реального тестового задания на позицию в Яндексе.

На вебинаре вы:
➡️ Потренируетесь использовать pandas: построите сводные таблицы и найдёте среднее значение колонки сразу в нескольких таблицах;
➡️ Поисследуете списки: посчитаете «расстояние» между элементами, найдёте дубликаты и разберёте другие похожие задачи;
➡️ Организуете свой класс для работы со стеком.

📆 30 июля, 19:00 МСК, онлайн
➡️ Поставить напоминание в календарь

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

🔥 Попробуйте буткемп по аналитике данных

На 3 дня мы открываем демо-доступ к профессии «Аналитик данных»: не скриншоты, не обещания, а реальный формат обучения!

Что входит в демо-доступ:
➖ Вводное занятие с преподавателем курса — живой разбор первых материалов;
➖ Чат со студентами потока;
➖ Урок «Современные подходы в промптинге, современные модели» — тот самый ИИ-блок;
➖ Урок «SQL для анализа данных» — первые реальные задачи по SQL!

Записывайтесь, в чате уже начали знакомиться! Доступ держим только первые 3 дня буткемпа:

🔥 Получить демо-доступ

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

Доверительный интервал: то, что прячет p-value

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

Представьте: мы проводим A/B-тест страницы оплаты — контроль 5.00%, тест 5.45%, по 20 000 юзеров, p = 0.043. Значимо, катим. Продакт: «Сколько денег принесёт?»

p-value на это не отвечает: он умеет только сказать, похожа ли разница на случайный шум. Размера эффекта и точности в этом числе нет. Отвечает доверительный интервал — диапазон эффекта, совместимый с данными. Считаем на Python:

import numpy as np
from scipy import stats

n_a, conv_a = 20_000, 1000   # контроль: 5.00%
n_b, conv_b = 20_000, 1090   # тест:    5.45%

p_a, p_b = conv_a / n_a, conv_b / n_b
diff = p_b - p_a                      # точечная оценка: 0.45 п.п.

# стандартная ошибка разницы двух долей
se = np.sqrt(p_a*(1-p_a)/n_a + p_b*(1-p_b)/n_b)

# p-value двустороннего z-теста
z = diff / se
p_value = 2 * stats.norm.sf(abs(z))
print(f"p-value: {p_value:.3f}")      # 0.043

# 95% доверительный интервал
lo, hi = diff - 1.96*se, diff + 1.96*se
print(f"ДИ: [{lo*100:.2f}; {hi*100:.2f}] п.п.")   # [0.01; 0.89] п.п.

# то же самое в деньгах
users, value = 500_000, 3_000         # юзеров/мес, ₽ с конверсии
print(f"от {lo*users*value/1e6:.1f} до {hi*users*value/1e6:.1f} млн ₽/мес")
# от 0.2 до 13.3 млн ₽/мес

То же p = 0.043 разворачивается в +0.01…+0.89 п.п., или от 0.2 до 13.3 млн ₽/мес при точечной оценке 6.75 млн. Обещать продакту 6.75, когда данные допускают 0.2, — легкомысленно.

Обратная ошибка не лучше: «не значимо» ≠ «эффекта нет». Если интервал накрывает и ноль, и ценный эффект — не хватило выборки, а не эффекта.

Что делать: в каждом отчёте держите интервал рядом с p-value — в процентных пунктах и в деньгах. p-value говорит только, случайна ли разница; интервал показывает, на сколько она тянет. Результат значим — планируй по нижней границе: 0.2 млн получишь почти наверняка, а 6.75 — это верхний край везения, а не обещание.

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

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