Data Transfer Serviceとは
BigQuery Data Transfer Service（DTS）は、Google広告などのデータをBigQueryへ定期転送するGoogle公式のマネージドサービスです。一度設定すれば、毎日自動でレポートデータがBigQueryに蓄積されます。スクリプト開発は不要で、Google広告用の転送自体は無料です。
広告データ基盤を作るなら、最初に設定すべき連携です。Meta広告やYahoo!広告と違って実装が不要なため、BigQueryに慣れる入口としても適しています。基盤全体の設計はBigQueryで広告データを集約する方法で解説しています。
この記事では、コンソールでの設定手順、転送されるテーブルの読み解き方、バックフィルの仕様、運用してわかる注意点までを一気通貫で説明します。
前提条件を確認する
設定に入る前に、必要な環境と権限を確認します。
| 項目 | 内容 |
|---|---|
| Google Cloudプロジェクト | 請求先アカウントの紐付けまで済んでいること |
| BigQuery Data Transfer API | プロジェクトで有効化されていること |
| BigQuery側の権限 | roles/bigquery.admin（または転送作成の個別権限） |
| Google広告側の権限 | 対象アカウント（またはMCC）への読み取り以上のアクセス |
| 転送先データセット | 事前に作成しておく（例: google_ads） |
権限まわりの要点は2つです。BigQuery側は、転送設定を作るユーザーに bigquery.admin 相当のロールが必要です。Google広告側は、転送を認可するGoogleアカウントが対象のcustomer IDにアクセスできる必要があります。広告運用者と基盤管理者が別の場合は、両方の権限を持つアカウントをどれにするか先に決めておくとスムーズです。
データセットの作成をコマンドで行いたい場合は、gcloud CLIの活用ガイドを参照してください。
設定手順
コンソールでの設定
Google Cloudコンソールでの設定は5分程度で完了します。
- BigQueryの画面左メニューから「データ転送」を開き、「転送を作成」を選択する
- ソースの種類で「Google Ads」を選択する
- 転送構成名（例:
google_ads_daily）と転送先データセットを指定する - customer IDを入力する（ハイフンなしの10桁）
- P-MAXを配信している場合は「Include PMax Campaign Tables」のチェックボックスをオンにする
- スケジュールを確認して保存し、Googleアカウントで認可する
customer IDにはMCC（マネージャーアカウント）のIDも指定できます。MCCを指定すると、配下にリンクされた全アカウントのデータが1つの転送でまとめて取り込まれます。公式ドキュメント上の上限は1つのマネージャーアカウントにつき8,000 customer IDです。代理店やインハウスで複数アカウントを扱う場合は、MCC単位での設定が管理しやすくおすすめです。
スケジュールは既定で24時間ごとに1回実行されます。実行時刻は作成時刻をもとに決まり、これより高い頻度にはできません。日次バッチとして扱う前提で設計してください。
bqコマンドでの設定
同じ設定はbqコマンドでも作成できます。構成をコードで管理したい場合はこちらが便利です。
bq mk --transfer_config \
--target_dataset=google_ads \
--display_name="google_ads_daily" \
--data_source=google_ads \
--params='{"customer_id":"1234567890"}'作成後の転送一覧や実行履歴の確認もbqコマンドで完結します。詳しくはgcloud CLIで広告データ基盤を管理するの転送管理セクションをご覧ください。
転送されるテーブルを読み解く
初回転送が完了すると、データセットに多数のテーブルとビューが作られます。最初は数に圧倒されますが、構造の原則を押さえれば迷いません。
テーブルとビューの2層構造
実体は p_ads_ プレフィックスのパーティション化されたテーブルに保存され、その上に ads_ プレフィックスのビューが作られます。普段のクエリはビューに対して書けば十分です。テーブル名の末尾には customer ID が付きます。
| よく使うビュー | 内容 |
|---|---|
ads_Campaign_{customer_id} | キャンペーンの属性（名前・ステータスなど） |
ads_CampaignBasicStats_{customer_id} | キャンペーン単位の実績（費用・表示・クリック） |
ads_CampaignConversionStats_{customer_id} | キャンペーン単位のコンバージョン |
ads_AdGroupBasicStats_{customer_id} | 広告グループ単位の実績 |
ads_Ad_{customer_id} / ads_AdBasicStats_{customer_id} | 広告の属性と実績 |
読み解きの最重要ポイントは、属性系（Campaign など）と実績系（BasicStats / ConversionStats）が分かれていることです。費用とCVを並べるには、属性・実績・CVの3種類をJOINする形になります。
日付フィルタと費用の単位
日付の絞り込みには _DATA_DATE 列を使います。パーティション列として機能するため、期間を絞ればスキャン量と費用を抑えられます。もう1つの必須知識が費用の単位です。費用フィールド（metrics_cost_micros）はmicros単位のため、円に直すには1,000,000で割ります。
SELECT
_DATA_DATE AS date,
campaign_id,
SUM(metrics_cost_micros) / 1000000 AS cost,
SUM(metrics_impressions) AS impressions,
SUM(metrics_clicks) AS clicks
FROM `your-project.google_ads.ads_CampaignBasicStats_1234567890`
WHERE _DATA_DATE BETWEEN "2026-07-01" AND "2026-07-23"
GROUP BY date, campaign_id
ORDER BY dateこの2点（_DATA_DATE とmicros）を知らないまま集計すると、管理画面と桁違いの数値が出て混乱します。導入時に必ず数日分を管理画面と突き合わせて、集計の正しさを確認してください。SQLの書き方全般はBigQueryのSQL実践ガイドで扱っています。
バックフィルと更新の仕様
直近7日は自動で取り直される
DTSには「refresh window（更新ウィンドウ）」という仕組みがあり、毎日の転送時に直近の日付をさかのぼって取り直します。既定は7日間で、最大30日間まで設定できます。
コンバージョンは計上が遅れて増えるため、この仕組みがないと直近の数値がすぐ古くなります。自作のAPI連携では自分で実装する「洗い替え」を、DTSは標準で備えていると理解してください。長いアトリビューション期間のCVを扱う場合は、ウィンドウを7日より延ばすことも検討します。
過去データのバックフィル
転送開始前の過去データは、バックフィル（過去分の転送実行）で取得します。転送設定の詳細画面から対象期間を指定して実行するだけです。数値のずれに気づいたときに、特定期間だけ取り直す用途でも使えます。
注意点として、Google広告側のデータ保持ポリシー変更により、37ヶ月より前のデータはバックフィルでも取得できなくなりました。過去データに価値がある場合は、消える前の取得をおすすめします。詳細はGoogle広告の37ヶ月データ制限で解説しています。
運用の注意点
実運用で気をつけるべきポイントを3つ挙げます。いずれも筆者が本番運用しているなかで実際に影響のあったものです。
| 注意点 | 対応 |
|---|---|
| 転送完了前にレポートが走る | 日次レポートは転送実行時刻より後に設定する |
| P-MAXの実績が通常テーブルに揃わない | 「Include PMax Campaign Tables」をオンにし専用テーブルを確認 |
| CVが実績系テーブルに見当たらない | ConversionStats 系のテーブルを参照する |
1つ目は時刻の設計です。転送は毎日ほぼ決まった時刻に実行されるため、その完了前に日次レポートのクエリが走ると、前日分が欠けたレポートになります。筆者の環境では転送が朝に実行されるため、後続のレポート処理は1時間以上ずらして組んでいます。転送実行履歴で自分の環境の実行時刻を確認し、余裕を持たせてください。
2つ目はP-MAXです。P-MAXキャンペーンは通常のテーブル群に実績が揃わないケースが公式のissue trackerでも報告されています。設定時にP-MAX用テーブルのオプションを必ずオンにし、P-MAX分の実績は専用テーブル側で確認する運用にすると安全です。
3つ目はテーブルの選び間違いです。CampaignBasicStats には費用・表示・クリックはありますが、CVは CampaignConversionStats 側にあります。ビューを眺めただけでは気づきにくいため、最初にJOINまで含めた集計クエリをテンプレート化しておくと、以降の分析が安定します。
蓄積が始まったら、Looker Studioでのダッシュボード化やAIエージェントとのMCP接続へ進むと、データの活用の幅が一気に広がります。
まとめ
Google広告のBigQuery自動転送について、設定から運用までを整理しました。
| 項目 | 要点 |
|---|---|
| 費用 | 転送は無料。BigQueryのストレージ・クエリ料金のみ |
| 設定 | コンソールで5分。MCC指定で複数アカウント一括も可 |
| スケジュール | 24時間ごとに1回。実行時刻を確認して後続処理を設計 |
| テーブル | 属性系と実績系の2種類。CVはConversionStats系 |
| 単位 | 費用はmicros。1,000,000で割る |
| 更新 | 直近7日は自動で取り直し。過去分はバックフィル |
公式連携ならではの手軽さと安定性があり、広告データ基盤の最初の一歩として最適です。設定が済んだら、管理画面との数値突き合わせで集計クエリを確定させ、他媒体の取り込みへ進んでいきましょう。