- Что такое SQL для маркетолога и зачем он нужен при анализе рекламных данных
- Какие задачи в контекстной рекламе решает SQL: примеры из практики
- Где взять данные для SQL-анализа рекламы
- Основы SQL для маркетолога: пять команд, которые закрывают большинство задач
- Как посчитать ROMI, CPL и CPA через SQL-запрос
- Типичные ошибки маркетолога при первых SQL-запросах
- SQL или Excel/Google Таблицы: когда переходить на SQL-анализ рекламы
- С чего начать изучение SQL маркетологу: пошаговый план
- Частые вопросы про SQL-анализ рекламных кампаний
- Заключение
Когда рекламных кампаний становится больше десятка, а данные лежат в трёх разных отчётах — статистике Директа, выгрузке из Метрики и CRM — сводные таблицы Excel начинают тормозить. Файл весит 40 МБ, формулы пересчитываются минуту, а любое изменение структуры данных рассыпает половину листов. В этот момент маркетологи обычно слышат совет «выучи SQL» и пугаются: кажется, что это про программирование, базы данных сервера и разработчиков.
Я работаю с контекстной рекламой и веду отчётность по десяткам аккаунтов Яндекс Директа, и SQL для меня — рабочий инструмент, а не программирование в чистом виде. Базовый набор из пяти команд закрывает 80% задач по объединению и агрегации рекламных данных, и освоить его можно за пару вечеров без курса и без бэкграунда в IT.
В этой статье — что такое SQL для маркетолога простыми словами, какие задачи в контекстной рекламе он решает, откуда брать данные для запросов и как написать первый SQL-запрос для расчёта CPL и ROMI по кампаниям.
Что такое SQL для маркетолога и зачем он нужен при анализе рекламных данных
SQL (Structured Query Language) — язык запросов к таблицам с данными. Для маркетолога это не язык программирования в привычном смысле, а способ задать вопрос к данным словами, максимально похожими на обычную речь: «выбери кампании, где расход больше 5000 рублей, и посчитай для каждой средний CPL».
Разница с Excel в подходе к масштабу. В таблицах вы работаете с готовым файлом и формулами внутри ячеек. В SQL вы храните данные в структурированных таблицах — например, отдельно клики по объявлениям, отдельно расходы по кампаниям, отдельно заявки из CRM — и связываете их запросом в момент анализа. Это тот же принцип, что использует Метрика при построении многоканальных последовательностей: данные из разных источников сводятся по общему идентификатору, а не копируются в один файл.
SQL для маркетолога нужен там, где Excel начинает буксовать: десятки тысяч строк кликов, объединение расхода по Директу с заявками из CRM, регулярные отчёты, которые нужно пересчитывать каждый день без ручной пересборки формул.
🔍 Где на практике живёт SQL
Базы данных, в которых удобно потренироваться: экспорт статистики Директа в Google BigQuery или ClickHouse, таблицы CRM (amoCRM, Битрикс24 при выгрузке через API) и любая локальная СУБД — PostgreSQL или SQLite с загруженным CSV. Для первых экспериментов достаточно бесплатного онлайн-редактора вроде SQLiteOnline — не нужно ставить сервер.
Какие задачи в контекстной рекламе решает SQL: примеры из практики
Первая и самая частая задача — свести расход по кампаниям Директа с заявками из CRM без ручного копирования. Пока источников два и записей меньше тысячи, это делается через ВПР (VLOOKUP) в Excel. Когда записей 15 000, а связка идёт по трём ключам (кампания, дата, UTM-метка), формулы начинают падать по таймауту, и здесь SQL-запрос с JOIN отрабатывает за секунды.
Вторая типичная задача — расчёт эффективности не по кампании целиком, а по срезу: например, по региону, по устройству или по товарной категории. Похожую логику разбирает статья про анализ рекламных расходов по товарным категориям — но там расчёт делается в готовом отчёте Метрики, а SQL позволяет собрать такой срез самостоятельно из сырых данных, если готового отчёта под нужную комбинацию признаков нет.
Третья задача — объединение маркетинговых данных с воронкой продаж: сколько заявок из каждой кампании дошли до сделки и с какой скоростью. Это прямое пересечение с темой SLA между маркетингом и продажами — SQL-запрос, объединяющий таблицу лидов и таблицу сделок по ID клиента, быстрее и надёжнее ручной сверки в двух файлах.
Четвёртая — расчёт метрик, которые не считаются напрямую в интерфейсе Директа: LTV по когортам, отток клиентов (об этом подробно — в статье про расчёт churn rate), эффективность звонков в связке с рекламным источником, как в материале про аналитику эффективности менеджеров по звонкам. Всё это — задачи объединения нескольких таблиц с последующей агрегацией, и это ровно то, для чего создан SQL. 
Где взять данные для SQL-анализа рекламы
Прежде чем писать запросы, нужны сами таблицы. Для контекстной рекламы это обычно три источника.
Статистика Директа. Выгружается через интерфейс (раздел «Статистика» → экспорт в XLSX/CSV) или через API Директа — тогда данные попадают в базу автоматически, без ручной выгрузки каждый день. Здесь лежат клики, показы, расход, CTR по кампаниям и группам объявлений.
Данные Метрики. Заявки, звонки, доходимость до целей — то, что превращает клики в конверсии. Если у вас настроен отчёт по посадочным страницам в Директе, эти же данные можно выгрузить в таблицу и связать по UTM-метке с расходами. Для более сложной атрибуции понадобится ещё и отчёт по ассоциированным конверсиям — если клиент видел несколько объявлений перед покупкой, простое сведение «одна конверсия — один клик» даст искажённую картину.
CRM. Финальная точка — доход. Сделка, сумма, статус. Без этой таблицы SQL-анализ рекламы упирается в лиды, а не в прибыль, а маркетологу для расчёта реального ROMI нужны именно деньги, дошедшие до кассы.
💡 Один общий ключ решает половину проблем
Прежде чем сводить три источника в SQL, убедитесь, что во всех есть общий идентификатор — UTM-метка кампании, ID лида или номер сделки. Без единого ключа JOIN просто не сработает, и придётся сначала чистить данные, а не считать метрики.
Основы SQL для маркетолога: пять команд, которые закрывают большинство задач
Базовый SQL-запрос строится из блоков, которые почти всегда идут в одном порядке: что показать (SELECT), из какой таблицы (FROM), по какому условию отфильтровать (WHERE), как сгруппировать (GROUP BY) и в каком порядке вывести (ORDER BY).
SELECT кампания, SUM(расход) AS общий_расход, SUM(конверсии) AS всего_заявок
FROM статистика_директа
WHERE дата BETWEEN ‘2026-06-01’ AND ‘2026-06-30’
GROUP BY кампания
ORDER BY общий_расход DESC;
Этот запрос отвечает на вопрос «сколько потратила каждая кампания за июнь и сколько принесла заявок» — без единой формулы, вставленной вручную. Дальше добавляется JOIN — команда, которая связывает две таблицы по общему полю. Она заменяет ВПР из Excel, но работает надёжнее: не «слетает» при добавлении новых строк и не требует точного совпадения диапазонов.
| Команда | Что делает | Пример для рекламных данных |
|---|---|---|
| SELECT | Выбирает нужные столбцы | Название кампании, расход, конверсии |
| WHERE | Фильтрует строки по условию | Только кампании с расходом выше 3 000 ₽ |
| GROUP BY | Группирует строки для агрегации | Сумма расхода по каждой кампании отдельно |
| JOIN | Связывает две таблицы по общему полю | Статистика Директа + сделки из CRM по UTM-метке |
| HAVING | Фильтрует уже сгруппированные данные | Кампании, где CPL после группировки выше 900 ₽ |
Разница между WHERE и HAVING — частая путаница у новичков: WHERE отсекает строки до группировки, HAVING — уже готовые агрегаты после SUM или AVG. Если написать условие по среднему CPL в WHERE, запрос просто не выполнится, потому что на этом этапе среднего ещё не существует.
Как посчитать ROMI, CPL и CPA через SQL-запрос
Ниже — обобщённый иллюстративный пример логики расчёта, а не описание конкретного реального проекта. Представим, что у нас есть таблица расходы (кампания, дата, сумма) и таблица сделки (кампания, дата, сумма_продажи). Задача — за один запрос получить CPL, CPA и ROMI по каждой кампании.
SELECT р.кампания,
SUM(р.сумма) AS расход,
COUNT(с.id) AS заявки,
SUM(с.сумма_продажи) AS доход,
SUM(р.сумма) / COUNT(с.id) AS cpl,
(SUM(с.сумма_продажи) — SUM(р.сумма)) / SUM(р.сумма) * 100 AS romi
FROM расходы р
LEFT JOIN сделки с ON р.кампания = с.кампания
GROUP BY р.кампания;
По этому расчёту в нашем примере кампания «Директ — поиск, консалтинг» при расходе 48 260 ₽ и 34 заявках дала CPL 1 420 ₽ и ROMI 187%, а кампания «РСЯ — брендовый охват» при расходе 22 900 ₽ и 6 заявках — CPL 3 816 ₽ и ROMI минус 41%. Такая разница видна только после объединения расходов с реальным доходом, а не с количеством лидов — если сравнивать кампании по CPL без ROMI, вторая кампания выглядит просто дороже, а не убыточной.
Важный нюанс — LEFT JOIN вместо обычного JOIN. Обычный JOIN покажет только кампании, у которых были сделки, и полностью «потеряет» кампании с нулевой конверсией — а именно они часто самые важные для решения об отключении. LEFT JOIN сохраняет все строки из левой таблицы (расходы), даже если совпадений в сделках не нашлось.
Типичные ошибки маркетолога при первых SQL-запросах
❌ Обычный JOIN вместо LEFT JOIN
Кампании без единой заявки просто выпадают из отчёта, и вы неосознанно анализируете только «выжившие» кампании — картина расходов искажается в лучшую сторону.
❌ Деление на ноль в расчёте CPL
Если у кампании 0 заявок, формула расход / заявки вызовет ошибку деления на ноль. Нужно оборачивать делитель в условие NULLIF или CASE, чтобы запрос не падал целиком из-за одной строки.
❌ Разное написание UTM-метки в разных таблицах
«direkt_poisk» в статистике Директа и «Direkt_Poisk» в CRM для SQL — два разных значения. JOIN не найдёт совпадений, и часть данных потеряется без явной ошибки — отчёт просто окажется неполным.
Ещё одна частая проблема — путаница между GROUP BY и агрегацией без группировки. Если в SELECT есть SUM(), но нет GROUP BY, а в списке столбцов помимо агрегата стоит негруппируемое поле — движок либо выдаст ошибку, либо (в некоторых СУБД) молча возьмёт произвольное значение этого поля, что даёт неверный, но правдоподобный результат. Такие ошибки опаснее явных сбоев, потому что их не видно без сверки с исходником.
SQL или Excel/Google Таблицы: когда переходить на SQL-анализ рекламы
SQL не заменяет таблицы полностью — для быстрой прикидки по одной кампании Excel всё ещё быстрее. Переход оправдан там, где данные растут в объёме и в количестве источников.
| Критерий | SQL | Excel/Google Таблицы |
|---|---|---|
| Объём данных | Сотни тысяч и миллионы строк без потери скорости | Тормозит и «зависает» после 100–200 тыс. строк |
| Объединение источников | JOIN по ключу за секунды, без ручного копирования | ВПР/VLOOKUP вручную, легко ошибиться в диапазоне |
| Повторяемость отчёта | Один раз написал запрос — запускаешь ежедневно | Формулы и фильтры настраиваются заново или ломаются |
| Порог входа | Нужно выучить синтаксис SELECT/JOIN/GROUP BY | Знаком большинству маркетологов «из коробки» |
| Риск ручной ошибки | Низкий — логика фиксируется в коде запроса | Высокий — легко сдвинуть строку или диапазон |
Практичный ориентир: если отчёт по рекламе занимает у вас больше 30–40 минут в неделю на ручное сведение таблиц из разных кабинетов — это сигнал, что пора автоматизировать процесс через SQL-запрос, который выполняется по расписанию и выгружает готовую таблицу в дашборд или на почту.
С чего начать изучение SQL маркетологу: пошаговый план
Учить SQL «с нуля до эксперта» маркетологу не нужно — достаточно освоить рабочий минимум, который закрывает 90% задач по анализу рекламы.
1. SELECT, WHERE, ORDER BY — базовая выборка и фильтрация данных по условию, сортировка по нужному столбцу.
2. GROUP BY и агрегатные функции — SUM, COUNT, AVG для сведения строк в сводные показатели по кампаниям, дням, каналам.
3. JOIN (INNER и LEFT) — объединение таблиц расходов и заявок по ключу, самый частый инструмент в связке «реклама — CRM».
4. Подзапросы и CASE WHEN — расчёт условных метрик типа ROMI, деление на группы «прибыльные / убыточные».
5. Практика на реальных данных — выгрузка из своего рекламного кабинета и CRM важнее любого учебного курса: ошибки на своих данных запоминаются быстрее.
Для практики не нужен сложный сервер — большинство рекламных кабинетов и CRM позволяют выгрузить данные в CSV, а бесплатные инструменты типа SQLite или встроенный SQL в Google BigQuery (с бесплатным лимитом) дают возможность потренироваться на своих же цифрах уже в первый день.
Частые вопросы про SQL-анализ рекламных кампаний
Нужно ли маркетологу устанавливать отдельный сервер базы данных для SQL-запросов?
Нет, для начала достаточно бесплатных инструментов без установки: Google BigQuery с бесплатным лимитом запросов, SQLite как локальный файл-база или встроенный SQL-редактор в самой CRM. Полноценный сервер нужен только тогда, когда объём данных и число пользователей отчётов вырастает настолько, что требуется постоянный доступ нескольким сотрудникам одновременно.
Сколько времени нужно, чтобы маркетолог сам написал первый рабочий SQL-запрос по рекламе?
При наличии готовых выгрузок из рекламного кабинета и CRM базовый запрос с SELECT, WHERE и GROUP BY на подсчёт CPL по кампаниям пишется за один-два вечера самостоятельного разбора синтаксиса. Более сложный отчёт с JOIN двух таблиц и расчётом ROMI обычно занимает одну-две недели практики с ошибками и их разбором — это нормальный темп для человека без технического образования.
Что делать, если UTM-метки в рекламном кабинете и в CRM записаны по-разному?
Самый надёжный вариант — привести регистр и формат меток к единому стандарту ещё на этапе настройки рекламных кампаний, до запуска. Если исторические данные уже накопились в разном виде, перед JOIN можно применить функции приведения строк к нижнему регистру (LOWER) и обрезки пробелов (TRIM) прямо в запросе — это устраняет расхождения без переделки старых кампаний.
Как избежать ошибки деления на ноль при расчёте CPL по кампаниям без заявок?
Нужно оборачивать делитель функцией NULLIF, которая заменяет ноль на NULL перед делением — в результате СУБД вернёт NULL вместо ошибки, и запрос отработает по всем строкам целиком. Альтернативный способ — конструкция CASE WHEN COUNT(с.id) = 0 THEN NULL ELSE расход/COUNT(с.id) END, которая даёт тот же результат более явным способом для тех, кто пока не помнит функцию NULLIF наизусть.
Можно ли анализировать рекламу через SQL, если данные хранятся в разных сервисах — Яндекс.Директе, ВКонтакте и CRM?
Да, именно для этого и нужен SQL: данные из разных источников выгружаются в единое хранилище (это может быть облачная база или даже локальный файл SQLite), а затем объединяются JOIN-ом по общему ключу — как правило, это UTM-метка кампании или дата с идентификатором клиента. Технически источник данных не имеет значения, важно только единообразие формата ключа для объединения.
Что важнее для решения об отключении кампании — CPL или ROMI?
ROMI важнее, так как учитывает не только стоимость привлечения заявки, но и реальный доход от сделок, которые из неё получились. Кампания с низким CPL может давать заявки, которые почти не закрываются в продажи, и в итоге окажется убыточной по ROMI — а кампания с более высоким CPL, но качественными заявками и высокой конверсией в оплату, может приносить прибыль. Решение об отключении стоит принимать по ROMI, а CPL использовать как дополнительный ориентир при равном ROMI у нескольких кампаний.
Заключение
SQL — это не навык программиста, а рабочий инструмент маркетолога, который хочет видеть реальную рентабельность рекламных кампаний, а не только количество кликов и заявок. Базовый набор из SELECT, GROUP BY, JOIN и CASE WHEN закрывает большинство задач по сведению расходов из рекламных кабинетов с доходом из CRM, и этот набор реально освоить самостоятельно за несколько недель практики на своих же данных.
Главный практический вывод — переходить на SQL стоит не ради самого языка, а ради того, чтобы отчёт по ROMI считался автоматически и по единой логике каждый раз, без риска сдвинутой строки в Excel или забытого фильтра. Начните с одного простого запроса, который объединяет вашу таблицу расходов с таблицей сделок, и постепенно добавляйте туда новые метрики — это быстрее, чем искать идеальный курс перед тем, как написать первую строку кода.
Хотите настроить сквозную аналитику и автоматический расчёт ROMI под вашу рекламу без лишних затрат времени? Свяжитесь с нами — поможем разобраться с данными и запросами.
Читайте также
→ Как правильно считать ROMI рекламной кампании: формулы и примеры
→ UTM-метки для сквозной аналитики: как настроить без ошибок
→ Сквозная аналитика для малого бизнеса: с чего начать
→ Как связать CRM и рекламные кабинеты для расчёта окупаемости
Автор: Павел Комарков — специалист по контекстной рекламе с 2010 года, работал с бюджетами от 50 000 ₽ до 150 млн ₽ в месяц. Подробнее →
