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

Есть профессиональная ошибка, которая дороже всех остальных вместе взятых. Она выглядит так: аналитик приносит цифру, цифра выглядит убедительно, компания на неё опирается — и цифра оказывается артефактом способа сбора данных, а не свойством мира. Никто не соврал. SQL корректный, график красивый, проценты сходятся. Просто данные не выдерживали того веса, который на них положили.

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

1. Пример, к которому мы будем возвращаться

Понедельник, сообщение в чате: «После релиза нового чекаута конверсия в оплату выросла с 4,0 до 4,5 процента. Раскатываем на всех?»

Цифра настоящая, запрос корректный. И тем не менее до решения ещё далеко — потому что как минимум восемь вещей объясняют эти 0,5 п.п. без всякого влияния нового чекаута:

1. Случайность. Если в выборке было 1000 пользователей, доверительный интервал для 4 процентов — примерно от 2,8 до 5,2. Разница в 0,5 п.п. целиком помещается внутрь шума.
2. Разный состав. Новый чекаут выкатили сначала на десктоп, а на десктопе конверсия всегда выше. Сравнили не версии, а платформы.
3. Сезон. Релиз совпал с выплатой зарплат или окончанием распродажи у конкурента.
4. Изменился знаменатель. Заодно починили баг, из-за которого часть заходов не логировалась: числитель прежний, знаменатель уменьшился, «рост» появился на ровном месте.
5. Поздние события. Платежи через банковский редирект долетают до хранилища с задержкой в часы. Вчерашний день ещё «недосчитан», позавчерашний — уже досчитан.
6. Подглядывание. Смотрели на метрику каждый день и остановились в тот день, когда она выглядела хорошо.
7. Множественные сравнения. Смотрели не одну метрику, а двадцать; одна «выстрелила» — это ожидаемо даже при полном отсутствии эффекта.
8. Выживший источник. Трекер не срабатывает у пользователей с блокировщиками, а они систематически другие.

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

2. Что такое прикладная аналитика и чем она не является

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

Хранилища, ETL, моделирование и качество на уровне пайплайна — трек Data Engineering, физика запросов и колоночных движков — Базы данных, обучение моделей — Machine Learning. Здесь мы занимаемся описательной и причинно-следственной аналитикой: что произошло, насколько мы в этом уверены, почему это произошло и что изменится, если вмешаться.

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

3. Карта трека

Порядок глав — это порядок, в котором вопрос проходит путь от постановки до решения.

• 01. Сначала вопрос — фильтр, который отсекает большую часть бесполезной аналитики: «какое решение изменится от ответа».
• 02. Откуда берутся данные — события, логи, выгрузки, опросы; почему любой источник это уже фильтр, отрезавший часть реальности.
• 03. Качество данных — пропуски, дубликаты, поздние события, изменение схемы задним числом.
• 04. SQL для анализа — агрегаты, оконные функции, воронки, антипаттерны вроде JOIN, размножающего строки.
• 05. Описательная статистика — почему среднее врёт и что ставить вместо него.
• 06. Распределения — тяжёлые хвосты, логнормальность выручки, почему p99 важнее среднего.
• 07. Неопределённость — доверительный интервал, бутстрап, размер выборки.
• 08. Проверка гипотез — что означает и чего не означает p-значение.
• 09. A/B-тесты — мощность, подглядывание, множественные сравнения, перекос в распределении групп.
• 10. Корреляция и причинность — контроль, естественные эксперименты и случай, когда причинность недоступна.
• 11. Когорты и удержание — как читать кривые и не спутать эффект когорты с эффектом времени.
• 12. Визуализация — как график врёт честными данными.
• 13. Дашборды — почему их не смотрят и что с этим делать.
• 14. Метрики и закон Гудхарта — цифра, которая меняет поведение системы.

4. Сквозная тема: что позволяет ваш способ сбора данных

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

Каждая ступень воронки — не просто потеря объёма. Потеря почти всегда неслучайна, и именно это ломает выводы. Пользователи с блокировщиками моложе и технически грамотнее. Отказавшиеся от cookies чувствительнее к приватности. Не долетевшие события чаще принадлежат тем, у кого плохая связь, — то есть жителям регионов с плохой связью. Любой из этих перекосов способен развернуть вывод на противоположный.

Правило, которое стоит держать в голове при каждом запросе:

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

Две детали здесь стоят всей схемы. Первая — два времени у события: occurred_at (когда произошло у пользователя) и received_at (когда доехало до нас). Без второго невозможно отличить «событий не было» от «события ещё не приехали». Вторая — таблица назначения вариантов отдельно от событий: без неё вы посчитаете конверсию по тем, кто дошёл до экрана, а не по тем, кому эксперимент был назначен, и получите классическое смещение отбора. Подробнее в главах 02 и 09, а про моделирование таблиц в хранилище — в Data Engineering.

5. Жизненный цикл аналитического ответа

Шаг 5 пропускают чаще всего, и именно он отличает аналитика от генератора отчётов. Прежде чем показывать вывод, попробуйте его сломать: посмотрите на разрезы, где эффект должен отсутствовать; проверьте метрики, которые не должны были измениться; попробуйте объяснить наблюдение без своей гипотезы.

6. Статистика, которая действительно нужна

Аппарат вероятности и статистики разбирается в Математике. Здесь — только то, что применяется руками, и то, вокруг чего чаще всего ошибаются.

6.1 Доверительный интервал — это признание неопределённости

Точечная оценка без интервала притворяется более точной, чем она есть. Для доли (конверсии) нормальное приближение даёт:

$$\hat{p} \pm z_{1-\alpha/2}\,\sqrt{\frac{\hat{p}\,(1-\hat{p})}{n}}$$

где $\hat{p}$ — наблюдаемая доля, $n$ — размер выборки, $z_{1-\alpha/2} \approx 1{,}96$ для 95 процентов.

Считаем на нашем примере: 1000 пользователей, 40 оплат, $\hat{p} = 0{,}04$.

$$\sqrt{\frac{0{,}04 \cdot 0{,}96}{1000}} = \sqrt{0{,}0000384} \approx 0{,}0062$$

Интервал: $0{,}04 \pm 1{,}96 \cdot 0{,}0062$, то есть примерно от 2,8 до 5,2 процента. Разница «4,0 против 4,5» на таком объёме — шум, и разговор о раскатке закрыт. Та же конверсия при 100 000 пользователей: стандартная ошибка $\approx 0{,}00062$, интервал от 3,88 до 4,12 процента. Ширина упала в десять раз, потому что $n$ вырос в сто: точность растёт как $\sqrt{n}$. Хотите вдвое точнее — нужно вчетверо больше данных; это важнейшая практическая константа профессии.

Честная интерпретация: «95-процентный» относится к процедуре, а не к конкретному интервалу. Если повторять эксперимент много раз, 95 процентов построенных так интервалов накроют истинное значение. Про этот интервал сказать «истина внутри с вероятностью 0,95» строго говоря нельзя — это байесовское утверждение, требующее априорного распределения. Разбор — глава 07.

6.2 p-значение: что оно означает и чего не означает

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

Чего p-значение не означает — список стоит выучить:

• Это не вероятность того, что нулевая гипотеза верна: условие стоит с другой стороны черты.
• Это не вероятность того, что результат случаен.
• Это не размер эффекта. Значимость и важность — разные вещи.
• $p = 0{,}049$ и $p = 0{,}051$ — это не «есть эффект» и «нет эффекта». Порог 0,05 — соглашение, а не закон природы.
• Большое p — не доказательство отсутствия эффекта. Это может быть просто маленькая выборка.

Иллюстрация к пункту про размер эффекта: две группы по 10 миллионов пользователей, конверсии 4,00 и 4,02 процента. Стандартная ошибка разности долей:

$$\text{SE} = \sqrt{\bar{p}\,(1-\bar{p})\left(\frac{1}{n_1}+\frac{1}{n_2}\right)} = \sqrt{0{,}0401 \cdot 0{,}9599 \cdot 2 \cdot 10^{-7}} \approx 8{,}8 \cdot 10^{-5}$$

Отсюда $z = 0{,}0002 / 0{,}000088 \approx 2{,}28$, двусторонний $p \approx 0{,}023$. Результат статистически значим — и при этом абсолютный прирост составляет 0,02 п.п. Окупит ли он полгода разработки, статистика не решает: это вопрос экономики. Позиция Американской статистической ассоциации на этот счёт написана прямым языком и стоит десяти минут чтения: The ASA Statement on p-Values. Подробный разбор — глава 08.

6.3 Множественные сравнения

При проверке одной гипотезы с порогом $\alpha = 0{,}05$ вероятность ложной находки — 5 процентов. При $m$ независимых проверках вероятность хотя бы одной ложной находки равна $1 - (1-\alpha)^m$: для 5 метрик это $1 - 0{,}95^5 \approx 23$ процента, для 20 метрик — $1 - 0{,}95^{20} \approx 64$ процента. То есть при двадцати проверяемых метриках «что-то значимое» найдётся почти наверняка, даже если релиз не делает ровным счётом ничего.

Отсюда практика: одна заранее объявленная основная метрика, остальные — вспомогательные и защитные, с поправкой. Простейшая поправка Бонферрони сравнивает p с $\alpha/m$, то есть с 0,0025 для двадцати метрик; она консервативна, и в A/B-практике чаще контролируют FDR по процедуре Бенджамини — Хохберга.

Опаснее формальных множественных сравнений их неформальный брат — сад расходящихся тропок: аналитик не проверяет двадцать гипотез явно, но перебирает разрезы, окна и фильтры, пока картинка не «сложится». Формально проверена одна гипотеза, фактически — десятки. Механику описал Эндрю Гельман в The garden of forking paths.

6.4 Подглядывание в A/B и размер выборки

Если смотреть на результат теста каждый день и останавливать его в момент, когда p впервые опустилось ниже 0,05, фактическая доля ложноположительных результатов взлетает. Классические оценки Армитеджа, Макферсона и Роу (1969) для последовательных проверок при номинальном $\alpha = 0{,}05$:

Причина в том, что случайное блуждание разности рано или поздно заденет границу. Вывод жёсткий: длительность теста фиксируется до старта, а если смотреть в середине необходимо — применяются методы, которые это учитывают (групповые последовательные границы, always-valid p-values). Самое цитируемое объяснение с симулятором — How Not To Run An A/B Test Эвана Миллера.

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

$$n \approx \frac{2\,(z_{1-\alpha/2} + z_{1-\beta})^2\,\bar{p}\,(1-\bar{p})}{\delta^2}$$

где $\delta$ — минимальный эффект, который вы хотите уметь обнаружить (MDE), $\bar{p}$ — базовая конверсия, $z_{1-\beta} \approx 0{,}84$ для мощности 80 процентов. Считаем для базовой конверсии 4 процента и MDE в 10 процентов относительно, то есть $\delta = 0{,}004$:

$$n \approx \frac{2 \cdot (1{,}96 + 0{,}84)^2 \cdot 0{,}04 \cdot 0{,}96}{0{,}004^2} = \frac{2 \cdot 7{,}84 \cdot 0{,}0384}{0{,}000016} \approx 37\,600$$

Около 38 тысяч пользователей на группу, 76 тысяч всего. А если ловить эффект вдвое меньше ($\delta = 0{,}002$), знаменатель уменьшается вчетверо: нужно уже 150 тысяч на группу. Это главный источник разочарования в A/B — у большинства продуктов трафика физически не хватает на эффекты, ради которых тест затевался. Честный ответ на такой расчёт не «запустим на неделю и посмотрим», а «этот вопрос A/B-тестом не решается, ищем другой способ». Разбор — глава 09.

7. Корреляция и причинность: что делать, а не что сказать

Фразу «корреляция не означает причинности» знают все, и она бесполезна, потому что не говорит, что делать дальше. Дальше — вот что.

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

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

Сравниваем две версии интерфейса по наблюдательным данным (версию B видели те, кто попал на новый лендинг):

Проверьте арифметику: B выигрывает на десктопе, B выигрывает на мобильных — и B проигрывает в сумме. Ошибки нет. Причина в составе: в группе A две трети трафика десктопные, в группе B четыре пятых мобильные, а мобильная конверсия втрое ниже на обеих версиях. Агрегат сравнивает не версии, а платформы.

Следствия два. Первое: любой наблюдательный вывод проверяется в разрезах, и если знак меняется — верить нужно разрезам, а не итогу. Второе: рандомизация снимает эту проблему автоматически, потому что делает состав групп статистически одинаковым. Это и есть главная ценность A/B — не «научность», а балансировка всего, о чём вы не подумали.

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

8. SQL: рабочий инструмент, а не формальность

Ниже — четыре запроса на PostgreSQL, покрывающие большую часть повседневной работы. Оконные функции и антипаттерны подробно разбирает глава 04.

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

WITH steps AS (
    SELECT
        user_id,
        min(occurred_at) FILTER (WHERE event_name = 'view_cart')       AS t_cart,
        min(occurred_at) FILTER (WHERE event_name = 'checkout_start')  AS t_checkout,
        min(occurred_at) FILTER (WHERE event_name = 'payment_success') AS t_paid
    FROM events
    WHERE occurred_at >= DATE '2026-07-01'
      AND occurred_at <  DATE '2026-07-08'   -- полуинтервал: не теряем и не задваиваем границу
    GROUP BY user_id
)
SELECT
    count(*) FILTER (WHERE t_cart IS NOT NULL)                        AS step_1_cart,
    count(*) FILTER (WHERE t_checkout >= t_cart)                      AS step_2_checkout,
    count(*) FILTER (WHERE t_paid >= t_checkout AND t_checkout >= t_cart) AS step_3_paid
FROM steps;

Сравнение с NULL даёт NULL, а NULL внутри FILTER не считается истиной — поэтому пользователи без нужного шага отсекаются сами, без дополнительных IS NOT NULL.

Среднее против медианы. Один запрос сразу показывает, врёт ли вам среднее:

SELECT
    count(*)                                            AS purchases,
    round(avg(amount), 2)                               AS mean_amount,
    percentile_cont(0.5) WITHIN GROUP (ORDER BY amount) AS median_amount,
    percentile_cont(0.9) WITHIN GROUP (ORDER BY amount) AS p90_amount,
    max(amount)                                         AS max_amount
FROM purchases
WHERE created_at >= DATE '2026-07-01';

Если mean_amount заметно больше median_amount, распределение скошено вправо и «средний чек» описывает несуществующего пользователя. Тема глав 05 и 06.

Когортное удержание по неделям — классическая таблица «когорта × номер недели»:

WITH first_seen AS (
    SELECT user_id,
           date_trunc('week', min(occurred_at))::date AS cohort_week
    FROM events
    GROUP BY user_id
),
weekly_activity AS (
    SELECT DISTINCT
           user_id,
           date_trunc('week', occurred_at)::date AS active_week
    FROM events
)
SELECT
    f.cohort_week,
    (a.active_week - f.cohort_week) / 7 AS week_number,  -- разность дат в PostgreSQL даёт целое число дней
    count(DISTINCT a.user_id)           AS active_users
FROM first_seen f
JOIN weekly_activity a USING (user_id)
GROUP BY f.cohort_week, week_number
ORDER BY f.cohort_week, week_number;

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

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

SELECT
    date_trunc('day', occurred_at)::date AS day,
    count(*)                                                             AS total_events,
    count(*) FILTER (WHERE received_at > occurred_at + INTERVAL '1 hour') AS late_over_1h,
    round(100.0 * count(*) FILTER (WHERE received_at > occurred_at + INTERVAL '1 hour')
          / count(*), 2)                                                 AS late_pct
FROM events
WHERE occurred_at >= current_date - INTERVAL '14 days'
GROUP BY day
ORDER BY day;

Если late_pct за последние сутки заметно выше обычного, вчерашняя точка на графике ещё «растёт» — сравнивать её с прошлой неделей нельзя. Подробности — глава 03; про то, почему такие запросы на больших объёмах пишутся иначе, — индексы и планы запросов.

9. Визуализация: график врёт честными данными

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

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

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

Неверный тип графика. Круговая диаграмма с двенадцатью сегментами не читается никем: человек плохо сравнивает углы и площади. Двойная ось Y позволяет «доказать» любую корреляцию подбором масштабов. Гладкая интерполяция между точками рисует значения, которых не было. Тип графика выбирается из вопроса, а не из красоты.

Агрегация, скрывающая распределение — самая коварная. Совершенно разные данные могут иметь одинаковые сводные статистики: квартет Энскомба и его современное продолжение Datasaurus Dozen — наборы точек с одинаковыми средними, дисперсиями и корреляцией, но абсолютно разными формами. Столбик со средним временем ответа скрывает, что у половины пользователей всё быстро, а у второй половины катастрофа. Лечение простое: где можно, показывайте распределение (гистограмма, боксплот, набор перцентилей), а не одну точку.

Разбор всех трёх механик — глава 12; метрики самого интерфейса — соседний трек, UX-метрики.

10. Дашборды: честно о том, почему их не смотрят

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

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

Что отличает дашборды из первого квадранта: у каждого блока есть владелец решения — конкретный человек, который на основании числа что-то делает; есть порог, заранее записанный («при значении ниже X делаем Y»), потому что без порога цифра не информация, а фон; показан контекст — не «конверсия 4,1 процента», а «4,1 при норме 3,9–4,3», желательно с интервалом; есть срок жизни — дашборд под проект удаляется вместе с проектом; и он проверяется тестами на данные, а не только на код.

Разбор — глава 13; про продуктовые метрики как таковые — Продуктовые метрики и Аналитика и решения.

11. Метрика меняет систему

Последняя глава трека — про то, что аналитик обнаруживает обычно поздно: измерение не нейтрально. Как только цифра становится целью, поведение системы под неё подстраивается, и цифра перестаёт измерять то, ради чего вводилась. Это закон Гудхарта, и в инженерных командах он воспроизводится идеально: метрика «время закрытия тикета» рождает тикеты, закрытые без решения; «покрытие тестами» — тесты без проверок; «число релизов» — дробление одного релиза на пять.

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

12. Как читать трек

Аналитику с опытом имеет смысл идти по порядку, уделив особое внимание главам 07–10: именно там сосредоточены ошибки, которые невозможно заметить изнутри собственной работы. Инженеру, которому аналитика нужна прикладным образом, хватит маршрута 01, 03, 04, 07, 09, 12 — этого достаточно, чтобы не сделать ложный вывод и не поверить чужому. Продуктовому менеджеру — 01, 05, 09, 10, 13, 14. Всем без исключения — глава 01: без неё трек превращается в набор техник без применения.

Работа с заказчиком и выяснение настоящего вопроса за формулировкой «дайте выгрузку» — соседний трек, Системный анализ.

13. Чек-лист вывода, на который не стыдно опереться

1. Какое решение изменится от этого ответа? Если никакое — зачем мы это считали?
2. Как получены данные и кого в них систематически нет?
3. Совпадает ли знаменатель до и после? Не менялась ли схема, не чинили ли логирование?
4. Проверен ли SQL на дубликаты после JOIN и на потерянные строки после WHERE?
5. Указан ли интервал или разброс, а не только точечная оценка?
6. Хватает ли размера выборки для эффекта, который мы обсуждаем? Считали ли MDE заранее?
7. Сколько гипотез и метрик проверено на самом деле, с учётом разрезов и итераций?
8. Фиксировалась ли длительность теста заранее или мы остановились на удачном дне?
9. Сохраняется ли вывод во всех значимых разрезах или знак где-то переворачивается?
10. Утверждаем ли мы причинность и имеем ли на это право по схеме из раздела 7?
11. Что должно было измениться и не изменилось? Что не должно было и изменилось?
12. Что сделает система, если начать оптимизировать эту метрику?

14. Типичные ошибки

• Вывод про всех по данным о выживших — опрос довольных клиентов, анализ активных, ретроспектива успешных проектов.
• Сравнение групп, которые собрались сами — пользователи фичи против непользователей это сравнение людей, а не фичи.
• Точечная оценка без неопределённости — «конверсия выросла на 12 процентов» без упоминания, что интервал включает ноль.
• Средние по скошенным распределениям — средняя выручка на пользователя при наличии корпоративных клиентов.
• Смена определения метрики без версионирования — через полгода никто не помнит, почему в марте случился «скачок».
• Сравнение неполного периода с полным — вчерашний день против позавчерашнего при задержке событий.
• Дашборд вместо ответа — заказчику нужен был один вывод, а ему выдали двадцать графиков и право выбрать самому.

Источники

• Ronald Wasserstein, Nicole Lazar. The ASA Statement on p-Values, The American Statistician, 2016.
• Alex Reinhart. Statistics Done Wrong — короткая книга ровно про ошибки из этого трека, доступна онлайн.
• Ron Kohavi, Diane Tang, Ya Xu. Trustworthy Online Controlled Experiments — практический стандарт по A/B-тестированию.
• Evan Miller. How Not To Run An A/B Test — про подглядывание, с симулятором.
• Andrew Gelman, Eric Loken. The garden of forking paths.
• Scott Cunningham. Causal Inference: The Mixtape и Nick Huntington-Klein. The Effect — обе бесплатны онлайн и обе про причинность без эксперимента.
• Justin Matejka, George Fitzmaurice. Same Stats, Different Graphs.
• Edward Tufte. The Visual Display of Quantitative Information; Alberto Cairo, How Charts Lie.
• Документация PostgreSQL: агрегатные функции и FILTER, оконные функции.

Мини-итог

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

Что дальше

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