Серия «Аналитика FM»

А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков.
В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках.
Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!

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

Продажи "просели".
Конверсия "стала хуже".
Клиенты "ведут себя странно".

Это язык боли, а не требований.

И тут аналитик хочет обезопасить себя со всех сторон:
- написать запрос
- вытащить все данные
- построить отчёт "на всякий случай"
- показать цифры и сказать: "Вот"

Но в реальности это почти всегда заканчивается одинаково:
- "А это не совсем то"
- "А можно по-другому?"
- "А мы вообще не это имели в виду"

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

Ты начинаешь переводить бизнесовые ощущения в конкретные показатели, и смотреть как эти показатели подтверждают/опровергают эти ощущения. Ты переводишь эмоции в конкретные метрики. Подсознательное ощущение "что-то не так", ты переводишь в конкретные вопросы к данным.

И вот на этом этапе SQL становится не просто инструментом, а следствием мышления.

Очень часто проблема не в том, что запрос неправильный.
А в том, что вопроса не существовало.

Например:

• "Продажи упали" - относительно чего?

• "Конверсия плохая" - на каком этапе?

• "Клиенты уходят" - кто именно и когда?

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

И это самый важный навык аналитика. Аналитик не должен просто писать сложные JOIN-ы, он должен уметь задавать вопросы так, чтобы:
- стало понятно, что именно ищем
- появилось ощущение направления
- сузилось пространство неопределенности.

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

Тогда аналитик делает не отчёт, а гипотезу.

Я предполагаю, что проблема может быть здесь.
Давайте проверим это.

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

Самое важное:
если бизнес не знает, что ему нужно - это не ошибка бизнеса.

Это точка, где аналитика становится ценностью!

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!

Рассмотрим задачу.

Есть таблица заказов. Нужно:

1. Взять только оплаченные заказы

2. Посчитать сумму заказов по пользователям

3. Оставить пользователей, у которых сумма больше 10 000

4. Отсортировать по убыванию суммы

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

SELECT

user_id,

SUM(amount) AS total_amount

FROM orders

WHERE status = 'paid'

GROUP BY user_id

HAVING SUM(amount) > 10000

ORDER BY total_amount DESC;

Что происходит на самом деле?

Хотя запрос написан сверху вниз, выполняется он иначе:

1. FROM — база берёт таблицу orders

2. WHERE — отфильтровывает только status = 'paid'

3. GROUP BY — группирует строки по user_id

4. SUM(amount) — считает сумму внутри каждой группы

5. HAVING — отбрасывает группы с суммой ≤ 10 000

6. SELECT — формирует финальные колонки

7. ORDER BY — сортирует результат

SQL не идёт шаг за шагом как сценарий. Для него каждый запрос - это единый слепок результата

Ты не "живешь" внутри процесса, ты его декларируешь.

Теперь тот же самый запрос в Python (pandas)

Чтобы не увеличивать объем строк с подключением к БД, сделаем так, что наши данные мы читаем из CSV файла

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

import pandas as pd

df = pd.read_csv('orders.csv')

2. Фильтрация

paid_orders = df[df['status'] == 'paid']

paid_orders.head()

Здесь отфильтровали данные, можно посмотреть, что получилось, можно вернуться назад.
Это состояние сохранилось.

3. Группировка и агрегация

grouped = (

paid_orders

.groupby('user_id')['amount']

.sum()

.reset_index(name='total_amount')

)

grouped.head()

Ты видишь промежуточный результат:

• пользователей

• их суммы

• можешь проверить аномалии

4. Фильтр по агрегату

filtered = grouped[grouped['total_amount'] > 10000]

filtered.head()

5. Сортировка

result = filtered.sort_values('total_amount', ascending=False)

result

Ключевая разница

SQL

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

Python

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

На практике аналитик:
- думает как в Python
- реализует как в SQL
- и постоянно переключается между этими моделями

Получается, что SQL и Python - это два разных способа мышления.
SQL говорит нам - вот результат
Python - вот процесс.

Python - это процедурный подход.
Аналитик говорит КАК делать:
- возьми данные
- отфильтруй
- посчитай
- отсортируй
- покажи результат
Здесь происходить управление процессом: мы ведем данные по шагам

SQL - декларативный подход.
Аналитик не говорит КАК делать, он говорит, что хочет получить.

В разбираемом примере мы говори:

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

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

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!