Yahoo!広告データをBigQueryに取り込んでGoogle広告と統合分析する

はじめに：複数媒体を別々に見るのは想像以上に非効率

検索広告を出していると、Google広告とYahoo!広告の両方を運用しているケースは少なくありません。ところが、いざ「先月はどちらが効率よく売上につながったのか」を知ろうとすると、片方の管理画面を開いて数字を控え、もう片方を開いて控え、スプレッドシートで足し合わせる、という作業になりがちです。

この作業には、いくつか地味な問題があります。

媒体ごとに画面の項目名や集計の単位が違い、突き合わせるだけで手間がかかる
手でコピーするたびに、貼り間違い・期間のずれといったミスが入り込む
「キャンペーン横断で合計いくら使って、何件売れたか」をパッと出せない

毎週・毎月これを繰り返していると、本来やりたい「どこに予算を寄せるか」の判断より、集計作業のほうに時間を取られてしまいますよね。

この記事では、Yahoo!広告のデータをBigQueryに取り込み、Google広告と同じ場所・同じ形にそろえて、横断で見られるようにする設計を紹介します。一度仕組みを作ってしまえば、媒体をまたいだ集計がSQL一本で出せるようになります。

なお、各媒体のAPIやレポート機能の仕様は更新が頻繁です。実装の際は必ず最新の公式ドキュメント（Yahoo!広告ヘルプ／API、Google広告ヘルプ／Data Transfer）を確認してください。

Yahoo!広告データの取得手段

まず、Yahoo!広告のデータをどうやって手元に持ってくるかです。Google広告には BigQuery Data Transfer Service（DTS）という公式の自動転送がありますが、Yahoo!広告には、これに相当する「ボタンひとつでBigQueryへ」という仕組みは用意されていません。そのため、取得手段を自分で選ぶ必要があります。

大きく分けて、次の2つのルートがあります。

レポートのダウンロードを使う

Yahoo!広告の管理画面、またはレポート機能から、実績データをCSVなどの形式で出力する方法です。

メリット：プログラムを書かなくても始められる。まず手元でデータの中身を確認したいときに向く
デメリット：完全な自動化には向かない。毎回手で落とすと、結局コピー作業と同じ手間が残る

最初は手動ダウンロードで「どんな列が取れるのか」「どの粒度で取れるのか」を把握し、運用に乗せる段階でAPIに切り替える、という進め方が現実的です。

APIを使う

Yahoo!広告は、運用型広告向けにAPIを提供しています。APIから実績レポートを取得し、BigQueryへロードするスクリプトを組めば、定期実行で自動化できます。

ただし、APIの利用にはいくつか前提があります。

利用申請やアクセストークンの取得などの初期設定が必要
レポートの取得は、リクエストを投げてから生成完了を待ち、結果をダウンロードする、という非同期の流れになることが多い
API のバージョンや項目名は変わることがある

このあたりの具体的な手順や項目名は、必ず最新の公式ドキュメントで確認してください。ここでは「APIで日別・キャンペーン単位の実績を取得し、BigQueryへ入れる」という前提で先に進めます。

取得・ロードの実装の考え方そのものは、別記事の Meta広告APIからBigQueryにデータを自動取得すると共通する部分が多いので、Python での自動ロードを組みたい方はそちらも参考になります。

共通スキーマで媒体を統合する設計

ここが今回のいちばんの肝です。媒体ごとにバラバラの形のまま貯めると、結局あとで突き合わせる手間が残ってしまいます。そこで、どの媒体から来たデータも同じ列構成のテーブルに入れるという設計にします。

考え方はシンプルで、各媒体に共通する「最低限の指標」だけを抜き出して、横断テーブルにそろえます。

列名	内容	例
`date`	日付	2026-07-01
`platform`	媒体名	google / yahoo
`campaign_name`	キャンペーン名	夏セール_検索
`impressions`	表示回数	12000
`clicks`	クリック数	340
`cost`	費用（円）	28500
`conversions`	コンバージョン数	12

ポイントは platform 列です。「このデータがどの媒体のものか」を1列持たせておくだけで、媒体別にも、媒体横断にも、同じテーブルから集計できるようになります。

設計の進め方としては、次の2段構えがおすすめです。

媒体ごとの生データ用テーブル（google_ads_raw、yahoo_ads_raw など）に、各媒体のレポートをそのまま貯める
その生データを 共通スキーマのテーブル（ads_unified など）に整形して入れる

生データをそのまま残しておくと、あとで「この媒体だけの細かい項目も見たい」となったときに困りませんし、整形ロジックを直したいときも作り直しがしやすくなります。

たとえば、Google広告のDTSテーブルとYahoo!広告の生テーブルから、共通スキーマへまとめるイメージは次のようになります（列名はあくまで例です。実際の列名は各媒体・各テーブルの仕様に合わせてください）。

-- 各媒体の生データを共通スキーマに統合する例
CREATE OR REPLACE TABLE `myproject.ads.ads_unified` AS

-- Google広告（DTSのテーブルを共通形に変換）
SELECT
  DATE(segments_date)        AS date,
  'google'                   AS platform,
  campaign_name              AS campaign_name,
  metrics_impressions        AS impressions,
  metrics_clicks             AS clicks,
  metrics_cost_micros / 1e6  AS cost,        -- microは100万分の1なので円に戻す
  metrics_conversions        AS conversions
FROM `myproject.google_ads.ads_CampaignStats_1234567890`

UNION ALL

-- Yahoo!広告（取り込んだ生データを共通形に変換）
SELECT
  CAST(report_date AS DATE)  AS date,
  'yahoo'                    AS platform,
  campaign_name              AS campaign_name,
  impressions                AS impressions,
  clicks                     AS clicks,
  cost                       AS cost,
  conversions                AS conversions
FROM `myproject.yahoo_ads.campaign_stats_raw`;

UNION ALL で縦に積むだけなので、3媒体目（たとえばMeta広告）が増えても、同じ形に変換するブロックを足すだけで拡張できます。

Google広告と横断で見る集計SQL

共通スキーマができてしまえば、横断の集計はとてもシンプルになります。先ほどの ads_unified を使って、媒体別の費用対効果を並べてみます。

-- 媒体別に、費用・クリック単価・獲得単価・ROAS の代わりとなる指標を並べる
SELECT
  platform,
  SUM(cost)                              AS total_cost,
  SUM(clicks)                            AS total_clicks,
  SUM(conversions)                       AS total_conversions,
  SAFE_DIVIDE(SUM(cost), SUM(clicks))    AS cpc,    -- クリック単価
  SAFE_DIVIDE(SUM(cost), SUM(conversions)) AS cpa   -- 獲得単価
FROM `myproject.ads.ads_unified`
WHERE date BETWEEN '2026-06-01' AND '2026-06-30'
GROUP BY platform
ORDER BY total_cost DESC;

SAFE_DIVIDE を使っているのは、コンバージョンが0の期間でゼロ除算エラーにならないようにするためです。これで「先月はGoogleとYahoo!でそれぞれいくら使って、CPAはどちらが安かったか」が一目で出ます。

日別の推移を媒体ごとに見たいときは、次のようにします。

-- 日別・媒体別の費用推移
SELECT
  date,
  platform,
  SUM(cost) AS daily_cost
FROM `myproject.ads.ads_unified`
WHERE date BETWEEN '2026-06-01' AND '2026-06-30'
GROUP BY date, platform
ORDER BY date, platform;

この結果をそのまま Looker Studio につなげば、媒体別の折れ線グラフがすぐ作れます。横断のダッシュボードまで作りたい方は BigQueryとLooker Studioでチャネル横断のROASダッシュボードを作るで具体的な組み立て方を紹介しています。

なお、この記事ではコンバージョン数までを扱っていますが、実際の売上金額（広告経由の購入金額）まで突き合わせると、本当の意味でのROAS（広告費用対効果）が見えてきます。その場合は、GA4やEC側の売上データと結合する設計も検討してみてください。

名寄せ・通貨・日付でつまずきやすい点

横断テーブルを作るときに、現場でよく引っかかるのが次の3点です。先に知っておくと、あとで「数字が合わない」と悩まずに済みます。

キャンペーン名の名寄せ

GoogleとYahoo!で、同じ施策のキャンペーン名がぴったり同じとは限りません。「夏セール検索」と「夏セール_検索」のように、ちょっとした表記ゆれがあると、横断で集計したときに別物として扱われてしまいます。

対策としては、

運用ルールとして、両媒体でキャンペーンの命名規則をそろえておく
どうしてもそろわない場合は、名寄せ用の対応表（マスタ）をBigQueryに別テーブルで持ち、結合して統一名に変換する

のどちらかが現実的です。最初に命名規則を決めておくほうが、あとあとラクになります。

通貨と単位

Google広告のDTSでは、費用が「マイクロ（100万分の1）」という単位で入っていることがあります。先ほどのSQLで metrics_cost_micros / 1e6 としていたのはこのためです。一方、Yahoo!広告側のデータが円単位ならそのまま使えます。

単位がそろっていないと、片方だけ桁が100万倍ずれる、という事故が起きます。共通スキーマに入れる時点で「すべて円・同じ単位」にそろえておきましょう。

日付とタイムゾーン

媒体によって、レポートの日付が日本時間（JST）基準なのか別の基準なのかが異なる場合があります。集計の境目（特に深夜帯）で数字が前日・翌日にずれることがあるため、

どちらの媒体も同じタイムゾーン基準にそろえる
日付列の型を DATE に統一しておく（文字列のまま貯めない）

という点に気をつけてください。型がバラバラだと、WHERE date BETWEEN ... のような絞り込みで思わぬ取りこぼしが起きます。

まとめ

Yahoo!広告とGoogle広告を別々の画面で見ていると、突き合わせの手作業にどうしても時間を取られます。そこを、

Yahoo!広告のデータを（レポートまたはAPIで）BigQueryに取り込み
platform 列を持つ共通スキーマにそろえて統合し
UNION ALL で積んだテーブルから横断のSQLで集計する

という流れに置き換えると、媒体をまたいだ費用対効果がSQL一本で出せるようになります。一度作ってしまえば、3媒体目が増えても変換ブロックを足すだけで拡張できるのも利点です。

つまずきやすいのは、キャンペーン名の名寄せ・通貨や単位・日付やタイムゾーンの3点です。ここさえ最初にそろえておけば、あとは安定して運用できます。

まずは「先月1か月分を、両媒体そろえて1つのテーブルに入れてみる」ところから、小さく始めてみてください。Google広告側の自動転送をまだ設定していない方は Google広告のBigQuery Data Transferを設定するもあわせてご覧ください。