Выгрузка Google Ads в BigQuery 2026: настройка и SQL

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

Ниже — что именно даёт связка, чем Data Transfer Service отличается от API и коннекторов, как устроена схема таблиц, где в ней ловушки двойного счёта, шесть запросов, ради которых всё и затевается, и честный расчёт стоимости.

Честная граница: когда кабинета хватает

BigQuery нужен не всем. Если весь ваш анализ помещается в интерфейс, добавлять инфраструктуру — значит платить за сложность без отдачи.

Задача	Хватает кабинета	Нужна витрина
Ежедневный контроль расхода и CPA	Да	—
Свои формулы поверх метрик кабинета	Да, через кастомные столбцы	—
История глубже стандартных окон, сравнение сезонов год к году	Ограниченно	Да
Склейка с CRM, себестоимостью, возвратами, LTV	Нет	Да
Десятки аккаунтов в одном отчёте	Тяжело	Да
Автоматические алерты по своим правилам	Частично	Да
Хранение данных на случай потери доступа к аккаунту	Нет	Да

Если ваши потребности в первых двух строках — начните с кастомных столбцов и Редактора отчётов: это бесплатно и закрывает больше, чем принято думать. BigQuery начинается там, где нужны данные, которых в кабинете нет в принципе.

Три способа завести данные в BigQuery

Способ	Плюсы	Минусы	Кому
Data Transfer Service (нативный трансфер)	Настраивается за час, без кода, официальная поддержка, работает с MCC целиком	Схема фиксирована, обновление раз в сутки, набор отчётов ограничен	Большинству — стартовать надо отсюда
Google Ads API + свой загрузчик	Любые отчёты и поля, своя частота, своя схема	Разработка и поддержка, квоты API, обработка ошибок	Тем, кому не хватает набора DTS
Коннекторы (ELT-сервисы)	Много источников сразу, нормализация из коробки, частые обновления	Абонплата, зависимость от вендора, свои ограничения по полям	Агентствам с зоопарком источников

Практичный маршрут: DTS как основа, API-загрузчик для двух-трёх отчётов, которых не хватает, и коннектор — только если помимо Google Ads нужно ещё пять источников.

Как устроен Data Transfer Service

Что нужно на старте

Проект в Google Cloud с включённым биллингом (без биллинга трансфер не создастся, даже если объёмы укладываются в бесплатный уровень).
Права на создание трансферов в проекте и права записи в целевой датасет.
Учётка с доступом на чтение к рекламному аккаунту.
Идентификатор аккаунта: можно указать как обычный аккаунт, так и MCC — во втором случае трансфер тянет данные по всем связанным суб-аккаунтам сразу и складывает их в один датасет с полем идентификатора клиента.

Расписание и глубина обновления

Трансфер запускается по расписанию, практический стандарт — раз в сутки в утренние часы, после того как статистика за вчера стабилизировалась.
Окно обновления по умолчанию — 7 дней, его можно расширить примерно до 30. Смысл окна: каждый запуск перезаписывает не только вчерашний день, но и N предыдущих — потому что конверсии доезжают с лагом, и цифры за прошлую неделю ещё меняются.
Исторический бэкфилл запускается отдельно и идёт частями: длинные периоды заливаются часами, а иногда сутками. Планируйте это до того, как пообещаете отчёт «за три года» к завтрашнему утру.
Типовая ловушка: в бэкфилле конечная дата не включается — добавляйте один день.

Что появляется в датасете

Трансфер создаёт набор таблиц с префиксом ads_, партиционированных по дате. Условно они делятся на три группы:

Справочники сущностей — ads_Customer, ads_Campaign, ads_AdGroup, ads_Ad: названия, статусы, настройки, бюджеты. Обновляются снимком на дату.
Статистика — ads_CampaignBasicStats, ads_AdGroupBasicStats, ads_AdBasicStats, ads_KeywordStats и подобные: показы, клики, расход, конверсии, ценность.
Дополнительные срезы — статистика по устройствам, гео, аудиториям, поисковым запросам (состав зависит от версии трансфера и типов кампаний в аккаунте).

Практика: перед тем как строить отчёт, откройте список таблиц в датасете и посмотрите фактические имена и схемы — набор различается между аккаунтами, и слепо копировать чужой SQL из статьи (в том числе из этой) не стоит.

Ограничения, о которых лучше знать заранее

Схему нельзя выбрать: приезжает то, что приезжает, включая поля, которые вам не нужны.
Частота — раз в сутки. Внутридневного мониторинга на DTS не построить; для этого остаются скрипты Google Ads и правила в кабинете.
Не все отчёты кабинета имеют аналог в трансфере.
Данные приходят в валюте и часовом поясе аккаунта — при склейке нескольких аккаунтов это первое, что ломается.

Модель данных: где считают дважды

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

Не смешивайте уровни. Статистика по кампаниям и по ключевым словам — разные гранулярности. Суммировать расход из ads_KeywordStats и ждать совпадения с кампаниями не нужно: часть трафика не относится к ключевым словам.
Сегментированные таблицы дают дубли по деньгам. Если в таблице есть разбивка по устройствам или сети, сумма по всем строкам корректна только пока вы не соединили её с другой сегментированной таблицей. Соединения делайте по ключу и дате, а агрегацию — до соединения.
Конверсии и ценность зависят от атрибуции и от даты. Показатель за вчера меняется ещё неделю. Отсюда и окно обновления: если вы копируете данные из BigQuery дальше в отчёты, копируйте с тем же окном перезаписи.
Деньги в микро-единицах. В части полей суммы приходят умноженными на миллион — делите на 1 000 000 и приводите к одной валюте, если аккаунтов несколько.

Шесть запросов, ради которых всё затевается

1. Ежедневная сводка с маржинальным ROAS

Соединяем расход с данными о марже из вашей ERP и получаем то, чего кабинет не покажет никогда: рентабельность по кампаниям в реальных деньгах, а не в выручке.

SELECT date, campaign_name,
       SUM(cost) / 1e6                      AS spend,
       SUM(conv_value * margin_rate)        AS gross_profit,
       SAFE_DIVIDE(SUM(conv_value * margin_rate), SUM(cost) / 1e6) AS margin_roas
FROM   ads_daily_joined
WHERE  date BETWEEN start_date AND end_date
GROUP BY date, campaign_name

Как считать саму маржу и предельный CPA — в материале про юнит-экономику Google Ads.

2. Поисковые запросы, которые тихо забирают бюджет

Запрос находит фразы, где расход за последние 30 дней вырос относительно предыдущих 30, а конверсий нет. Это готовый список кандидатов в минус-слова, который в кабинете собирается руками и глазами.

3. Динамика доли потерянных показов

Кабинет показывает текущие значения, витрина — тренд по неделям и связь с изменениями бюджета. Так видно, когда именно кампания стала упираться в деньги, а не «кажется, недавно». Как читать сами метрики — в разборе доли показов и статистики аукционов.

4. Когорты по дате первого клика

Соединяем клики с CRM по идентификатору клика и смотрим, сколько денег принесла каждая недельная когорта через 30, 60, 90 дней. Это единственный способ честно сравнивать каналы с разной длиной сделки. Чтобы связка работала, идентификатор должен доезжать до CRM — как это проверить, разобрано в статье про GCLID, GBRAID и WBRAID.

5. Алерты по своим правилам

SELECT campaign_id, campaign_name, spend_today, median_28d
FROM   spend_stats
WHERE  spend_today > median_28d * 2
   AND conversions_today = 0

Результат такого запроса удобно слать в мессенджер по расписанию. Это не замена правилам кабинета, а дополнение: в BigQuery вы формулируете условия, которых в интерфейсе просто нет.

6. База для сезонной поправки

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

Что меняется в работе, когда выгрузка Google Ads в BigQuery настроена

Технически всё выглядит скучно: появились таблицы. Практически меняются четыре вещи, и именно ради них проект и делают.

Исчезает «подготовка отчёта». Вопрос клиента или руководителя перестаёт быть задачей на полдня: срез достаётся запросом или уже лежит в дашборде.
Появляется память. «Как мы это делали в прошлом ноябре» превращается из воспоминания в число. Это же снимает зависимость от того, кто вёл аккаунт полгода назад.
Метрики становятся общими. Маржинальный ROAS, посчитанный в витрине, одинаков у байера, аналитика и финансиста — заканчиваются споры о том, чей отчёт правильный.
Аномалии находятся раньше. Ежедневный запрос по всем аккаунтам ловит то, что глазами замечают на третий день: аккаунт с нулевым расходом, кампанию с удвоенным CPC, категорию товаров, вылетевшую из фида.

Чего выгрузка не делает — не улучшает кампании и не заменяет решений. Витрина отвечает на вопрос «что произошло», а «что с этим делать» остаётся человеку и инструментам кабинета вроде экспериментов Google Ads.

Инкрементальные обновления: как не пересчитывать всё каждый день

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

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

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

Сколько это стоит

Сам трансфер данных Google Ads в BigQuery отдельно не тарифицируется — платите за хранение и за запросы. Порядки величин (ориентиры, точные цифры смотрите в актуальном прайсе Google Cloud):

Хранение — центы за гигабайт в месяц, причём партиции, которые не менялись 90 дней, переходят в долгосрочное хранение примерно вдвое дешевле. Данные Google Ads по одному среднему аккаунту за год — обычно единицы гигабайт.
Запросы — оплата за просканированные данные (тарифицируется по терабайтам). Есть бесплатный месячный объём, в который небольшая команда со здоровыми запросами укладывается.
Главный источник неожиданных счетов — SELECT * по непартиционированному диапазону в дашборде, который обновляется каждые пять минут у пятнадцати человек.

Три правила гигиены, которые держат счёт в разумных пределах: всегда фильтровать по дате партиции, никогда не тянуть *, и строить дашборды не поверх сырых таблиц, а поверх заранее агрегированных витрин.

Looker Studio поверх витрины

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

Семь ошибок внедрения

Начать с идеальной модели данных. Три месяца проектирования — и никто не пользуется. Начинайте с одного отчёта, который болит прямо сейчас.
Не расширить окно обновления. Дефолтные 7 дней не покрывают длинный конверсионный лаг — в витрине останутся заниженные конверсии.
Считать деньги без деления на миллион. Классика первого дня.
Смешать валюты и часовые пояса при склейке аккаунтов. Приводите к одной валюте и одному поясу на уровне витрины, а не в дашборде.
Дублировать логику. Одна и та же метрика, посчитанная в трёх дашбордах по-разному, разрушает доверие к системе быстрее, чем её отсутствие.
Не хранить справочники. Названия кампаний меняются; если не сохранять снимки, история переписывается задним числом.
Забыть про доступы. Кто может читать датасет с данными по всем клиентам — это вопрос из той же серии, что и права в рекламных аккаунтах; см. безопасность доступов в Google Ads.

План внедрения за две недели

Дни	Что делаете
1–2	Проект GCP, биллинг, датасет, права. Создаёте трансфер на MCC, ставите ежедневное расписание.
3–4	Запускаете бэкфилл за 13–24 месяца. Пока идёт — описываете, какие три отчёта нужны бизнесу.
5–7	Сверяете суммы с кабинетом за 7 и за 30 дней. Расхождение больше 1–2% — разбираетесь до того, как строить дальше.
8–10	Собираете первую агрегированную витрину: день × аккаунт × кампания + ваши бизнес-метрики.
11–12	Подключаете Looker Studio к витрине, собираете один рабочий отчёт.
13–14	Ставите ежедневный пересчёт и один алерт. Записываете в документацию, что откуда берётся.

Сверка на шаге 5–7 — обязательная. Витрина, цифры которой не сходятся с кабинетом, хуже, чем её отсутствие: на неё ссылаются в решениях, а она врёт. Тот же принцип, что и в аудите рекламного аккаунта — сначала доверие к данным, потом выводы.

Если своих данных первой стороны в системе ещё нет, витрина решит половину задачи: считать вы сможете, а оптимизировать по этим данным — нет. Вторая половина — в материале про Data Manager и данные первой стороны. И отдельный сценарий, ради которого витрину заводят агентства — сведение отчётности по десяткам аккаунтов; как устроена такая структура, разобрано в статье про управляющий аккаунт MCC.

Разобрать связку на своих кампаниях и данных можно на обучении Google Ads от PPC Rebels; базовые настройки кабинета собраны в гайде по Google Ads.

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

FAQ: Google Ads и BigQuery

Нужен ли платный аккаунт Google Cloud?

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

Можно ли выгрузить сразу все аккаунты под MCC?

Да, при создании трансфера указывается идентификатор управляющего аккаунта, и данные по всем связанным суб-аккаунтам приезжают в один датасет с полем клиента. Это основной сценарий для агентств.

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

Трансфер работает по расписанию; практический стандарт — раз в сутки. Внутридневная аналитика через этот механизм не строится.

Что такое окно обновления и зачем его расширять?

Это количество прошлых дней, которые перезаписываются при каждом запуске. По умолчанию около 7 дней, расширяется примерно до 30. Расширять нужно, если ваши конверсии доезжают дольше недели — иначе в витрине они останутся недосчитанными.

Насколько глубоко можно залить историю?

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

Почему цифры в BigQuery не сходятся с кабинетом?

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

Можно ли обойтись коннектором Looker Studio без BigQuery?

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

Сколько это будет стоить в месяц?

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

Нужен ли аналитик или справится байер?

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

Что делать с данными других источников?

Заводить в тот же датасет и приводить к общей структуре: дата, аккаунт, кампания, расход, конверсии, ценность. Смысл витрины именно в общем знаменателе, а не в том, чтобы держать данные Google Ads в облаке.

Переживёт ли витрина потерю доступа к рекламному аккаунту?

Да, история остаётся в вашем проекте. Это одна из недооценённых причин делать выгрузку заранее, а не после того, как доступ понадобился.

С чего начать, если ресурсов мало?

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