Аналитик данных: с нуля до PRO

Роль аналитика данных и основы мышления данными

Зачем компании нужен аналитик данных

Аналитик данных помогает принимать решения на основе фактов, а не ощущений. Его ключевая ценность — связывать бизнес-вопрос (например, «почему упали продажи?») с данными (что именно измерять, где это взять, как проверить) и переводить результат в понятные рекомендации.

Обычно аналитика приглашают, когда нужно:

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

Найти причины изменений (роста, падения, аномалий)

Оценить эффект изменений (новая цена, новый интерфейс, новая рекламная кампания)

Построить регулярную отчетность и метрики

Найти точки роста и приоритизировать задачи

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

Кто такой аналитик данных и чем он занимается

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

Типичные задачи аналитика:

Сформулировать задачу вместе со стейкхолдерами (заказчиками внутри компании)

Понять, какие данные нужны и откуда их получить

Проверить качество данных и подготовить их к анализу

Провести анализ: описательный, диагностический, иногда прогностический

Визуализировать результаты и объяснить выводы

Предложить действия и договориться о том, как измерять результат после внедрения

Роли рядом: чем аналитик данных отличается от смежных специалистов

В компаниях названия ролей могут отличаться, но смысл обычно близок к следующему:

| Роль | Основной фокус | Типичный результат | |---|---|---| | Аналитик данных | Анализ данных под бизнес-вопрос | Выводы, рекомендации, дашборды, исследования | | BI-аналитик | Регулярная отчетность и визуализация | Дашборды, витрины показателей, KPI-отчеты | | Продуктовый аналитик | Поведение пользователей и метрики продукта | Анализ воронок, retention, A/B-тесты, гипотезы | | Дата-инженер | Пайплайны и инфраструктура данных | Надежная доставка и хранение данных, модели данных | | Data Scientist | Модели и продвинутая статистика/ML | Прогнозы, ранжирование, модели, эксперименты |

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

Типовой цикл аналитической работы

Работа аналитика — это не «построить график», а процесс, где каждый шаг влияет на достоверность результата.

!Схема показывает, что аналитика — это замкнутый цикл от вопроса до контроля эффекта

Разберем шаги:

Уточнение бизнес-вопроса

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

Перевод вопроса в метрики и критерии успеха

Например, «улучшить удержание» нужно превратить в измеримое: retention D7 вырос на X% или доля вернувшихся через 7 дней.

Поиск источников данных

Данные могут быть в базе (заказы, события), в системах аналитики, в CRM, в таблицах. Важно понять, кто владелец данных и насколько они полные.

Подготовка и проверка качества

На этом этапе обнаруживаются пропуски, дубликаты, разные определения показателей, ошибки в логировании.

Анализ и проверка гипотез

Аналитик ищет закономерности, сравнивает сегменты, проверяет изменения во времени, оценивает возможные причины.

Выводы и рекомендации

Вывод — это что мы узнали, рекомендация — что сделать дальше. Хорошая рекомендация учитывает стоимость внедрения и ожидаемый эффект.

Мониторинг после внедрения

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

Основы мышления данными

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

Переход от мнений к проверяемым утверждениям

Фраза «кажется, пользователи стали уходить» превращается в проверяемое утверждение:

Какая именно метрика изменилась? (например, retention)

В каком сегменте? (новые пользователи, конкретный канал, конкретная страна)

Когда началось изменение? (после релиза, после изменения цены)

Операционализация: как превратить идею в измерение

Операционализация — это перевод абстрактного понятия в набор измеримых правил.

Пример:

Абстрактно: «активный пользователь»

Измеримо: пользователь, который совершил минимум 1 целевое действие за последние 7 дней

Если определения не зафиксированы, разные команды могут считать «активность» по-разному — и спорить не о реальности, а о словах.

Метрика: какой должна быть «хорошая»

Полезная метрика обычно:

Понятна: ее можно объяснить одной фразой

Стабильно считается: определение не меняется «по ходу обсуждения»

Сопоставима: можно сравнить сегодня с вчера и разные сегменты между собой

Действенна: по ней понятно, какие решения можно принимать

Корреляция и причинность: типичная ловушка

Аналитик часто видит, что два показателя меняются вместе. Это корреляция. Но она не доказывает, что одно вызвало другое.

Пример:

Наблюдение: после нового дизайна выросла выручка

Вопрос: это из-за дизайна или из-за параллельной рекламной кампании, сезонности, изменения ассортимента?

Чтобы приблизиться к причинному выводу, нужны дополнительные методы: контрольные группы, эксперименты (например, A/B-тесты), учет влияющих факторов.

Подробнее о различии корреляции и причинности можно прочитать в статье Correlation does not imply causation.

Единицы анализа и гранулярность

Один и тот же вопрос может требовать разной «единицы»:

Пользователь (сколько людей вернулось)

Заказ (сколько заказов отменили)

Сессия (как ведут себя в рамках визита)

Событие (какие действия совершают)

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

Когорты и сегментация

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

Сегментация — разбиение на группы по признаку (канал, страна, тариф)

Когорта — группа, объединенная общим моментом старта (например, пользователи, зарегистрировавшиеся в одну неделю)

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

Качество данных: почему это основа доверия

Даже «идеальный» анализ бесполезен, если данные ненадежны. Качество данных — это не абстракция, а проверяемые свойства.

Часто проверяют:

Полноту: нет ли пропусков критичных полей

Точность: значения соответствуют реальности (нет ли отрицательных цен, странных дат)

Согласованность: одно и то же считается одинаково в разных отчетах

Своевременность: данные приходят достаточно быстро для решений

Уникальность: нет ли дублей сущностей (например, заказ задвоился)

Хорошая практика — фиксировать определения метрик и источники данных в общем месте: в документации, в словаре данных или в описании дашборда.

Коммуникация: аналитик продает ясность, а не графики

Результат работы аналитика — это понятное объяснение, что происходит и что делать.

Полезная структура сообщения:

Контекст: какой был вопрос и почему он важен

Метод: какие данные и определения использовались

Результаты: что обнаружено (с цифрами)

Вывод: как это интерпретировать

Рекомендации: что сделать и как измерять эффект

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

Этика и приватность: границы «можно» и «нельзя»

Аналитик работает с данными о людях и процессах. Поэтому важны принципы:

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

Контроль доступа: данные доступны тем, кому они действительно нужны

Анонимизация и псевдонимизация: уменьшать риск идентификации человека

Честная интерпретация: не подтасовывать выборки и не «подгонять» выводы под ожидания

Если вы работаете с персональными данными в контексте ЕС, ключевой документ — GDPR.

Как эта статья связана с курсом

Дальше вы будете превращать описанный подход в практические навыки:

Учиться формулировать вопросы, метрики и гипотезы

Осваивать получение данных (обычно через SQL) и подготовку данных

Разбираться в базовой статистике и экспериментах

Строить визуализации и дашборды и объяснять результаты для бизнеса

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

Excel и Google Sheets для аналитики: формулы, сводные, автоматизация

Зачем аналитику Excel и Google Sheets

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

Быстро посчитать метрику и проверить гипотезу

Собрать небольшой датасет из разных источников

Привести данные в понятный для стейкхолдеров вид

Сделать прототип отчета до внедрения в BI

Связь с предыдущей темой мышления данными простая: таблицы помогают быстро пройти цикл «вопрос → метрика → данные → вывод», но требуют дисциплины в определениях и качестве данных.

База: как устроены данные в таблицах

Диапазоны, таблицы и “правильная форма” данных

Для аналитики удобнее всего формат таблицы фактов:

Каждая строка — одно наблюдение (заказ, пользователь-день, событие)

Каждый столбец — один признак (дата, канал, сумма, статус)

Внутри столбца — один тип данных (не смешивать текст и числа)

В Excel полезно превращать диапазон в «Таблицу» (Excel Table): это упрощает формулы, фильтры и обновления.

Типы данных и частые проблемы качества

Типичные “поломки”, которые приводят к неверным выводам:

Числа сохранены как текст (не суммируются)

Даты распознаны как текст или в разном формате

Лишние пробелы и невидимые символы

Дубликаты строк (заказ задвоился)

Полезные функции для очистки:

Excel: TRIM, CLEAN, VALUE, DATEVALUE

Google Sheets: TRIM, CLEAN, VALUE, DATEVALUE, SPLIT

Официальные справки:

Функции Excel (справочник)

Функции Google Sheets (справочник)

Ключевые формулы аналитика

Арифметика и агрегирование по условиям

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

SUM / AVERAGE / COUNT — простые итоги

SUMIF / COUNTIF — одно условие

SUMIFS / COUNTIFS — несколько условий

Пример постановки: «Выручка по заказам со статусом paid за январь».

В Excel: SUMIFS(сумма_заказа; статус; "paid"; дата; ">="&start; дата; "<"&end)

В Sheets: логика та же, синтаксис похож

Практический совет: условия по датам безопаснее задавать как интервал start, end), где end — первый день следующего периода.

Логика и обработка ошибок

В аналитических таблицах ошибки неизбежны: нет значения, не нашлось соответствия, деление на ноль.

IF — ветвление

IFS — несколько условий

IFERROR — подмена ошибки на понятный результат (например, пусто или 0)

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

Поиск соответствий: справочники, цены, категории

Типовой кейс: к таблице заказов нужно подтянуть категорию товара или источник трафика из справочника.

Excel: XLOOKUP (предпочтительно), исторически — VLOOKUP

Универсальная связка: INDEX + MATCH

Google Sheets: VLOOKUP, INDEX + MATCH

Смысл один: вы связываете таблицы по ключу (например, product_id). Ошибка аналитика здесь — использовать “неуникальный ключ” и незаметно получить неверные подстановки.

Официальные справки:

[Функция XLOOKUP (Excel)

Функция VLOOKUP (Google Sheets)

Фильтрация и “мини-витрины”

Когда нужно быстро получить таблицу только по нужным условиям:

Excel: FILTER (в версиях с динамическими массивами)

Google Sheets: FILTER

Это удобно для подготовки данных под сводную, график или проверку гипотезы.

Специфика Google Sheets: функция QUERY

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

Примеры задач, которые удобно решать QUERY:

Сгруппировать выручку по дате и каналу

Отфильтровать строки по условию

Отсортировать результаты и взять топ-N

Справка:

Функция QUERY (Google Sheets)

Практический принцип: если вы начинаете строить сложную “сеть” из десятков вспомогательных столбцов, часто проще сделать один QUERY (в Sheets) или вынести трансформации в Power Query (в Excel).

Массивные формулы и автопротяжка

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

Google Sheets: ARRAYFORMULA (применяет формулу к целому столбцу)

Excel: структурированные ссылки в Excel Table (формула автоматически распространяется вниз)

Справка:

Функция ARRAYFORMULA (Google Sheets)

Сводные таблицы: быстрые срезы и диагностика

Сводные таблицы отвечают на вопрос «что происходит?» и часто помогают перейти к «почему?» через разрезы.

Когда сводная — лучший выбор

Посчитать показатели по сегментам (страна, канал, продукт)

Быстро проверить, где именно “сломалась” метрика

Собрать черновик отчета для обсуждения

Как правильно подготовить данные под сводную

Одна таблица фактов без пустых строк внутри

Заголовки в первой строке

Отдельные колонки для даты, канала, суммы, статуса (не смешивать)

Не хранить итоги и подитоги внутри исходных данных (сводная посчитает их сама)

Основные элементы сводной

!Анатомия сводной таблицы: как поля раскладываются по строкам, столбцам, значениям и фильтрам

Ключевые настройки, которые влияют на корректность:

Тип агрегации в «Значениях» (сумма, количество, среднее)

Формат числа (валюта, проценты)

Группировка дат (по дням/неделям/месяцам)

Официальные справки:

Создание сводной таблицы (Excel)

Сводные таблицы (Google Sheets)

Частые ошибки в сводных

Считать COUNT по столбцу с пропусками и думать, что это количество строк

Использовать “смешанные” типы данных, из-за чего часть значений не попадает в сумму

Перетаскивать поля и забывать, что поменялся смысл метрики

Правило качества: перед тем как верить сводной, сделайте 1–2 ручные проверки на небольшом срезе (например, сверить сумму по одному дню).

Визуализация в таблицах: минимально, но достаточно

Таблицы — не замена BI, но базовая визуальная диагностика должна быть.

Условное форматирование для аномалий (рост/падение, превышение порога)

Линейный график для динамики метрики

Столбчатый график для сравнения сегментов

Принцип: сначала фиксируйте определение метрики и фильтры, потом стройте график. Иначе легко “нарисовать” разные версии правды.

Автоматизация: чтобы отчет не ломался и обновлялся сам

Что именно стоит автоматизировать

Импорт данных из источника

Очистку и преобразования (типы, даты, разбиение столбцов)

Обновление сводных и графиков

Регулярную выгрузку/рассылку

!Цепочка автоматизации: от источника до отчета с обязательными проверками качества

Excel: Power Query как стандартная автоматизация

Power Query (в Excel) позволяет один раз описать шаги подготовки данных и затем обновлять их кнопкой.

Что удобно делать в Power Query:

Загружать данные из файлов, папок, таблиц, некоторых источников

Приводить типы (даты, числа)

Удалять дубликаты

Разворачивать и объединять таблицы

Строить повторяемую “витрину” для сводных

Справка:

Power Query в Excel (справка Microsoft)

Если вам нужно “нажать кнопку и получить файл”, иногда используют макросы/VBA или Office Scripts, но для аналитика-новичка чаще достаточно Power Query + сводных.

Google Sheets: связка функций, импорта и Apps Script

В Sheets часто строят автоматизацию так:

Импорт: IMPORTRANGE (подтянуть данные из другой таблицы)

Подготовка: QUERY, FILTER, ARRAYFORMULA

Автодействия: Google Apps Script (например, обновить, разослать, записать лог)

Справки:

Функция IMPORTRANGE (Google Sheets)

Google Apps Script (документация)

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

Как сделать таблицу “аналитически надежной”

Документируйте определения

Внутри файла (на отдельном листе) зафиксируйте:

Определения метрик (что считается заказом, что считается выручкой)

Период обновления и источник данных

Список фильтров по умолчанию

Делайте проверки качества как часть процесса

Примеры простых проверок:

Количество строк сегодня не меньше/не больше ожидаемого диапазона

Нет отрицательной выручки (если это невозможно по бизнес-правилам)

Доля пропусков в ключевых полях ниже порога

Контрольная сумма сходится с источником (если есть эталон)

Разделяйте слои

Удобная структура файла:

raw — исходные данные (минимум ручных правок)

model — подготовка и расчеты (формулы, Power Query, QUERY)

report — сводные, графики, выводы

Так легче объяснять логику, поддерживать файл и искать ошибки.

Когда таблиц уже недостаточно

Таблицы — отличный старт, но есть признаки, что пора переходить к SQL/витринам/BI:

Данные большие, файл медленный и часто ломается

Нужны единые определения метрик для всей компании

Важно разграничение доступов и аудит изменений

Отчет нужен ежедневно и должен быть воспроизводимым без ручных действий

Именно поэтому дальше в курсе вы будете учиться получать и трансформировать данные более системно (в первую очередь через SQL), а таблицы использовать как быстрый инструмент анализа и коммуникации.

SQL с нуля: запросы, джойны, агрегации, оконные функции

Зачем аналитику SQL, если есть таблицы

В прошлой теме вы научились быстро анализировать данные в Excel и Google Sheets: формулы, сводные, базовая автоматизация. SQL — следующий шаг, когда таблиц становится недостаточно.

SQL нужен аналитику, чтобы:

Доставать данные из баз данных и хранилищ без ручных выгрузок

Считать метрики на больших объемах данных быстрее и надежнее

Делать воспроизводимые расчеты: один запрос можно запускать снова и снова

Согласовывать определения метрик на уровне данных (как часть качества данных)

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

Что такое база данных и как SQL «видит» данные

Обычно аналитик работает с реляционными данными: они хранятся в таблицах.

Таблица — набор строк и столбцов

Строка — один объект наблюдения (например, заказ)

Столбец — признак (например, дата заказа)

Ключ — столбец (или набор столбцов), по которому можно однозначно сопоставлять строки между таблицами (например, order_id)

Минимальный «словарь» терминов:

Схема данных — как устроены таблицы и связи между ними

Запрос — текст на SQL, который описывает, какие данные получить

Результат запроса — таблица, которую вернула база

Официальная справка по SQL (на примере PostgreSQL):

Документация PostgreSQL: SQL-команды

Базовый запрос: SELECT, FROM, WHERE, ORDER BY, LIMIT

SQL-запрос обычно читают так: из каких таблиц берем → что выбираем → как фильтруем → как сортируем.

SELECT и FROM

SELECT — какие столбцы (или вычисления) вернуть.

FROM — из какой таблицы.

Практический принцип: в аналитике лучше явно перечислять столбцы, а не писать SELECT *. Так запрос стабильнее и понятнее.

WHERE: фильтрация

WHERE отбирает строки по условию.

Частые условия:

= равно

<> не равно

IN (...) принадлежит списку значений

BETWEEN ... AND ... диапазон (осторожно с датами и временем)

IS NULL проверка пропуска

Пример: оплаченные заказы за январь (без привязки к конкретной СУБД лучше использовать полуинтервал).

ORDER BY и LIMIT

ORDER BY сортирует результат, LIMIT ограничивает количество строк.

Агрегации: метрики через COUNT, SUM, AVG и GROUP BY

Когда вы считаете бизнес-метрику, вы почти всегда агрегируете данные.

COUNT(*) — количество строк

COUNT(column) — количество строк, где в column не NULL

SUM(amount) — сумма

AVG(amount) — среднее

MIN и MAX — минимум и максимум

GROUP BY: разрезы по сегментам

GROUP BY группирует строки по столбцам, чтобы посчитать метрики по сегментам: по дням, каналам, странам.

Пример: выручка и количество оплаченных заказов по дням.

Правило: все неагрегированные поля в SELECT должны быть перечислены в GROUP BY.

HAVING: фильтр по результатам агрегации

WHERE фильтрует строки до группировки, а HAVING — группы после группировки.

Пример: оставить только дни, где выручка больше 100 000.

Частые ошибки в агрегациях

Путать COUNT(*) и COUNT(column) и получать «не то количество» из-за NULL

Группировать не по той гранулярности (например, по order_date и user_id одновременно, а потом удивляться числам)

Считать метрику по «грязным» данным (дубли, неверные статусы) и не делать проверок качества

Джойны: как соединять таблицы

В реальных данных метрики редко лежат в одной таблице. Например, заказы в orders, пользователи в users, каналы привлечения в traffic_sources.

JOIN соединяет таблицы по ключу.

Ключевые идеи:

Нужно понимать, какая связь между таблицами: один-к-одному, один-ко-многим или многие-ко-многим

Неверный JOIN может «размножить» строки и завысить метрики

!Диаграмма-подсказка по основным типам JOIN

INNER JOIN

Возвращает только строки, которые совпали по ключу в обеих таблицах.

Пример: получить заказы с данными о пользователе.

LEFT JOIN

Возвращает все строки из левой таблицы и подставляет данные из правой, если совпадение нашлось. Если не нашлось — справа будут NULL.

Это полезно, когда левая таблица — «факты» (например, все заказы), а правая — справочник (например, пользователи).

FULL OUTER JOIN

Возвращает все строки из обеих таблиц, заполняя отсутствующие части NULL. Поддерживается не везде.

Анти-джойн (поиск «потеряшек»)

Частая задача качества данных: найти факты, которым не соответствует запись в справочнике.

Пример: заказы без пользователя.

Как не сломать метрики JOIN-ом

Перед тем как джойниться, проверьте уникальность ключа в справочнике (users.user_id должен быть уникальным)

Если справа может быть несколько строк на один ключ, вы получите размножение фактов (и завышение сумм)

Если нужно джойниться к «многим», часто сначала агрегируют правую таблицу до нужной гранулярности

Подзапросы и CTE: как делать запросы читабельными

Сложные запросы удобнее собирать из шагов.

CTE (common table expression) — это именованный подзапрос через WITH. Он повышает читаемость и снижает риск ошибок.

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

Практический принцип: делайте шаги так, чтобы каждый можно было проверить отдельно (как слои raw → model → report в таблицах).

Оконные функции: когда нужны и чем отличаются от GROUP BY

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

Разница по смыслу:

GROUP BY уменьшает число строк: было много заказов → стало по одной строке на день

Оконная функция добавляет вычисленный столбец к каждой строке: было много заказов → осталось много заказов, но появился новый столбец (например, накопительная выручка)

Как читается OVER

Окно задается конструкцией OVER (...).

PARTITION BY — как разделить строки на группы (аналог сегмента)

ORDER BY внутри окна — в каком порядке считать (важно для накоплений и ранжирования)

Ранжирование: ROW_NUMBER

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

Что здесь происходит:

PARTITION BY o.user_id создает отдельное «окно» для каждого пользователя

ORDER BY o.amount DESC сортирует заказы пользователя по сумме

ROW_NUMBER() проставляет номера 1, 2, 3...

Накопительный итог: SUM() OVER

Пример: накопительная выручка по дням.

Почему здесь сначала GROUP BY, а потом окно:

Сначала мы приводим данные к нужной гранулярности (день)

Потом считаем накопление по дням

Скользящее среднее: AVG() OVER с рамкой окна

Иногда нужно сгладить метрику, например среднее за последние 7 дней.

В некоторых СУБД можно задавать рамку окна.

Как это читать:

ROWS BETWEEN 6 PRECEDING AND CURRENT ROW означает: взять текущий день и 6 предыдущих строк (в сумме 7 строк)

AVG(revenue) считает среднее по этому окну

!Иллюстрация сдвигающегося окна для скользящих метрик

Проверки качества данных через SQL

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

Примеры проверок:

Найти дубликаты ключа в справочнике

Проверить долю пропусков в ключевых полях

Найти невозможные значения (например, отрицательные суммы)

Пример: поиск дубликатов user_id.

Пример: отрицательные суммы заказов.

Практический принцип: любые «подозрительные» находки фиксируйте как часть результата анализа — это часто не менее ценно, чем сама метрика.

Как SQL встраивается в рабочий цикл аналитика

SQL — это не отдельный навык, а инструмент внутри цикла аналитики:

Формулируете вопрос и метрику

Определяете нужную гранулярность (по пользователям, заказам, дням)

Пишете запрос: фильтры, агрегации, джойны

Проверяете качество данных и корректность вычислений

Отдаете результат в таблицу, дашборд или презентацию, объясняя определения

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

Подготовка данных: качество, очистка, преобразования, ETL-логика

Зачем аналитику готовить данные

В предыдущих темах вы научились:

Формулировать бизнес-вопросы и метрики

Быстро считать показатели в Excel/Google Sheets

Доставать и агрегировать данные через SQL

На практике между «данные есть» и «метрика посчитана правильно» почти всегда стоит этап подготовки данных. Он отвечает за то, чтобы:

Данные были корректными и сопоставимыми во времени

Определения метрик были едиными (одни и те же фильтры, статусы, единицы измерения)

Расчеты были воспроизводимыми, а не «ручной магией»

Ошибки обнаруживались раньше, чем попадут в отчет или решение

Главная идея: аналитика начинается не с графика, а с надежного набора данных, где понятны правила получения каждой цифры.

Что такое качество данных и как его измеряют

Качество данных — это не «нравится/не нравится», а набор проверяемых свойств. Самые практичные для аналитика:

Полнота: есть ли значения в ключевых полях (дата, id, сумма, статус)

Уникальность: нет ли дублей там, где их не должно быть (например, order_id)

Согласованность: одинаково ли трактуются статусы, валюты, таймзоны, единицы измерения

Точность: нет ли невозможных значений (отрицательная сумма, дата из будущего)

Актуальность (freshness): данные обновляются вовремя для вашей задачи

Ссылочная целостность: все факты «ссылаются» на существующие сущности (заказ ссылается на существующего пользователя)

Одна из удобных метрик контроля — доля пропусков в поле:

Где:

— количество строк, где поле пустое (NULL)

— общее количество строк в проверяемом наборе данных

Если доля пропусков внезапно выросла, это часто сигнал о поломке загрузки, логирования или изменения формата.

Профилирование данных: что понять до очистки

Перед тем как «чинить», нужно описать фактическое состояние данных.

Типовые вопросы профилирования:

Сколько строк и за какой период?

Какие значения встречаются в статусах, категориях, источниках?

Есть ли дубликаты ключей?

Есть ли выбросы и невозможные значения?

Как распределены суммы, возраст, количество событий?

Практический принцип: сначала сделайте срез “что внутри”, затем решайте, что считать ошибкой и как это исправлять.

Очистка данных: типовые проблемы и решения

Типы данных

Частая причина неверных метрик — неверный тип:

Число записано как текст

Дата хранится строкой в разных форматах

Таймзона не учтена (например, события в UTC, а отчет в местном времени)

Что делать:

Приводить типы в одном месте и одинаково для всех отчетов

Фиксировать правила преобразования (например, все даты в UTC, а бизнес-день считаем по конкретной таймзоне)

Пропуски (NULL)

Пропуски бывают нормальными и ошибочными.

Нормальные: поле “promo_code” пустое, если скидки не было

Ошибочные: пустой order_date или user_id

Что делать:

Разделить поля на обязательные и необязательные

Для обязательных — заводить проверки и блокировать расчет витрины при нарушении

Для необязательных — осознанно выбирать поведение (оставить NULL, заменить на значение “unknown”, исключить из метрики)

Дубликаты

Дубликаты бывают:

Полные (строка повторилась один в один)

Логические (один заказ записан дважды с разными техническими id)

Что делать:

Явно определить ключ уникальности (например, order_id)

Хранить правило дедупликации: по чему выбираем “главную” запись (по времени обновления, по статусу, по приоритету источника)

Невозможные и «грязные» значения

Примеры:

Отрицательная сумма там, где возвраты должны быть отдельным типом операции

Статус “paidd” из-за опечатки в источнике

Пробелы и невидимые символы в справочниках

Что делать:

Устанавливать допустимые наборы значений (например, статусы только из списка)

Нормализовать строки: обрезка пробелов, приведение регистра

Фиксировать бизнес-правило: что такое возврат, отмена, частичная оплата

Преобразования данных: от “raw” к аналитическому набору

Подготовка — это не только очистка. Чаще всего нужно превратить данные в форму, удобную для метрик.

Гранулярность: один из главных источников ошибок

Вы уже встречали это в SQL: если смешать уровни детализации, метрика «поплывет».

Типовые уровни:

Событие (каждый клик)

Заказ (одна покупка)

Пользователь-день (агрегированные факты на пользователя за день)

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

Нормализация и справочники

В реляционных данных часто есть:

Таблица фактов (заказы, платежи, события)

Таблицы измерений (пользователи, товары, страны, источники)

Для аналитики вы обычно:

Подтягиваете атрибуты измерений через JOIN

Следите, чтобы справочник был уникален по ключу (иначе факты размножатся)

Типовые “фичи” и производные поля

Примеры преобразований, которые постоянно встречаются в аналитике:

is_paid как признак оплаченного заказа на основе статуса

first_order_date пользователя

Категоризация суммы в бины (например, “до 1000”, “1000–5000”)

Приведение валют к базовой

Вычисление бизнес-даты по таймзоне

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

ETL и ELT: логика “как данные проходят путь”

ETL — Extract, Transform, Load: сначала извлекаем, затем преобразуем, затем загружаем.

ELT — Extract, Load, Transform: сначала загружаем “как есть” в хранилище, а преобразуем уже внутри него SQL-запросами.

В современных аналитических хранилищах часто используют ELT, потому что:

Проще хранить исходные данные для аудита

Преобразования прозрачны и воспроизводимы в SQL

Легче масштабировать вычисления

!Схема слоев данных от источников до витрин и отчетов

Типовая слоистая структура

Удобная модель для аналитика (и хорошо стыкуется с подходом из статьи про таблицы raw → model → report):

raw: данные как пришли (минимум правок)

staging: приведение типов, базовая очистка, дедупликация

mart: витрины под метрики (по дням, по пользователям, по продуктам)

report: дашборды, выгрузки, презентации

Это помогает:

Понимать происхождение каждой цифры

Не смешивать “грязные” данные с бизнес-логикой

Быстрее находить, на каком этапе появилась ошибка

Тесты качества данных: что проверять регулярно

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

Not null: ключевые поля не пустые (order_id, user_id, order_date)

Unique: ключи уникальны там, где должны быть уникальными

Accepted values: статус заказа только из списка (например, new, paid, canceled, refunded)

Range: сумма не отрицательная (или отрицательная только для возвратов по явному правилу)

Referential integrity: все orders.user_id существуют в users.user_id

Freshness: последние данные не старее допустимого порога

!Процесс автоматических проверок качества перед обновлением витрин

Полезный принцип коммуникации с бизнесом: лучше остановить обновление отчета и объяснить причину, чем обновить его неправильными цифрами.

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

Подготовка данных должна быть не «одноразовой», а повторяемой.

Что помогает:

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

Явные фильтры и определения: например, что такое “paid” и какой период включаем

Версионирование логики: изменения в правилах должны быть фиксируемыми (например, через репозиторий)

Документация: словарь метрик и источников (что за таблица, кто владелец, как обновляется)

Контроль изменений: если поменялся источник (новый столбец, новые статусы), это должно быть заметно

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

dbt Documentation

Great Expectations Documentation

Мини-кейс: как подготовка влияет на метрику

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

Что может пойти не так без подготовки:

Дубликаты заказов завысят выручку

Статусы “paid” и “PAID” разойдутся и часть заказов выпадет из фильтра

Время заказа в UTC сдвинет день, и динамика по дням станет неверной

При JOIN к пользователям справочник окажется неуникальным, и выручка “размножится”

Как это предотвращает подготовка:

В staging вы приводите типы, нормализуете статусы и убираете дубликаты по правилу.

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

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

И только после этого строите отчет.

Как эта тема связывает курс в единую систему

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

Из Excel/Sheets — привычку разделять raw → model → report, делать проверки и прототипировать.

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

Дальше любые продвинутые темы аналитики (продуктовые метрики, A/B-тесты, витрины, BI) будут опираться на одну основу: подготовленные и проверенные данные.

Статистика и A/B-тесты: гипотезы, метрики, доверительные интервалы

Зачем аналитику статистика и A/B-тесты

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

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

задавать проверяемые гипотезы;

измерять эффект изменения;

понимать, насколько результат надежен;

избегать типовых ловушек интерпретации.

Что такое A/B-тест

A/B-тест — это частный случай рандомизированного контролируемого эксперимента: пользователей случайно делят на две (или более) группы и показывают им разные версии продукта.

Группа A (контроль): текущая версия.

Группа B (тест): версия с изменением.

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

Полезный контекст: Рандомизированное контролируемое исследование.

!Показана последовательность шагов A/B-теста от постановки гипотезы до решения

Гипотезы: что именно мы проверяем

Нулевая и альтернативная гипотезы

Статистическая проверка начинается с двух утверждений:

Нулевая гипотеза : эффекта нет, версии равны (например, конверсия не изменилась).

Альтернативная гипотеза : эффект есть (например, конверсия изменилась).

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

Подробнее: Статистическая проверка гипотез.

Односторонняя и двусторонняя проверка

Двусторонняя: допускаем как рост, так и падение метрики. Чаще всего это корректнее.

Односторонняя: проверяем только рост (или только падение). Требует сильного обоснования до запуска, иначе легко получить самообман.

Единица рандомизации и единица анализа

Вы заранее фиксируете:

кого рандомизируете: пользователь, устройство, аккаунт;

на чем считаете метрику: пользователь, сессия, заказ.

Если эти уровни перепутать, можно получить систематически неверные оценки (например, посчитать конверсию по событиям вместо пользователей).

Метрики: что считать и как не «сломать смысл»

Виды метрик в эксперименте

Primary metric: главная метрика, по которой принимается решение (например, конверсия в оплату).

Secondary metrics: вспомогательные метрики (например, средний чек, доля возвратов).

Guardrail metrics: метрики-ограничители, которые не должны ухудшиться (например, ошибки, время ответа, отмены).

Практический принцип: одна primary metric на решение и ограниченный список guardrail, иначе вы утонете в множественных сравнениях.

Пример: конверсия

Если метрика — конверсия, ее базовое определение:

Где:

— конверсия;

— число пользователей, совершивших целевое действие (например, оплату);

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

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

Минимально детектируемый эффект (MDE)

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

MDE — минимальный эффект, который бизнес считает значимым (например, рост конверсии минимум на 0.3 процентных пункта).

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

Доверительный интервал: как думать о неопределенности

Интуитивный смысл

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

Важно правильно понимать интерпретацию:

При 95% доверительном интервале речь не о том, что вероятность истинного эффекта внутри интервала равна 95%.

Корректная интерпретация такая: если бы мы много раз повторяли эксперимент одинаковым образом, то примерно в 95% случаев построенный интервал содержал бы истинный эффект.

Подробнее: Доверительный интервал.

Интервал для разницы конверсий (упрощенная практическая формула)

Пусть:

— конверсия в контроле;

— конверсия в тесте;

, — размеры групп;

эффект — разница конверсий.

Тогда:

Стандартная ошибка разницы:

Где:

— типичный масштаб случайного шума в оценке разницы;

выражения вида отражают вариативность бинарного события (конверсия или нет);

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

При доверительном уровне 95% часто используют приближение:

Где:

— границы интервала;

— коэффициент для 95% (квантиль нормального распределения).

Практическая интерпретация для решения:

если интервал целиком выше 0, есть статистически значимый рост;

если интервал целиком ниже 0, есть статистически значимое падение;

если 0 попадает внутрь интервала, данных недостаточно, чтобы уверенно сказать, что эффект отличен от нуля.

!Иллюстрация того, как положение доверительного интервала относительно нуля влияет на вывод

p-value и уровень значимости: как это связано с интервалами

Что такое p-value

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

Подробнее: p-value.

Критичные моменты:

p-value не равен вероятности того, что верна;

маленький p-value означает, что наблюдаемый эффект трудно объяснить случайностью при .

Уровень значимости

— допустимая вероятность ошибки первого рода (ложноположительного решения). Часто берут .

Связь с доверительным интервалом простая:

если 95% доверительный интервал для эффекта не включает 0, то p-value будет меньше 0.05 (для двусторонней проверки в типичных условиях).

Ошибки в A/B-тестах: что значит «ошибиться»

Ошибка первого и второго рода

Ошибка I рода: мы решили, что эффект есть, но на самом деле его нет. Вероятность ограничивается .

Ошибка II рода: мы решили, что эффекта нет, но он есть. Ее вероятность обозначают .

Мощность теста (power) — это вероятность обнаружить эффект, если он реально есть:

Где:

— мощность;

— вероятность пропустить реальный эффект.

На практике часто целятся в мощность 80% или 90%. Чем выше мощность, тем больше нужна выборка.

Контекст: Статистическая мощность.

Практический дизайн эксперимента: что фиксировать до запуска

Перед запуском полезно оформить протокол эксперимента. Минимальный набор:

Формулировка изменения и ожидаемого механизма (почему метрика должна измениться).

Primary metric, guardrails и точные определения числителя и знаменателя.

Единица рандомизации и исключения (боты, сотрудники, тестовые аккаунты).

Длительность теста или критерий остановки (например, набрать нужный размер выборки).

Уровень значимости и целевая мощность.

План анализа: какие сегменты смотрим и какие сравнения считаем допустимыми.

Это напрямую связано с предыдущими темами курса:

из подготовки данных вы берете дисциплину определений и проверок качества;

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

Проверки качества данных в A/B-тестах

Статистика не спасет, если экспериментальные данные «сломаны». Минимальные проверки:

Проверка логирования: событие экспозиции теста и целевое событие приходят стабильно.

Дубликаты: один и тот же пользователь не должен попадать в обе группы.

Свежесть: данные за последние часы/дни не отстают от ожидаемого.

SRM (Sample Ratio Mismatch): доли пользователей в группах соответствуют плану (например, 50/50). Если резко не соответствует, это сигнал, что рандомизация или сбор данных нарушены.

Практический принцип: если SRM обнаружен, результаты эксперимента обычно нельзя интерпретировать как причинный эффект.

Анализ результата: что обычно делают на практике

Выбор статистического теста

Выбор зависит от типа метрики:

Бинарная метрика (конверсия) — часто используют тест для долей (или эквивалентные подходы).

Средние значения (например, выручка на пользователя) — часто используют t-тест, но нужно думать о выбросах.

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

Главная цель для начинающего аналитика: не «выучить все тесты», а научиться корректно:

задать единицу анализа;

собрать данные без смещения;

посчитать эффект и доверительный интервал;

не сломать вывод ошибками дизайна.

Практический вывод по результату

Хорошая формулировка результата включает:

оценку эффекта (например, п.п. конверсии);

доверительный интервал (например, 95% CI: от +0.1 до +0.7 п.п.);

влияние на guardrails;

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

Типовые ошибки и как их избегать

Подглядывание (peeking): вы смотрите результат каждый день и останавливаете, как только стало значимо. Это резко повышает ложноположительные выводы.

Множественные проверки: много метрик и сегментов без поправок увеличивают шанс найти «значимость» случайно.

Неверный знаменатель: конверсию считают на всех пользователей, хотя часть не видела эксперимент.

Неправильная единица анализа: метрику по пользователям считают по событиям и получают смещение.

Размножение данных: при JOIN к справочнику с неуникальным ключом метрика завышается.

Неучтенная динамика: эффект новизны в первые дни и откат позже; сезонность и дни недели.

Здесь хорошо видно, как курс складывается в систему: SQL и подготовка данных защищают от «технических» ошибок, а статистика защищает от «логических» ошибок интерпретации.

Как эта тема связана с дальнейшим обучением

Дальше статистика будет встречаться постоянно:

в продуктовых метриках и воронках (сравнения сегментов);

в экспериментах и причинных выводах;

в мониторинге метрик и поиске аномалий.

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

Python для анализа данных: pandas, визуализация, ноутбуки, EDA

Зачем аналитику Python, если уже есть Excel и SQL

В предыдущих темах вы освоили:

Как формулировать бизнес-вопросы и метрики

Как быстро проверять гипотезы в Excel/Google Sheets

Как доставать данные через SQL и не ломать метрики джойнами и гранулярностью

Почему подготовка и качество данных критичны

Как мыслить про неопределенность в статистике и A/B-тестах

Python дополняет эту систему там, где таблиц и чистого SQL уже не хватает:

Быстрые исследования и EDA (exploratory data analysis, разведочный анализ данных) на выгрузках и витринах

Более гибкая очистка и преобразования, чем в таблицах

Визуализация и диагностика (распределения, выбросы, связи)

Повторяемые ноутбуки и отчеты, которые легко показать команде

Подготовка датасетов для статистики, A/B-тестов и более продвинутых моделей

Важно: Python не заменяет SQL. Типовая связка в работе аналитика такая:

SQL достает данные на нужной гранулярности и с правильными фильтрами

Python проверяет качество, исследует, визуализирует, помогает понять причины

Результат возвращается в отчет/дашборд/презентацию как понятные выводы и рекомендации

!Схема, показывающая, как SQL и Python встраиваются в общий цикл аналитической работы

Рабочая среда аналитика: ноутбуки и воспроизводимость

Что такое ноутбук

Jupyter Notebook и JupyterLab позволяют в одном месте хранить:

Код

Результаты выполнения

Комментарии и выводы текстом

Графики

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

Официальные источники:

Jupyter Project

Практические правила работы в ноутбуке

Чтобы ноутбук был полезен не только вам «сейчас», но и вам же «через месяц» (или коллеге), держите дисциплину:

Давайте ноутбуку цель в первых строках

Фиксируйте определения метрик и фильтры текстом рядом с кодом

Разделяйте этапы: загрузка данных → подготовка → EDA → выводы

Избегайте скрытой магии: минимизируйте ручные правки данных вне кода

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

Виртуальные окружения и зависимости

Чтобы код запускался одинаково на разных машинах, фиксируют зависимости.

venv или conda создают отдельное окружение

requirements.txt (pip) или environment.yml (conda) фиксируют версии библиотек

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

pandas: базовая модель данных аналитика

Что такое DataFrame

В pandas основной объект — DataFrame:

Похоже на таблицу (строки и столбцы)

В столбцах обычно один тип данных (число, строка, дата)

Поддерживает фильтрацию, группировки, объединения, преобразования

Официальная документация:

pandas Documentation

Минимальный набор импорта

Загрузка данных

Самые частые источники для аналитика:

CSV/TSV файлы

Excel

Результат SQL-запроса (через коннектор)

Пример с CSV:

Пара полезных приемов:

parse_dates помогает сразу читать даты как даты

dtype={...} помогает задать типы и не получить числа как строки

Пример чтения Excel:

Первичный осмотр данных

Быстрые команды для «профилирования» (из темы про качество данных):

Что вы хотите понять на этом шаге:

Сколько строк и столбцов

Есть ли пропуски в ключевых полях

Какие типы у столбцов (особенно даты и числа)

Какие значения в категориальных полях (статусы, страны, каналы)

Качество данных в pandas: быстрые проверки

Python удобен тем, что вы можете поставить «аналитические предохранители» прямо в исследовании.

Пропуски

Интерпретация:

0.00 означает, что пропусков нет

0.15 означает, что пропуски в 15% строк

Дубликаты

Проверка дублей по ключу:

Если дубли возможны по бизнес-логике (например, разные версии записи заказа), тогда важно заранее определить правило дедупликации.

Невозможные значения

Например, отрицательная сумма там, где ее быть не должно:

Или странные даты:

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

Преобразования в pandas: типовые операции аналитика

Фильтрация строк и выбор столбцов

Создание новых признаков

Пример: признак «оплачен» и месяц заказа.

Группировки и метрики

То, что вы делали в SQL через GROUP BY, в pandas делается через groupby.

Пример: выручка и число заказов по дням для оплаченных.

Почему здесь nunique, а не count:

count считает строки

nunique считает уникальные order_id и защищает от некоторых дублей

Объединения таблиц: merge как аналог JOIN

pandas merge соответствует SQL JOIN.

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

Практический принцип такой же, как в SQL:

Проверьте уникальность ключа в справочнике users по user_id

Иначе вы получите размножение строк и завышенные суммы

Проверка уникальности ключа:

Сортировки и топ-N

Работа со временем

В аналитике время почти всегда ключевое.

Приведение к дате без времени:

Агрегация по неделям/месяцам (через to_period):

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

EDA: разведочный анализ данных как обязательный этап

Что такое EDA

EDA — это набор приемов, которые помогают понять данные до того, как вы начнете делать далеко идущие выводы.

EDA отвечает на вопросы:

Что происходит с метриками во времени

Есть ли выбросы, ошибки, дубли, пропуски

Какие сегменты ведут себя по-разному

Какие отношения между переменными выглядят правдоподобно, а какие подозрительно

EDA не доказывает причинность. Он помогает:

Найти гипотезы

Найти проблемы качества данных

Выбрать корректный дизайн дальнейшей проверки (в том числе A/B-тест)

Рекомендуемый сценарий EDA

Ниже — рабочая «шпаргалка», которая хорошо стыкуется с предыдущими темами курса (метрики, гранулярность, качество данных).

Контекст и определения

Проверки качества (пропуски, типы, дубли, справочники)

Описательные метрики

Динамика во времени

Сегментация и сравнение групп

Выбросы и нестандартные значения

Формулировка выводов и ограничений

Главное: EDA всегда заканчивается не «графиками», а выводами и следующими шагами.

Визуализация в Python: минимум, который нужен аналитику

Для визуализации чаще всего используют:

matplotlib как базовый слой

seaborn как удобный слой для статистических графиков

Официальные источники:

Matplotlib Documentation

Seaborn Documentation

Базовая настройка

Динамика метрики во времени

Пример: выручка по дням.

На что смотреть:

Резкие провалы и пики (возможные поломки данных или реальные события)

Дни недели и сезонность

Сдвиги после релизов/кампаний (но без вывода о причинности)

Сравнение сегментов

Пример: выручка по странам.

Распределения и выбросы

Для сумм заказов часто характерны «тяжелые хвосты» и выбросы.

И быстрый просмотр выбросов через boxplot:

Практический вывод:

Выбросы могут быть реальными (корпоративные покупки)

А могут быть ошибками (лишние нули, неверная валюта)

Ваше решение (фильтровать, винзоризировать, оставлять) должно опираться на бизнес-правило

Как связать Python-EDA с A/B-тестами и статистикой

Python часто используют как «площадку подготовки» данных для эксперимента:

Проверить корректность логирования экспозиции

Проверить, что пользователь не попал в обе группы

Проверить распределение трафика по группам (по сути, SRM-проверка)

Посчитать метрики по пользователям нужной гранулярности

Построить графики динамики эффекта и guardrail-метрик

Пример проверки «пользователь только в одной группе»:

Если таких пользователей много, статистика дальше не спасет: дизайн эксперимента нарушен.

Типовые ошибки новичков в Python-анализе

Работать без фиксации определений метрик и фильтров

Смешивать гранулярности (например, считать метрику «по пользователям» на уровне событий)

Делать merge без проверки уникальности ключа

Скрывать проблемы качества через автоматические заполнения без объяснения

Доверять графику без проверки данных и без контрольных точек

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

Итог: что вы должны уметь после этой темы

Понимать роль Python в связке Excel → SQL → подготовка данных → статистика

Уверенно работать с pandas.DataFrame: загрузка, типы, фильтры, groupby, merge

Делать базовые проверки качества данных в Python

Проводить EDA по структуре: качество → описания → динамика → сегменты → выбросы → выводы

Строить понятные графики динамики, сравнений и распределений

Дальше эти навыки будут постоянно использоваться: и при анализе метрик, и при подготовке датасетов для A/B-тестов, и при поиске причин изменений в продукте и бизнесе.

BI и профессиональная практика: дашборды, storytelling, портфолио, собеседования

Зачем аналитику BI и «профессиональная упаковка»

В прошлых темах вы научились доставать данные (SQL), готовить их (качество, очистка, ETL/ELT), оценивать неопределенность (статистика, A/B-тесты) и исследовать данные в Python (EDA, визуализации). Теперь важный шаг до уровня PRO: научиться превращать вычисления в решения.

BI и профессиональная практика закрывают 4 ключевых вопроса:

Как сделать так, чтобы метрики были едиными и доверенными (не «каждый считает по-своему»).

Как упаковать результат в дашборд и историю, понятные бизнесу.

Как собрать портфолио, которое доказывает ваши навыки.

Как проходить собеседования, где проверяют не только инструменты, но и мышление.

Что такое BI и где он в цепочке данных

BI (Business Intelligence) — это набор процессов и инструментов, которые превращают данные в отчеты, дашборды и метрики для регулярного управления бизнесом.

Важно различать роли слоев:

Источники: продуктовые события, CRM, платежи.

Хранилище: база/хранилище, где данные доступны аналитике.

Подготовка: правила очистки, дедупликации, приведения типов.

Витрины и семантический слой: таблицы и определения, удобные для метрик.

BI: визуализация, фильтры, доступы, расписание обновлений.

!Где BI находится в общем пайплайне данных

Типичные BI-инструменты

Выбор инструмента зависит от компании, но принципы одинаковы:

Microsoft Power BI — корпоративный стандарт во многих компаниях.

Tableau — сильная визуальная аналитика.

Looker Studio — быстрые дашборды, часто в маркетинге.

Apache Superset — open-source BI.

Metabase — простой вход, много self-service.

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

Дашборд как продукт: для кого, зачем, как будет использоваться

Дашборд — это не набор графиков. Это инструмент принятия решений.

Перед созданием дашборда зафиксируйте:

Пользователь дашборда: CEO, руководитель продаж, продукт, маркетинг, операторы.

Частота решений: ежедневно, еженедельно, по итогам месяца.

Сценарий использования: мониторинг, поиск причины, планирование.

Стоимость ошибки: насколько опасно «ошибиться на 2%».

Три типа дашбордов

Мониторинговый: быстро понять, все ли в норме, и где аномалия.

Диагностический: разобраться почему метрика изменилась (разрезы, сегменты, воронка).

Операционный: список объектов для действия (заказы в риске, заявки без ответа, просрочки).

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

Главный риск BI: разные определения одной и той же метрики

Если вы дошли до BI, вы уже знаете из тем про SQL и подготовку данных: проблема редко в визуализации — она в определениях.

Что нужно зафиксировать для каждой метрики

Название и смысл: одна фраза, понятная бизнесу.

Формула и фильтры: какие статусы, какие исключения.

Единица анализа: пользователь, заказ, сессия.

Гранулярность: день, неделя, месяц.

Окно времени и таймзона: что такое «день» в бизнесе.

Источник данных: таблицы/витрина.

Практический стандарт: хранить определения в словаре данных или документации к витрине (часто это делают через dbt).

dbt Documentation

Почему витрина метрик важнее графика

Если метрика собирается в BI «на лету» из сырых таблиц, вы получаете:

медленные отчеты;

сложные и дублирующиеся формулы;

риск разных версий метрики в разных отчетах;

трудность тестирования качества.

Профессиональный подход:

метрики считаются в витрине (SQL/ELT);

BI в основном визуализирует готовые показатели;

проверки качества запускаются до публикации.

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

Хороший дашборд помогает ответить на 3 вопроса:

Что происходит?

Где именно происходит?

Что делать дальше?

Рекомендуемая структура экрана

Контекст и фильтры: период, сегмент, версия продукта.

Главные KPI: 5–9 показателей, которые действительно управляют бизнесом.

Тренды: динамика KPI и ключевых драйверов.

Диагностика: разрезы (страна, канал, платформа), воронка, когорты.

Заметки: определения и важные события (релиз, акция).

!Анатомия удобного аналитического дашборда

Частые ошибки в BI-дашбордах

Слишком много метрик: дашборд превращается в «кладбище графиков».

Нет определений: пользователь не понимает, что именно считается.

Нет сравнения: показывают только «сегодняшнее число» без базы (вчера, неделя назад, план).

Смешана гранулярность: рядом показатели «по событиям» и «по пользователям» без объяснения.

Цвет заменяет смысл: много цветов, мало информации.

Минимальный набор сравнений

Обычно достаточно 2–3 опорных сравнения:

к предыдущему периоду (день к дню, неделя к неделе);

к аналогичному периоду прошлого года (если есть сезонность);

к плану или целевому значению.

Storytelling: как превратить анализ в решение

BI часто отвечает на вопрос «что», но бизнесу нужен ответ «что делать». Storytelling — это дисциплина объяснения результата.

Структура истории для бизнеса

Контекст: что случилось и почему вопрос важен.

Определения: как считаем метрику, кого включаем.

Наблюдение: что изменилось (цифры, график).

Диагностика: где именно (сегменты, этап воронки, когорта).

Гипотезы причин: 2–4 правдоподобные версии.

Проверка: какие данные подтверждают/опровергают (SQL, EDA, A/B).

Рекомендация: действие, ожидаемый эффект, риск.

Мониторинг: как измерим результат после внедрения.

Как выбрать правильный уровень уверенности

Связь с темой статистики:

Если это наблюдение в данных без эксперимента, формулируйте вывод как вероятностный: «есть устойчивый рост», «похоже на эффект канала», «нужно проверить».

Если это A/B-тест, вы можете говорить про эффект уверенно, но только при корректном дизайне (рандомизация, SRM, единица анализа).

Один график — одна мысль

Правило, которое сильно улучшает коммуникацию:

Заголовок графика должен быть выводом, а не описанием.

Плохо: «Конверсия по дням».

Хорошо: «После релиза 12.4 конверсия упала на новых пользователей из iOS».

Self-service аналитика и контроль доступа

BI часто используют не только аналитики, но и менеджеры. Это плюс, но есть риски.

Что такое self-service

Self-service — когда пользователь сам меняет фильтры, строит разрезы и получает ответ без запроса к аналитику.

Чтобы это работало безопасно:

витрины должны быть понятными и ограниченными по смыслу;

определения метрик должны быть встроены (описания полей, документация);

должны быть корректные уровни доступа.

Доступы и приватность

Связь с этикой из первой темы:

минимизация данных;

разграничение доступов (RLS/row-level security, если доступ зависит от подразделения);

избегание вывода персональных данных в широкие отчеты.

Портфолио аналитика: что показать, чтобы вас наняли

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

Что такое сильный проект в портфолио

Сильный проект демонстрирует полный цикл:

постановка вопроса;

получение данных (SQL);

подготовка и проверки качества;

анализ (EDA, сегменты, статистика при необходимости);

визуализация (дашборд или отчет);

выводы и рекомендации.

Рекомендуемая структура репозитория проекта

README.md: цель, контекст, метрики, основные выводы.

data/: или ссылка на источник данных и описание.

sql/: запросы, сбор витрин.

notebooks/: EDA и анализ.

dashboard/: скриншоты, ссылка на демо, описание.

docs/: словарь метрик, допущения, ограничения.

!Как выглядит понятный проект в портфолио аналитика

Где хранить и как показывать

GitHub как стандарт для кода и описаний: GitHub

Публичные ноутбуки или отчет можно показать через статический экспорт.

Если делаете BI-дашборд, добавьте скриншоты и описание логики (не полагайтесь на «кликните по ссылке»).

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

Собеседования аналитика: что проверяют и как готовиться

Собеседования обычно проверяют 4 блока.

SQL и работа с данными

Проверяют:

агрегации, джойны, оконные функции;

аккуратность с NULL, дубликатами, гранулярностью;

способность собрать датасет под метрику.

Типовой вопрос: «посчитайте retention» или «выручку по когортам» и объясните, почему ваш запрос корректен.

Метрики, продуктовая логика и причинность

Проверяют:

умение определять метрику (числитель, знаменатель, фильтры);

выбор unit of analysis;

понимание различия корреляции и причинности;

дизайн A/B-теста и ошибки (peeking, SRM, множественные проверки).

BI и коммуникация

Проверяют:

как вы выбираете KPI и не перегружаете дашборд;

как вы объясняете вывод;

умеете ли вы предложить действие, а не только график.

Поведенческое интервью (про опыт)

Даже без большого опыта можно отвечать структурно:

проблема;

контекст и ограничения;

что сделали;

результат;

чему научились.

Полезный формат ответа: STAR (Situation, Task, Action, Result). Официальное описание встречается в карьерных материалах, например на странице DOL: Метод STAR

Практическая связка навыков из курса

Эта тема собирает весь курс в единую профессиональную систему:

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

Excel/Sheets помогает быстро прототипировать и проверять.

SQL обеспечивает воспроизводимое получение данных.

Подготовка данных делает цифры надежными.

Статистика и A/B-тесты отвечают за корректные выводы при неопределенности.

Python дает гибкость в EDA и аналитической диагностике.

BI и storytelling превращают результат в решение, понятное бизнесу.

Если вы держите эту цепочку целиком, вы становитесь аналитиком уровня PRO: не «строителем графиков», а человеком, который уменьшает неопределенность и помогает компании действовать.