Практика

• #1 Практика: Аудит "пустого" трафика (WHERE =)
• #Практика: Фильтрация чисел (WHERE >)
• #Практика: Текстовые фильтры (WHERE =)
• Базовые правила SELECT для аналитика

#1 Практика: Аудит "пустого" трафика (WHERE =)

Задача

Менеджер заметил странный трафик 5 января 2026 года: переходы были, а продаж нет. Нужно подтвердить это цифрами из базы.

Требование: Вывести источник, дату, визиты и продажи. Отфильтровать строго за '05.01.2026'.

Рабочее решение (SQL)

SELECT source_raw, date_raw, visits_raw, goal_sales_raw
FROM analytics_events
WHERE date_raw = '05.01.2026'
LIMIT 5

Разбор логики

• SELECT ... — перечисляем поля. Важно: обязательно включили goal_sales_raw. Если мы хотим доказать отсутствие продаж, колонка с продажами должна быть в отчете, иначе цифры не видно.
• WHERE date_raw = '...' — жесткий фильтр. Используем кавычки, так как дата в базе хранится текстом. Оператор = оставляет только точное совпадение.
• LIMIT 5 — бережем ресурсы базы, выводим только примеры строк.

Грабли (Типичная ошибка)

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

#Практика: Фильтрация чисел (WHERE >)

Задача

Найти источники трафика с высокой доходностью (выручка более 50 000 руб.).

Рабочее решение (SQL)

SELECT source_raw, users_raw, revenue_raw
FROM analytics_events
WHERE revenue_raw > 50000
LIMIT 3

Главные выводы (Запомнить!)

• Числа пишутся голыми: Никаких кавычек, никаких пробелов (50 000 — нельзя, 50000 — можно).
• Операторы сравнения: Для поиска "больше" используем >, для поиска "ровно" — =.
• Порядок: Условие WHERE всегда идет после FROM, но до LIMIT.

Типичная ошибка

Попытка написать число с пробелом или валютой (50 000 руб.). SQL — это калькулятор, он понимает только чистые цифры.

#Практика: Текстовые фильтры (WHERE =)

Задача

Выявить записи с аномальным показателем отказов (100%), чтобы понять, в какие дни и из каких источников шел некачественный трафик.

Рабочее решение (SQL)

SELECT date_raw, source_raw, bounce_rate_raw
FROM analytics_events
WHERE bounce_rate_raw = '100,00%'
LIMIT 7

Главные выводы

• Текст = Кавычки: Любое значение с буквами, знаками %, запятыми или дефисами — это строка. Её всегда в 'одинарные кавычки'.
• Точное совпадение: Оператор = найдет только те строки, где написано символ-в-символ так, как ты указал. Если в базе "100%", а ты ищешь "100.0%", запрос ничего не найдет.

Типичная ошибка

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

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

1. Любой запрос начинается с бизнес-вопроса

Плохие запросы отвечают на «что SQL смог».
Хорошие — на «что я хочу понять».

---

2. SELECT — только нужные поля

• не тащи всё

• каждое поле должно быть объяснимо бизнесу

• если не можешь объяснить — оно лишнее

---

3. FROM — всегда реальная таблица

• не поле

• не предположение

• проверяем фактами, а не памятью

---

4. ORDER BY обязателен почти всегда

Без сортировки:

• порядок строк не гарантирован

• LIMIT теряет смысл

• отчеты становятся случайными

---

5. Направление сортировки указывай явно

ORDER BY date_raw DESC

Почему:

• ASC ставится по умолчанию

• SQL решает за тебя

• он не знает, что ты маркетолог

---

6. Иерархия сортировки

Всегда сверху вниз по смыслу:

1. Время (date_raw)

2. Деньги (revenue_raw)

3. Конверсии (goal_sales_raw)

4. Трафик (visits_raw)

ORDER BY date_raw DESC, revenue_raw DESC

7. LIMIT — только после сортировки

Иначе ты смотришь:

• не «последние дни»

• а «первые попавшиеся строки»

---

8. Рабочий запрос ≠ правильный отчет

SQL может выполниться:

• без ошибок

• быстро

• красиво

И при этом быть логически неверным.

---

Контрольное правило (запомни намертво)

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