ETL для маркетинга: что это такое и зачем оно нужно

Если открыть вакансию дата-инженера, там почти наверняка будет слово ETL. Звучит как что-то далёкое от рекламы и продаж. На деле это ровно та работа, которую маркетолог или аналитик выполняет руками, когда сводит расход Директа и продажи из CRM в одной таблице перед отчётом.

Что означают три буквы

ETL — это сокращение от Extract, Transform, Load («извлечь, преобразовать, загрузить»). Три шага, в таком порядке:

• Extract (извлечь). Забрать данные из источника — рекламного кабинета, счётчика аналитики, CRM. Это может быть выгрузка через API или просто файл, скачанный из личного кабинета.
• Transform (преобразовать). Привести данные к общему виду: одинаковые названия колонок, одинаковые единицы измерения, убрать дубли, посчитать нужные суммы. Именно здесь чаще всего расходятся ожидания и реальность.
• Load (загрузить). Сложить готовые данные туда, откуда их удобно смотреть и строить отчёты, — в таблицу, базу данных или дашборд.

Если вы когда-либо выгружали отчёт по кампаниям из Яндекс.Директа, копировали в него данные из Метрики и подписывали строки вручную — вы уже делали ETL, просто без автоматизации и без этого названия.

Почему ручной ETL со временем перестаёт работать

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

• Источников становится больше. Директ, Метрика, Ozon, retailCRM — у каждого свой формат выгрузки, свои названия полей, свой личный кабинет.
• Данные меняются задним числом. Директ уточняет расход за прошлые дни, статусы заказов в CRM меняются. Вчерашняя выгрузка сегодня уже неточная — а вручную это никто не перепроверяет.
• Ошибка не видна сразу. Файл скачался, таблица заполнилась — и то, что часть кампаний не попала в выгрузку из-за истёкшего токена доступа, заметят в лучшем случае через месяц.
• Это отнимает время специалиста, который должен анализировать рекламу, а не выравнивать колонки в Excel.

Как выглядит автоматический ETL на практике

Автоматизация не убирает эти три шага — она убирает из них человека:

1. Extract. Планировщик сам, по расписанию, обращается к API Яндекс.Директа, Яндекс.Метрики, Ozon и CRM и забирает свежие данные — без того, чтобы кто-то заходил в кабинет и жал «выгрузить».
2. Transform. Данные приводятся к единой схеме: расход — в одних единицах, даты — в одном формате, кампании — сопоставлены с визитами и заказами по UTM-меткам.
3. Load. Всё складывается в хранилище (в SBN BI это ClickHouse — база данных, заточенная под быстрые отчёты по большим объёмам), откуда строятся дашборды и выгрузки.

Почему данные приходится забирать заново

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

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

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

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

ETL, который сам себя чинит

Довесок, без которого ETL для рекламы не заслуживает доверия, — ежедневная сверка: система сама сравнивает, сколько денег потрачено по её данным и сколько говорит API Яндекс.Директа. Зачем это нужно и сколько расхождений находится на практике, разобрано в статье про ежедневную сверку расхода.

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

С 31 января мы сделали 52 755 проверок данных и 600 автоматических перезаборов по 19 проектам. Это и есть разница между «скрипт выгружает данные» и «процесс отвечает за то, что данные верны»: в первом случае расхождение ждёт, пока его заметят, во втором — устраняется само.

Данные на 6 сентября 2026.

Чем ETL отличается от сквозной аналитики

Термины часто путают, а разница простая:

• ETL — это про то, как данные попадают из точки А в точку Б и приводятся к общему виду. Это «водопровод».
• Сквозная аналитика — это про то, что с этими данными делать: строить воронку «показ → клик → визит → цель → заказ» и считать, какая реклама реально приносит деньги. Подробнее — в статье про сквозную аналитику.

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

Что чаще всего ломается

Четыре поломки, которые встречаются постоянно и объединены одним свойством: ни одна не выглядит как поломка.

• Истёк токен доступа. Доступ к кабинету выдаётся на время и привязан к человеку. Он тихо перестаёт работать, и выгрузка приносит пустоту — формально без ошибки.
• Кабинет переименовали. Логин рекламного кабинета поменялся, данные начали складываться «мимо». В отчёте их нет, хотя деньги тратятся.
• API не ответил. Лимиты, таймаут, разовый сбой на стороне сервиса. Одна кампания не доехала, остальные доехали — сумма занизилась ровно на неё.
• Изменилась структура данных на стороне источника. Появилось новое поле, поменялся формат — и часть строк перестала раскладываться правильно.

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

Частые вопросы

ETL — это про программирование, мне нужно нанимать разработчика?

Нет, если использовать готовый сервис вроде SBN BI: настройка сводится к тому, чтобы дать доступ к рекламным кабинетам и CRM, а забор и приведение данных к общему виду сервис делает сам. Писать код для этого не нужно.

Чем ETL отличается от «интеграции» или коннектора?

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

Как часто должны обновляться данные?

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

Что такое витрина данных?

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

Что будет, если один источник данных временно недоступен?

Хороший ETL-процесс не должен молча это скрывать. В SBN BI перерыв в данных виден в проверке качества данных, а не всплывает через месяц в разговоре с клиентом как сюрприз. Дальше пропущенный период забирается заново.

Можно ли собрать ETL самому, без сервиса?

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

Куда это ведёт

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

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