Аналитика данных: от основ до практики

Роль аналитики данных и формулирование бизнес-задач

Зачем бизнесу аналитика данных

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

В бизнесе аналитика обычно нужна, чтобы:

Понимать, что происходит (например, продажи падают в одном регионе).

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

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

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

Если в компании решения принимаются на основе данных, это обычно называют data-driven подходом. Его смысл не в том, чтобы «всё решали цифры», а в том, чтобы:

явно формулировать цель и критерии успеха;

уменьшать влияние субъективных мнений;

фиксировать, что именно сработало и почему.

Полезный ориентир: Data-driven decision-making.

Где аналитика находится в цепочке создания ценности

Частая ошибка новичков — воспринимать аналитику как «сделать отчёт» или «построить график». На практике графики — лишь средство.

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

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

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

Основные типы аналитики (простыми словами)

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

Описательная (descriptive): что произошло?

Диагностическая (diagnostic): почему это произошло?

Прогнозная (predictive): что, вероятно, произойдёт дальше?

Предписывающая (prescriptive): что лучше сделать, чтобы получить нужный результат?

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

Почему важно правильно формулировать бизнес-задачу

Бизнес-задача — это формулировка проблемы или цели на языке бизнеса (деньги, клиенты, риски, сроки). Аналитическая задача — это то, что аналитик делает с данными, чтобы помочь бизнесу (посчитать, сравнить, сегментировать, построить модель, проверить гипотезу).

Если бизнес-задача сформулирована размыто, то:

аналитик может сделать «правильный анализ неправильной проблемы»;

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

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

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

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

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

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

Кто принимает решение на основе результата?

Какое решение будет принято в зависимости от вариантов ответа?

Когда нужен результат (сроки)?

Какую цену имеет ошибка (например, потеря выручки, репутационные риски)?

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

Как перевести бизнес-цель в аналитическую задачу

Ниже — практичный алгоритм, который можно применять почти всегда.

Шаг 1. Зафиксировать бизнес-цель

Примеры бизнес-целей:

Увеличить выручку интернет-магазина.

Снизить отток подписчиков.

Ускорить обработку заявок.

Снизить долю возвратов.

Важно: цель должна быть управляемой (на неё можно повлиять) и временной (к какому сроку).

Шаг 2. Выбрать метрику и критерий успеха

Метрика — измеримый показатель. KPI — метрика, по которой оценивают успех команды/направления.

Примеры:

Цель: увеличить выручку.

Метрики: количество заказов, средний чек, конверсия в покупку.

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

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

Полезный ориентир для формулирования измеримых целей: SMART criteria.

Шаг 3. Уточнить объект анализа и сегменты

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

Вопросы для уточнения:

Что именно анализируем: пользователей, заказы, продукты, заявки?

За какой период?

Какие сегменты важны (например, новые/возвращающиеся, регионы, тарифы)?

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

Шаг 4. Сформулировать гипотезы (предположения)

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

Примеры гипотез:

Из-за повышения стоимости доставки снизилась конверсия в заказ.

Изменение формы заявки сократит время обработки.

Письмо-напоминание на 3-й день снизит отток.

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

Шаг 5. Превратить гипотезу в аналитическую задачу

Типовые форматы аналитической задачи:

Посчитать: динамику метрики, разницу по сегментам.

Найти причину: где именно произошёл провал (в каком шаге воронки).

Проверить эффект: было/стало или тест/контроль.

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

Определить приоритет: где вклад в метрику максимален.

Если планируется сравнение вариантов изменения, часто применяют экспериментальный подход, например A/B testing.

Шаблон постановки задачи для аналитика

Ниже — короткий шаблон, который можно копировать в рабочие документы.

| Блок | Что написать | Пример | |---|---|---| | Контекст | Что за продукт/процесс и что случилось | Упала конверсия в оплату на сайте | | Бизнес-цель | Чего хотим добиться | Вернуть конверсию и сохранить выручку | | Метрика и критерий успеха | Какая метрика важна и что считаем успехом | Конверсия в оплату на уровне прошлого месяца | | Объект и сегменты | Что анализируем и какие разрезы важны | Пользователи, каналы, устройства | | Гипотезы | Почему это могло произойти | Ухудшилась скорость загрузки на мобильных | | Ограничения | Сроки, ресурсы, правила | Нужны выводы за 2 дня, без внедрений | | Решение по итогам | Какие решения будут приняты | Откат релиза или доработка мобильной версии |

Такой шаблон снижает риск, что аналитик «сделает красиво», но не в ту сторону.

Качество данных как часть бизнес-задачи

Даже идеально сформулированная цель не спасает, если данные не подходят для ответа.

Базовые вопросы к данным:

Данные существуют? (есть ли события/поля, чтобы измерить метрику)

Данные сопоставимы? (одинаково ли считается метрика до и после изменения)

Данные полные? (нет ли провалов, дублей, смещений)

Данные своевременные? (не приходит ли информация с задержкой)

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

Частые ошибки в формулировке задач

Подмена цели: «сделать дашборд» вместо «снизить отток».

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

Слишком широкая постановка: «проанализировать продажи» без фокуса и сегментов.

Путаница метрики и рычага: метрика — что измеряем, рычаг — что меняем.

Игнорирование ограничений: сроки, бюджет, юридические требования.

Мини-чеклист перед стартом анализа

Сформулирована бизнес-цель и срок.

Выбрана ключевая метрика и критерий успеха.

Определены объект анализа и ключевые сегменты.

Есть 1–3 гипотезы, которые реально проверить.

Понятно, какое решение будет принято по итогам.

Проверено, что нужные данные существуют и считаются корректно.

Что дальше по курсу

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

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

Сбор, хранение и подготовка данных (ETL/ELT)

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

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

Что мы называем данными в аналитике

В прикладной аналитике чаще всего встречаются два «мира» данных.

Табличные данные — строки и столбцы (заказы, платежи, обращения, остатки).

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

Важно договориться о единице наблюдения: что означает одна строка.

В таблице заказов одна строка часто равна одному заказу.

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

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

Откуда берутся данные: типовые источники

Источники зависят от продукта и бизнес-процессов, но набор обычно повторяется.

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

Транзакционные базы (касса, биллинг, ERP, CRM): заказы, оплаты, возвраты.

Маркетинговые платформы: расходы, показы, клики, кампании.

Службы поддержки: тикеты, причины обращений, SLA.

Внешние данные: курсы валют, геоданные, справочники.

На этом этапе полезно вернуть разговор к бизнес-задаче: какая метрика, в каком разрезе и с какой частотой обновления нужна. Это определяет, какие источники подключать и достаточно ли текущего трекинга.

Где данные хранят: базовые понятия

Операционные базы и аналитические хранилища

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

Операционная база часто отвечает на вопрос «покажи заказ №123».

Аналитическое хранилище отвечает на вопрос «как изменилась конверсия по регионам за 12 месяцев».

Ориентир по терминам: Data warehouse.

Data warehouse, data lake и зачем они нужны

На практике встречаются два популярных подхода к хранению «аналитической правды».

Data warehouse — структурированное аналитическое хранилище, где данные заранее приведены к согласованным форматам и моделям.

Data lake — хранилище «сырья» (часто файлов), куда складывают данные в более исходном виде, а преобразования делают позже.

Ориентир по терминам: Data lake.

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

ETL и ELT: что это и в чём разница

ETL и ELT — два способа организовать путь данных.

ETL — Extract, Transform, Load: извлечь данные из источника, преобразовать в отдельной зоне и загрузить в хранилище.

ELT — Extract, Load, Transform: извлечь, загрузить «как есть» в аналитическое хранилище, а преобразования делать уже внутри него.

Ориентиры: Extract, transform, load, Extract, load, transform.

!Наглядно показывает, чем ETL отличается от ELT и где выполняются преобразования

Сравнение ETL и ELT

| Критерий | ETL | ELT | |---|---|---| | Где происходят преобразования | До загрузки в хранилище | Внутри хранилища | | Что проще хранить | Сразу подготовленные таблицы | Сырой слой плюс модели | | Гибкость при изменении логики | Ниже: часто надо менять внешний процесс | Выше: меняем SQL-модели и пересчитываем | | Типичный современный сценарий | Когда хранилище ограничено или есть строгие правила до загрузки | Когда хранилище мощное и удобно трансформировать SQL-ом |

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

Типичный путь данных: от источника до витрины

Ниже — типовая логика, даже если названия слоёв отличаются.

Извлечение: получение данных из источников (таблицы, API, события).

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

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

Моделирование данных: построение согласованных таблиц, удобных для анализа.

Витрины данных: таблицы «под задачу» (например, воронка по неделям и каналам).

Доступ и потребление: BI, ноутбуки, отчёты, модели.

!Общая карта того, как данные движутся от источников к витринам

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

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

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

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

Инкрементальная загрузка снижает стоимость и ускоряет обновление.

Нужен способ понять, какие данные «новые» или «изменились».

Один из популярных подходов — Change Data Capture (CDC): фиксация изменений в источнике и доставка этих изменений в аналитический контур.

Ориентир: Change data capture.

Подготовка данных: что именно делает трансформация

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

Типовые виды трансформаций:

Приведение типов: даты становятся датами, числа — числами.

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

Дедупликация: устранение повторов (например, повторная отправка события).

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

Соединения таблиц: связывание заказов с пользователями и платежами.

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

Отдельно стоит понятие витрина данных: таблица или набор таблиц, сделанных под конкретный класс задач.

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

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

Хорошая витрина уменьшает риск «каждый считает метрику по-своему».

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

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

Ниже — практичные измерения качества и примеры.

| Измерение качества | Вопрос | Пример проверки | |---|---|---| | Полнота | Все ли записи пришли? | Нет ли провала по числу заказов относительно вчера | | Уникальность | Нет ли дублей? | order_id не должен повторяться | | Корректность формата | Типы и форматы верные? | Дата события парсится и не равна NULL | | Согласованность | Не противоречат ли данные друг другу? | Оплаченный заказ должен иметь платеж | | Своевременность | Приходят ли данные вовремя? | Данные за вчера доступны до 10:00 |

Для автоматизации проверок используют специализированные инструменты и подходы «тестов данных». Ориентир по инструменту: Great Expectations.

Оркестрация и воспроизводимость

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

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

Расписание (ежечасно, ежедневно, по событию).

Зависимости (витрина строится только после обновления модели).

Повторы при сбое и уведомления.

Ориентир по распространённому оркестратору: Apache Airflow.

Документация, определения и «единая правда»

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

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

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

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

Владельцы: кто отвечает за источник и за витрину.

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

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

Безопасность и доступ: базовые принципы

При работе с данными почти всегда есть ограничения.

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

Разделение сред: разработка и продакшен.

Логи и аудиты: кто и когда получал доступ.

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

Как аналитик формулирует задачу на данные

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

Короткий шаблон запроса на данные или трекинг:

| Блок | Что уточнить | Пример | |---|---|---| | Метрика | Что считаем и как | Конверсия в оплату = оплаченные заказы / визиты | | Единица наблюдения | Что такое «строка» | Одно событие оплаты на заказ | | Разрезы | Какие сегменты нужны | Канал, устройство, регион | | Частота обновления | Как быстро нужно | Ежедневно до 09:00 | | Источник правды | Какая система главная | Биллинг — главный источник оплат | | Ограничения | Что нельзя делать | Не хранить сырые номера карт |

Если этот шаблон заполнен, становится проще спроектировать ETL/ELT-пайплайн и сразу заложить проверки качества.

Что дальше по курсу

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

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

SQL — основной язык, на котором аналитик превращает подготовленные данные из хранилища (после ETL/ELT из прошлой темы) в метрики, сегменты и проверки гипотез (из первой темы курса). На практике именно SQL чаще всего отвечает на вопрос: что происходит в данных прямо сейчас и в каких разрезах это видно.

В этой статье разберём три уровня:

базовые запросы и фильтрация

агрегации и группировки для метрик

оконные функции для сравнений, ранжирования и расчётов без потери детализации

Синтаксис SQL немного отличается между системами (PostgreSQL, BigQuery, ClickHouse, Snowflake), но основные идеи одинаковые. Термины: SQL.

Мини-схема данных для примеров

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

users(user_id, signup_at, country)

orders(order_id, user_id, created_at, status)

order_items(order_id, product_id, qty, price)

payments(order_id, paid_at, amount, payment_status)

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

orders: одна строка = один заказ

order_items: одна строка = одна позиция в заказе

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

Базовая анатомия запроса SELECT

Чаще всего аналитический запрос состоит из этих блоков.

SELECT — какие поля и вычисления вернуть

FROM — откуда берём данные

JOIN — как связываем таблицы

WHERE — фильтры по строкам

GROUP BY — группировка для агрегатов

HAVING — фильтры по группам (после агрегации)

ORDER BY — сортировка

LIMIT — ограничение числа строк

Официальная справка по конструкции SELECT: PostgreSQL: SELECT.

Простой пример: список заказов за неделю.

Фильтрация: WHERE, IN, BETWEEN, LIKE и работа с NULL

WHERE и логика условий

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

IN вместо длинных OR

BETWEEN и границы периодов

BETWEEN включителен с обеих сторон, поэтому в аналитике часто безопаснее писать полуинтервал: >= start AND < end.

NULL: почему = NULL не работает

NULL означает неизвестно, поэтому сравнение field = NULL не возвращает TRUE. Используйте IS NULL.

Если нужно подставить значение вместо NULL, используйте COALESCE.

Соединения таблиц: JOIN как основа аналитики

Большинство метрик требуют связать факты (заказы, платежи) с измерениями (пользователи, страны, каналы). Это делается через JOIN. Термины: Join (SQL)).

INNER JOIN и LEFT JOIN

INNER JOIN оставляет только строки, для которых нашлось совпадение в обеих таблицах.

LEFT JOIN оставляет все строки из левой таблицы и добавляет данные справа, если они нашлись.

Пример: заказы и платежи (покажем все заказы, даже если платежа нет).

!Интуитивная разница между INNER JOIN и LEFT JOIN

Главная ошибка аналитика при JOIN: «размножение строк»

Если соединить orders и order_items, то один заказ превратится в несколько строк (по числу позиций). Это нормально, но метрики нужно считать с учётом этого.

Пример ошибки: посчитать число заказов по таблице order_items без уникализации.

неправильно: COUNT(order_id)

правильно: COUNT(DISTINCT order_id)

Агрегации: как считать метрики

Агрегатные функции превращают набор строк в одно число (или одно число на группу).

Типовой набор:

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

COUNT(DISTINCT x) — число уникальных значений

SUM(x) — сумма

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

MIN(x), MAX(x) — минимум и максимум

GROUP BY: метрика по сегментам

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

Идея из первой темы курса: бизнес-цель формулируется как метрика, а GROUP BY — это реализация метрики в нужных разрезах (сегментах).

HAVING: фильтрация после агрегации

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

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

CASE WHEN: метрики «условно»

CASE помогает считать показатели по условию без нескольких запросов.

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

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

Когда логика усложняется, полезно разделять её на шаги.

подзапрос — выражение внутри FROM или WHERE

CTE (WITH) — именованный подзапрос в начале запроса

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

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

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

Агрегации с GROUP BY «схлопывают» данные: одна строка на группу. Но в аналитике часто нужно:

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

посчитать накопительный итог

найти «предыдущую покупку» пользователя

ранжировать объекты внутри сегмента

Для этого существуют оконные функции.

Официальное введение: PostgreSQL: Window Functions.

Идея OVER: «окно» поверх строк

Оконная функция выглядит так:

функция (SUM, AVG, ROW_NUMBER, LAG и другие)

OVER (...) — правило, как сформировать «окно» строк

Чаще всего в OVER используют:

PARTITION BY — разбиение на группы (например, по пользователю)

ORDER BY — порядок внутри группы (например, по времени)

!Что такое PARTITION BY и ORDER BY в оконных функциях

ROW_NUMBER, RANK: порядковый номер и ранжирование

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

Разница ROW_NUMBER и RANK важна, когда есть одинаковые значения сортировки.

ROW_NUMBER всегда 1, 2, 3… без «ничьих»

RANK даёт одинаковый ранг равным значениям, но может «пропускать» номера

SUM/AVG OVER: агрегат рядом с каждой строкой

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

Здесь нет GROUP BY, поэтому строки платежей сохраняются, а показатель добавляется «сбоку».

Накопительный итог (cumulative sum)

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

Это полезно для контроля выполнения планов и для визуализаций «накоплением».

Скользящее среднее (moving average)

Иногда нужно сгладить дневные колебания. Это делается рамкой окна.

Пример: средняя выручка за последние 7 дней (включая текущий день).

LAG/LEAD: предыдущая и следующая строка

Это ключ к поведенческим метрикам: интервалы между покупками, повторные действия, «что было до».

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

Примечание: выражение разницы дат зависит от СУБД. В некоторых системах нужно использовать специальные функции для интервалов.

Практические правила, чтобы SQL-аналитика была надёжной

Явно фиксируйте период: лучше полуинтервал >= start AND < end.

Проверяйте единицу наблюдения перед JOIN и агрегациями.

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

Разделяйте логику на шаги через WITH, чтобы проще проверять.

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

Что дальше по курсу

Теперь у нас есть связка:

бизнес-цель → метрика, сегменты, гипотеза

данные → источники, слои, витрины и качество

SQL → получение метрик и сравнения на подготовленных таблицах

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

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

Статистика в аналитике данных нужна не ради формул, а чтобы принимать решения в условиях неопределённости. В прошлых темах курса мы:

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

разобрали, как данные попадают в хранилище и становятся пригодными для анализа

научились считать метрики SQL-ом

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

конверсия выросла с 2.00% до 2.08% — это реальный эффект или шум?

средний чек в одном регионе выше — это закономерность или случайность выборки?

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

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

Откуда берётся неопределённость

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

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

метрика меняется изо дня в день

мы сравниваем сегменты, которые отличаются по составу

Ключевая идея:

параметр — истинная характеристика всей совокупности (например, истинная конверсия всех пользователей за месяц)

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

Оценка почти всегда случайно колеблется, даже если продукт вообще не менялся.

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

Распределение описывает, какие значения принимает величина и как часто. Аналитику распределения нужны, чтобы:

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

понимать, можно ли применять «стандартные» статистические методы

избегать ошибок интерпретации (например, когда среднее искажено выбросами)

Частые типы распределений в продуктовой аналитике

Нормальное распределение

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

Распределение с «тяжёлым хвостом»

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

Биномиальное распределение

- возникает для метрик вида «успех/неуспех» - примеры: конверсия в оплату, доля пользователей, сделавших действие - справка: Биномиальное распределение

Пуассоновское распределение

- для счётчиков событий на интервал: обращения в поддержку за день, ошибки 500 за минуту - справка: Распределение Пуассона

!Сравнение симметричного распределения и распределения с тяжёлым хвостом

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

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

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

Для конверсий и долей удобны доли и доверительные интервалы для долей.

Выборка, стандартная ошибка и центральная предельная теорема

Один из самых важных мостов от «сырых данных» к статистическим выводам: распределение оценки.

Среднее и его неопределённость

Пусть у нас есть значения метрики .

— размер выборки (сколько наблюдений)

— выборочное среднее

Формула среднего:

Здесь:

— сумма всех наблюдений

деление на даёт «среднее на одно наблюдение»

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

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

Если — выборочное стандартное отклонение (мера разброса значений в данных), то стандартная ошибка среднего:

Где:

— типичный масштаб случайного отклонения среднего

— насколько сильно разбросаны отдельные значения

— корень из размера выборки

Практический смысл формулы:

чем больше , тем точнее оценка среднего

рост точности идёт как , то есть в 4 раза больше наблюдений дают примерно в 2 раза меньше шум

Почему «часто можно считать нормально»

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

Справка: Центральная предельная теорема

В аналитике это означает:

для многих метрик можно строить доверительные интервалы и тесты для среднего

но нужно помнить про зависимости (например, «события» пользователя не независимы) и про тяжёлые хвосты (где сходимость может быть медленной)

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

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

Справка: Доверительный интервал

Корректная интерпретация доверительного интервала

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

если бы мы много раз повторяли сбор данных одинаковым способом, то примерно в 95% случаев построенный интервал накрывал бы истинный параметр

Некорректная, но частая интерпретация:

«с вероятностью 95% истинное значение лежит внутри именно этого интервала»

Почему некорректно: в классической (частотной) статистике параметр считается фиксированным, а случайным является интервал.

Доверительный интервал для среднего

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

Справка: Распределение Стьюдента

Общий вид доверительного интервала для среднего:

Где:

— среднее по выборке

— стандартное отклонение по выборке

— размер выборки

— уровень значимости, для 95% CI это

— критическое значение t-распределения для уровня и степеней свободы

Практический смысл:

задаёт «ширину шума»

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

Доверительный интервал для конверсии (доли)

Конверсия — это доля успехов :

Где:

— число «успехов» (например, оплат)

— число попыток (например, визитов или оформлений)

В простом приближении стандартная ошибка доли:

И приближённый 95% интервал часто пишут как:

Где 1.96 — приблизительное критическое значение для 95% при нормальном приближении.

Важные оговорки для практики:

при малых и при долях близких к 0 или 1 нормальное приближение может работать плохо

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

!Как выглядит доверительный интервал и сравнение двух групп

Проверка гипотез: как формализовать решение

В бизнесе гипотеза звучит как «изменение X улучшит метрику Y». В статистике это превращается в сравнение двух утверждений.

Справка: Статистическая проверка гипотез

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

Нулевая гипотеза : эффекта нет (различие равно нулю или объясняется случайностью)

Альтернативная гипотеза : эффект есть (различие не нулевое или в заданную сторону)

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

: конверсии в A и B равны

: конверсии отличаются

p-value и уровень значимости

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

Справка: p-value

выбирают уровень значимости (часто 0.05)

если , то результат называют статистически значимым и часто отвергают

Важная интерпретационная ловушка:

p-value не является вероятностью того, что верна

p-value не говорит о практической полезности эффекта

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

Любое решение по тесту может ошибаться.

Ошибка первого рода: отвергли , хотя эффекта нет

- вероятность такой ошибки примерно равна

Ошибка второго рода: не отвергли , хотя эффект есть

- зависит от размера эффекта и объёма данных

Связанное понятие:

мощность теста — вероятность обнаружить эффект, если он реально есть

Практический смысл для аналитика:

если данных мало, вы часто будете «не видеть» настоящие эффекты

если проверяете много гипотез, вы почти гарантированно найдёте «значимые» ложные находки

Доверительные интервалы и тесты: как это связано

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

если 95% доверительный интервал для разницы не включает 0, то тест на уровне обычно даст значимость

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

интервал показывает масштаб эффекта и его неопределённость

тест даёт только «прошло/не прошло порог»

В продуктовой работе почти всегда нужно объяснять не только «значимо», но и:

насколько велик эффект

стоит ли он стоимости внедрения

каков риск, что эффект на самом деле близок к нулю

Типовые сценарии в аналитике и что применять

Сравнение среднего чека

Чек часто имеет тяжёлый хвост, поэтому при сравнении средних важно:

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

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

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

Сравнение конверсий

Для конверсии как доли полезно:

сравнивать не только относительный рост, но и абсолютную разницу

строить доверительные интервалы для долей или разницы долей

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

До/после без эксперимента

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

Минимальная практика снижения риска:

сравнивать одинаковые дни недели

проверять контрольные метрики, которые не должны меняться

сегментировать (возможно, эффект есть только в части пользователей)

Как связать статистику с SQL-аналитикой

SQL обычно отвечает за:

корректное определение выборки (период, фильтры, единица наблюдения)

расчёт агрегатов (, суммы, средние, доли)

Дальше статистика отвечает за:

перевод этих агрегатов в неопределённость (SE, доверительные интервалы)

формализацию решения (гипотезы, p-value или интервалы для разницы)

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

Здесь:

— размер выборки

— число успехов

— оценка конверсии

Этих трёх чисел уже достаточно, чтобы дальше посчитать стандартную ошибку доли и приближённый интервал.

Частые ошибки и как их избегать

Смешивание единиц наблюдения

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

Связь с прошлой темой про SQL:

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

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

Если вы сначала посмотрели 10 метрик, а затем «выбрали ту, где значимо», то уже не означает 5% ложных находок.

Практика:

заранее фиксировать целевую метрику и критерий успеха (из первой темы курса)

явно отделять exploration (поиск) от confirmatory (подтверждение)

Путаница статистической и практической значимости

При большом трафике даже микроскопический эффект может стать «значимым».

Практика:

всегда показывать размер эффекта (например, разницу конверсий в процентных пунктах)

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

Зависимости в данных

Пользователь может совершать много событий, и эти события зависимы. Тесты, предполагающие независимость наблюдений, могут «переоценивать уверенность».

Практика:

часто лучше агрегировать на уровне пользователя (одна строка на пользователя) и сравнивать пользователей

Что дальше по курсу

Теперь у вас есть базовый язык неопределённости:

распределения помогают понимать свойства метрик

доверительные интервалы показывают диапазон правдоподобных значений

проверка гипотез формализует решение и риск ошибок

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

Исследовательский анализ данных и выявление закономерностей (EDA)

EDA (Exploratory Data Analysis) — исследовательский анализ данных. Его цель — быстро и системно понять, что за данные у нас есть, можно ли им доверять, как устроены распределения и сегменты, и какие гипотезы имеет смысл проверять дальше.

Классическое определение и контекст: Exploratory data analysis.

Зачем нужен EDA аналитику

EDA закрывает разрыв между двумя типичными состояниями:

«У нас есть таблицы в хранилище» (после ETL/ELT).

«У нас есть вывод и решение» (после расчётов метрик и статистической проверки).

Практически EDA нужен, чтобы:

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

обнаружить проблемы качества данных до того, как вы построите метрики и отчёты;

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

найти сегменты и закономерности, которые превращаются в проверяемые гипотезы.

Важно: EDA не заменяет статистику. Он помогает сформулировать что именно проверять и на каких данных.

Где EDA находится в общем процессе аналитики

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

Формулируем бизнес-задачу: метрика, сегменты, критерий успеха.

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

Получаем базовые срезы SQL-ом: выборки, агрегаты, окна.

Делаем EDA: проверяем данные, смотрим распределения, сегменты, тренды, аномалии.

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

!Место EDA в общем аналитическом процессе

Старт EDA: зафиксировать объект анализа и единицу наблюдения

До графиков и сводных таблиц важно договориться о двух вещах.

Объект анализа: пользователи, заказы, платежи, сессии, обращения.

Единица наблюдения: что означает одна строка в вашей рабочей таблице.

Примеры:

«Одна строка = один заказ» (таблица orders).

«Одна строка = один платеж» (таблица payments).

«Одна строка = одно событие» (таблица событий).

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

Минимальный аудит качества данных в EDA

В EDA аудит качества данных обычно делают быстро, но системно. Его задача — ответить: можно ли вообще считать метрику так, как задумано?

Ниже — практичный набор проверок, который часто можно сделать одним SQL-скриптом.

Полнота и покрытие по времени

Есть ли данные за весь нужный период?

Нет ли провалов по дням?

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

Если вы видите «дыру» в один день, это может быть:

реальное событие (сайт не работал, закончился товар);

сбой загрузки данных;

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

Дубли и уникальность ключей

Есть ли дубликаты там, где их быть не должно?

Пример: проверка order_id.

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

Пропуски (NULL) в критичных полях

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

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

Согласованность между таблицами

Совпадают ли факты между сущностями?

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

Диапазоны и «невозможные значения»

Есть ли отрицательные суммы, даты из будущего, некорректные статусы?

Пример: платежи с отрицательной суммой.

Одномерный EDA: понять распределения и типичное поведение

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

Числовые показатели: среднее, медиана, выбросы

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

Практика:

смотрите MIN, MAX, среднее и перцентили;

не делайте вывод «среднее выросло», пока не проверили, что рост не вызван несколькими экстремальными значениями;

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

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

Если ваша СУБД поддерживает перцентили, добавьте их в анализ (синтаксис зависит от системы).

!Типичные визуальные паттерны для денежных метрик

Категориальные признаки: частоты и «перекосы»

Для категорий (страна, канал, устройство, статус) базовый EDA обычно начинается с частот.

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

Это помогает быстро заметить:

неожиданные значения (новый статус, опечатка, «мусор»);

резкий перекос (например, слишком много отмен);

изменения логики (вчера статус назывался иначе).

Время: тренды, сезонность, аномалии

Почти любая бизнес-метрика живёт во времени. Поэтому EDA часто включает график или таблицу динамики.

Практика:

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

сравнивайте одинаковые дни недели, если есть выраженная недельная сезонность;

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

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

Двумерный EDA: сегменты, сравнения и первые закономерности

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

Сегментация через GROUP BY

Связь с темой про формулирование задачи: сегменты превращают «в среднем всё нормально» в конкретный диагноз.

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

Здесь мы специально агрегировали до уровня заказа (GROUP BY country, order_id), чтобы JOIN с платежами не размножал строки и не ломал доли.

Связи между признаками: осторожно с «корреляцией»

В EDA часто хочется сказать: «если A выше, то B тоже выше». Это может быть полезной подсказкой, но важно помнить:

совместное изменение не означает причинно-следственную связь;

закономерность может быть объяснена третьим фактором (например, каналом или регионом);

при большом числе сравнений вы почти неизбежно найдёте «интересное» случайно.

Как использовать такие находки правильно:

зафиксировать гипотезу механизма (что и почему влияет);

предложить следующий шаг: эксперимент, контрольная группа, статистическая проверка.

Артефакты EDA: что должно остаться после исследования

EDA полезен, когда он воспроизводим и превращается в решения. Типовые результаты EDA:

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

определения метрик и уточнение единицы наблюдения;

ключевые срезы: динамика, топ-сегменты, аномалии;

3–7 гипотез с приоритетом и ожидаемым эффектом;

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

Хорошая практика — вести EDA в виде одного SQL-скрипта или ноутбука, где:

есть входные фильтры по периоду;

есть явные определения метрик;

есть проверки качества перед расчётами.

Типовые ошибки в EDA

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

Делать выводы «эффект есть», опираясь только на визуальное отличие, без оценки неопределённости.

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

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

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

Как EDA связывается со статистикой и следующими шагами

EDA помогает подготовить корректную постановку статистической проверки:

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

выбрать уровень агрегации (часто пользователь);

оценить порядок величин и вариативность;

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

Дальше (по теме статистики) вы переходите от «кажется, отличается» к формату:

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

проверка гипотез;

оценка практической значимости.

Что дальше по курсу

После EDA логично переходить к типовым продуктовым сценариям, где исследование превращается в устойчивые расчёты и решения:

воронки и точки отвала;

когорты и удержание;

оценка эффекта изменений и эксперименты;

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

Визуализация и дашборды: принципы, метрики и сторителлинг

В прошлых темах курса мы научились:

переводить бизнес-цель в метрики, сегменты и гипотезы;

понимать, откуда берутся данные и как устроены слои ETL/ELT;

считать метрики SQL-ом и избегать ошибок из-за JOIN и неверной единицы наблюдения;

применять статистическое мышление (неопределённость, доверительные интервалы);

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

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

Визуализация в аналитике — это не украшение отчёта, а инструмент:

сделать данные сравнимыми;

показать динамику и сегменты;

подсветить аномалии;

объяснить, что делать дальше.

Термины для ориентира: Визуализация данных, Бизнес-дашборд), Data storytelling.

Зачем дашборд, а не просто график

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

Хороший дашборд отвечает на три вопроса (в таком порядке):

Что происходит? (уровень метрик и тренды)

Где именно это происходит? (сегменты, воронка, вклад факторов)

Что делать? (интерпретация, приоритет действий, следующие проверки)

Плохой дашборд чаще всего выглядит как «много графиков», но не содержит:

явной цели и аудитории;

определений метрик;

порогов и контекста;

подсказок, какие действия следуют из изменений.

Начните с задачи: аудитория, решение, частота

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

Аудитория: кто будет смотреть дашборд (менеджер, маркетинг, саппорт, финансы).

Решение: что они делают по результату (отключают канал, откатывают релиз, увеличивают бюджет).

Частота: как часто принимают решение (ежедневно, еженедельно, раз в месяц).

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

!Цепочка от бизнес-вопроса до решения через метрику, данные и визуализацию

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

Базовые правила определения метрики

Метрика в дашборде должна быть определена так же строго, как в SQL-расчёте:

единица наблюдения (пользователь, заказ, визит, платёж);

период и часовой пояс;

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

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

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

Практика из темы ETL/ELT: если определение метрики не закреплено, появится «несколько правд», и дашборд станет поводом для споров.

Северная звезда, KPI и диагностические метрики

Типовой набор в продуктовом/коммерческом дашборде:

North Star Metric: метрика, которая лучше всего отражает ценность продукта для клиента и долгосрочный рост.

KPI: показатели, по которым оценивают направление в заданный период.

Диагностические метрики: помогают понять причину изменения KPI (воронка, причины отказов, производительность, качество трафика).

Важно не смешивать:

метрики результата (выручка, активные пользователи);

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

Декомпозиция: как связать метрику с причинами

Декомпозиция помогает превратить «график про выручку» в «график, по которому видно, что делать».

Классический пример:

Где:

— выручка за период;

— число заказов за период;

— средний чек (Average Order Value).

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

Аналогично для конверсии:

Где:

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

— число заказов с успешной оплатой;

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

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

Выбор правильного графика: быстрый справочник

Визуализация работает хорошо, когда тип графика соответствует вопросу.

| Вопрос | Что показываем | Типовой график | Частая ошибка | |---|---|---|---| | Как меняется во времени? | тренд, сезонность, аномалии | линейный график | смешать разные масштабы без вторичной оси и пояснений | | Что больше/меньше? | сравнение категорий | столбцы, dot plot | слишком много категорий без сортировки | | Из чего состоит? | структура долей | stacked bars | пытаться сравнивать доли по слишком многим сегментам | | Где «узкое место»? | шаги процесса | воронка | считать воронку на неправильной единице (события вместо пользователей) | | Как распределена величина? | хвосты, выбросы | histogram, box plot | показывать только среднее и скрывать разброс | | Есть ли связь A и B? | зависимость | scatter plot | делать вывод о причинности по корреляции |

Термины для ориентира: Линейный график, Гистограмма, Box plot, Диаграмма рассеяния.

Читаемость и восприятие: что важно мозгу

Иерархия внимания

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

верх: ключевые KPI и их изменение;

середина: разбор причин (декомпозиция, воронка, сегменты);

низ: детали, таблицы и диагностика.

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

Практичные правила:

один цвет — «норма», другой — «отклонение»;

не кодируйте смысл только цветом (часть людей не различает цвета одинаково);

избегайте палитр, где соседние категории похожи.

Контекст: Дальтонизм.

Масштабы осей и честность

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

для столбцов обычно ожидают ось от нуля;

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

!Иллюстрация того, как масштаб оси меняет восприятие эффекта

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

Типовая структура дашборда

Часто удобно проектировать дашборд «сверху вниз»:

Сводка: 5–10 KPI, тренды, сравнение с прошлым периодом, цель/план.

Драйверы: декомпозиция KPI (например, выручка → заказы и чек).

Сегменты: каналы, регионы, устройства, новые/возвращающиеся.

Диагностика данных: свежесть данных, пропуски, доля NULL, объём трафика.

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

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

Фильтры полезны, но избыток фильтров разрушает интерпретацию:

люди сравнивают «несравнимые» выборки;

меняется знаменатель метрик;

повторить анализ становится невозможно.

Практика:

оставляйте только те фильтры, по которым реально принимают решения;

фиксируйте дефолтный период и объясняйте, что именно показано;

добавляйте подсказки с определениями метрик.

Данные и задержки: показывайте свежесть и «неполные дни»

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

Минимальный набор для доверия:

время последнего обновления;

предупреждение о неполном дне;

сравнение объёма событий/заказов с ожидаемым уровнем.

Это напрямую связано с темой качества данных в ETL/ELT.

Как добавить статистическое мышление в визуализацию

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

Практики:

показывайте размер выборки рядом с конверсией (например, визиты и оплаты), иначе «рост» может быть на десятках наблюдений;

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

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

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

сглаживание (например, скользящее среднее), но обязательно помечают, что это сглаживание;

сравнение с прошлой неделей по тем же дням недели.

Сторителлинг на данных: как превращать графики в решение

Сторителлинг — это структура объяснения: контекст → наблюдение → причина → действие. Он нужен, когда у вас есть вывод, который требует согласования и действий.

Каркас истории (который подходит почти всегда)

Контекст: что за метрика и почему она важна.

Что изменилось: где, когда и насколько.

Где именно: сегменты и точки провала.

Почему это могло произойти: гипотезы механизма (из темы про постановку задач).

Что делать: конкретные варианты решений и риск каждого.

Как проверим: какие данные или эксперимент подтвердят.

Аннотации важнее, чем «ещё один график»

Практика для продуктовых дашбордов:

отмечайте релизы, изменения цен, кампании, инциденты;

подписывайте пики и провалы;

добавляйте короткий комментарий «что произошло» прямо на график.

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

Пример: как связать SQL-метрику и дашборд

Предположим, цель — мониторить выручку и понимать, за счёт чего она меняется: заказов или чека. В хранилище есть payments и orders.

SQL-основа для витрины дневных метрик:

Дальше в дашборде это превращается в три согласованных элемента:

линия revenue по дням;

линия orders_cnt по дням;

линия aov по дням.

Именно такая связка поддерживает декомпозицию и ускоряет диагностику.

Частые ошибки в визуализации и дашбордах

Нет одного главного вопроса: дашборд превращается в «галерею графиков».

Метрики без определения: разные люди считают по-разному.

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

Нет контекста: не показаны план, прошлый период, сезонность.

Скрыта неопределённость: вывод делается по шуму на малой выборке.

Слишком много цветов и типов графиков: внимание распадается.

Чеклист перед публикацией дашборда

Сформулировано решение, которое принимают по дашборду.

У каждой метрики есть определение и источник.

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

Есть декомпозиция ключевого KPI на драйверы.

Есть 2–5 ключевых сегментов, а не 50 категорий.

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

Масштабы осей не вводят в заблуждение.

Добавлены аннотации ключевых событий (релизы, кампании).

Что дальше

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

воронки и точки отвала;

когорты и удержание;

эксперименты и оценка эффекта изменений.

Эксперименты и принятие решений: A/B-тесты и интерпретация результатов

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

В предыдущих темах курса мы уже построили фундамент:

из бизнес-цели сделали метрику, сегменты и критерий успеха;

разобрали, как данные попадают в хранилище и как контролировать качество;

научились считать метрики SQL-ом без ошибок единицы наблюдения и JOIN;

добавили статистическое мышление: неопределённость, доверительные интервалы и проверка гипотез;

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

научились доносить результаты в дашбордах и сторителлинге.

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

Ориентиры по терминам: A/B testing, Randomized controlled trial.

Что даёт A/B-тест и почему он сильнее «до/после»

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

Группа A — контроль, текущая версия.

Группа B — тест, новая версия.

Смысл рандомизации:

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

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

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

Язык эксперимента: гипотеза, метрики, дизайн

Гипотеза и критерий успеха

Связь с первой темой курса: без чёткой постановки задача превращается в спор.

Хорошая экспериментальная формулировка:

что меняем (изменение в продукте);

на что ожидаем влияние (целевой KPI);

какой знак эффекта ждём (рост или снижение);

когда считаем успехом (порог, временное окно).

Пример:

изменение: добавили подсказку в форме оплаты;

KPI: конверсия в успешную оплату;

ожидание: рост;

успех: рост минимум на 0.2 п.п. при приемлемом риске ошибок.

Типы метрик: целевая, guardrail, диагностические

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

Целевая метрика — то, ради чего делаем изменение.

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

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

Это продолжение идеи из темы про дашборды: один KPI без драйверов не объясняет, что делать дальше.

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

Ключевая техническая точка, которая связывает SQL, EDA и статистику: на каком уровне «случайность».

Единица рандомизации: кого распределяем по группам (обычно user_id, иногда session_id, реже device_id или account_id).

Единица анализа: на каком уровне считаем метрику (часто тоже пользователь).

Частая ошибка:

рандомизировали по пользователю, а анализируют по событиям;

это создаёт зависимости и делает выводы слишком уверенными.

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

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

Варианты, трафик и длительность

Перед запуском фиксируют:

какие варианты сравниваем (A/B или A/B/C);

доли трафика (например, 50/50);

длительность (часто минимум 1–2 полных недельных цикла из-за сезонности по дням недели);

окно измерения (например, «успех в течение 24 часов после попадания в эксперимент»).

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

Из темы про статистику: любое решение может ошибаться.

Уровень значимости — риск ложной тревоги (ошибка первого рода).

Мощность — шанс обнаружить реальный эффект (связано с ошибкой второго рода).

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

Ориентир: Statistical power).

Минимально значимый эффект (MDE)

Чтобы оценить, сколько данных нужно, команда заранее фиксирует минимальный эффект, который имеет смысл для бизнеса.

если эффект меньше MDE, то даже при «значимости» он может быть невыгоден;

если данных мало, тест будет часто давать «нет эффекта», даже когда он есть.

Важно: MDE — бизнес-решение, а не статистическое.

Остановка теста и запрет «подглядывания»

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

Практики:

заранее фиксировать дату окончания;

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

Ориентир: Sequential analysis.

Подготовка данных для A/B: слои, качество, воспроизводимость

Связь с темой ETL/ELT: экспериментальные данные должны быть стабильны и проверяемы.

Минимально нужны три сущности:

назначение в эксперимент: user_id, experiment_id, variant, assigned_at;

базовое событие знаменателя: например, визит или попадание на экран;

событие успеха: например, успешная оплата.

Критичные проверки качества

Перед интерпретацией результата проверьте базовые риски.

свежесть данных и полнота по дням;

дубликаты назначений в эксперимент;

доля пользователей без варианта;

резкие провалы объёма событий;

SRM.

SRM: Sample Ratio Mismatch

SRM — ситуация, когда фактические доли пользователей в группах заметно отличаются от запланированных (например, ожидали 50/50, получили 55/45).

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

Ориентир: Sample ratio mismatch.

!Схема процесса A/B-тестирования от распределения пользователей до решения

Как посчитать метрику A/B в SQL (и не ошибиться)

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

Предположим, есть таблицы:

ab_assignments(user_id, experiment_id, variant, assigned_at)

visits(user_id, visited_at)

payments(user_id, paid_at, amount, status)

Пример: конверсия в успешную оплату за 7 дней после назначения

Что здесь важно:

одна строка на пользователя в CTE base;

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

окно 7 дней фиксирует правило измерения.

Связь с SQL-темой: это способ избежать «размножения строк» и неверной единицы наблюдения.

Интерпретация результата: эффект, неопределённость, решение

Эффект и его размер

Для конверсии часто показывают два числа.

Абсолютный эффект: разница в процентных пунктах.

Относительный эффект: прирост в процентах к базе.

Если — конверсия в контроле, а — конверсия в тесте, то:

абсолютная разница: ;

относительная разница: .

Объяснение элементов:

и — доли успехов в группах A и B (успехи делим на пользователей);

показывает «насколько пунктов» изменилась конверсия.

Практика:

для бизнеса абсолютные пункты часто понятнее;

относительный эффект полезен для сравнения разных метрик и периодов.

Доверительный интервал важнее, чем «значимо/не значимо»

p-value отвечает на вопрос «насколько необычны данные при отсутствии эффекта», но не отвечает на вопрос «насколько велик эффект и выгодно ли внедрять».

Поэтому в итогах эксперимента полезно показывать:

оценку эффекта ;

доверительный интервал для ;

размер выборки.

Если интервал широкий и включает 0, это значит: данных недостаточно, чтобы уверенно различить эффект от шума.

Ориентиры: Confidence interval, P-value.

!Иллюстрация роли доверительного интервала при принятии решения

Практическая значимость и стоимость

Даже если эффект статистически значим, решение может быть «не выкатывать».

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

эффект слишком мал относительно стоимости внедрения;

ухудшились guardrail-метрики;

эффект есть только в маленьком сегменте и не масштабируется;

высокий риск побочных эффектов (например, рост возвратов).

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

Частые ловушки A/B-тестов

Множественные проверки

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

Практики:

заранее фиксировать одну основную метрику;

разделять анализ на подтверждающий и исследовательский;

при необходимости корректировать множественные сравнения.

Ориентир: Multiple comparisons problem.

Сегменты после факта

Фраза «в среднем эффекта нет, но в сегменте X есть» может быть правдой, а может быть случайной находкой.

Практики:

трактовать такие сегменты как гипотезы для следующего теста;

подтверждать повторным экспериментом.

Пересечение вариантов и загрязнение

Если пользователь видит и A, и B (например, на разных устройствах или при сбросе идентификатора), эффект размывается.

Практики:

выбирать правильный идентификатор для рандомизации;

контролировать «перетекание» пользователей;

анализировать долю пользователей с несколькими вариантами.

Проблемы логирования

Иногда тест «показал эффект», но на самом деле изменилось логирование.

Связь с EDA и качеством данных:

проверяйте, что объёмы событий и доля NULL не менялись только в одном варианте;

добавляйте диагностику данных прямо в отчёт эксперимента.

Как превратить результат в решение (шаблон)

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

Каркас итогового вывода

Контекст: что тестировали и зачем.

Дизайн: единица рандомизации, окно измерения, длительность, доли трафика.

Качество: SRM, полнота, пересечения вариантов.

Результат по целевой метрике: , , , доверительный интервал.

Guardrail: что ухудшилось или осталось нормальным.

Сегменты: только заранее заданные, остальные как гипотезы.

Решение: выкатываем, докатываем, откатываем, повторяем тест.

Следующий шаг: что проверяем дальше и какие данные нужны.

Три типовых исхода

Выкатываем: эффект положительный, guardrail в норме, качество данных ок.

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

Не выкатываем: эффекта нет или есть ухудшение guardrail, либо проблемы качества делают вывод недостоверным.

Как это связывается со всем курсом

A/B-тест — это точка, где сходятся все навыки аналитика.

Формулирование задачи даёт метрику, критерий успеха и ограничения.

ETL/ELT и качество данных обеспечивают доверие к эксперименту.

SQL даёт воспроизводимый расчёт выборки и метрик.

Статистика помогает честно выразить неопределённость.

EDA помогает увидеть проблемы, выбросы и неожиданные сегменты.

Визуализация и сторителлинг превращают результат в решение.

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