はじめに：Amazonと自社ECが分断されたまま予算を決めていませんか

商品をAmazonと自社EC（Shopifyや独自ドメインのストア）の両方で売っていると、データが完全に別々の場所に貯まります。Amazonの売上はセラーセントラル、Amazon広告の実績は広告コンソール、自社ECの集客と売上はGA4。三つの画面を行き来しながら、頭の中で足し算して「今月はどこに予算を寄せるか」を決めている、という方は多いのではないでしょうか。

この分断には、地味だけれど効いてくる問題があります。

  • チャネルごとに指標の名前も粒度も違い、突き合わせるだけで手間がかかります
  • 「広告全体でいくら使って、Amazonと自社ECを合わせて何件売れたか」をパッと出せません
  • 同じ商品でも、Amazon広告が効いているのか自社ECの集客が効いているのか、横断で比べられません

毎月この集計をやっていると、本来時間を使いたい「予算配分の判断」より、数字を集める作業のほうに時間を取られてしまいますよね。

この記事では、Amazon広告のデータとGA4の自社ECデータをBigQueryの同じ場所・同じ形に集めて、チャネルミックス（媒体別の貢献度合い）を横断で見られるようにする設計を紹介します。一度仕組みを作ってしまえば、チャネルをまたいだ費用対効果がSQL一本で出せるようになります。

なお、Amazon広告のAPIやレポート仕様、GA4のBigQueryエクスポートの仕様は更新が頻繁です。実装の際は必ず最新の公式ドキュメント（Amazon Ads APIの開発者向けドキュメント、Amazonセラーセントラルのヘルプ、GoogleアナリティクスのBigQuery Export公式ヘルプ）を確認してください。本記事の列名やパラメータはあくまで設計の例として読んでください。

それぞれのデータをどう取得するか

最初に、三つのデータをそれぞれどうやってBigQueryに持ってくるかを整理します。取得経路はチャネルごとに事情が違います。

Amazon広告のデータ

Amazon広告には、運用型広告向けにAmazon Ads APIが提供されています。スポンサープロダクト広告などのレポートをAPIで取得し、BigQueryへロードするスクリプトを組めば、定期実行で自動化できます。

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

  • 開発者としての登録や、アクセス権限・認証情報の取得などの初期設定が必要です
  • レポートの取得は、リクエストを投げてから生成完了を待ち、結果をダウンロードする、という非同期の流れになることが多いです
  • APIのバージョンやレポートの項目名は変わることがあります

これらの具体的な手順や項目名は、必ず最新の公式ドキュメントで確認してください。「まずは手元で中身を見たい」という段階なら、広告コンソールからレポートを手動でダウンロードして列を確認し、運用に乗せる段階でAPIに切り替える、という進め方が現実的です。

取得・ロードの実装の考え方そのものは、別媒体のAPI取り込みと共通する部分が多いので、Pythonでの自動ロードを組む流れの参考にしてみてください。

Amazonの売上データ

Amazon内での実際の売上（注文データ）は、セラーセントラルのレポートや、対応するAPI経由で取得できます。広告の実績だけでなく、Amazon側で何がいくら売れたかも合わせて持っておくと、後で広告費と売上を突き合わせやすくなります。こちらも仕様は変わりやすいので、利用範囲や取得方法は公式の最新情報で確認してください。

GA4の自社ECデータ

自社ECの集客と売上は、GA4のBigQuery Export機能を使えば、イベント単位の生データをそのままBigQueryに自動で貯められます。設定すれば日次（または条件によりストリーミング）でエクスポートされ、追加のスクリプトなしで集計の土台が手に入ります。

ここで一点、つまずきやすい重要なポイントがあります。GA4のBigQueryエクスポートでは、流入元（source / medium / campaign）は event_params の中ではなく、専用のレコード列に入っています。具体的には、イベント時点の流入元は collected_traffic_source.*、セッション単位の流入元は session_traffic_source.* という構造体の中に格納されます。

-- GA4の流入元は event_params ではなく専用の構造体に入っている
SELECT
  PARSE_DATE('%Y%m%d', event_date)              AS date,
  collected_traffic_source.manual_source        AS source,
  collected_traffic_source.manual_medium        AS medium,
  collected_traffic_source.manual_campaign_name AS campaign_name,
  ecommerce.purchase_revenue                     AS revenue
FROM `myproject.analytics_XXXXXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'
  AND event_name = 'purchase';

ここを event_params から取ろうとして「流入元が取れない」と悩む方が多いので、列の場所を最初に押さえておきましょう。列名はGA4のバージョンによって異なる場合があるため、実装前に最新の公式ドキュメントで確認してください。

共通スキーマでチャネルを統合する設計

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

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

列名内容例
date日付2026-08-01
channelチャネル名amazon_ads / own_ec
campaign_nameキャンペーン名・流入元夏セール_SP広告
cost費用（円）28500
orders注文数12
revenue売上金額（円）184000

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

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

  1. チャネルごとの生データ用テーブル（amazon_ads_raw、ga4_own_ec など）に、各チャネルのデータをそのまま貯めます
  2. その生データを 共通スキーマのテーブル（channel_unified など）に整形して入れます

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

たとえば、Amazon広告の生テーブルとGA4のエクスポートから、共通スキーマへまとめるイメージは次のようになります（列名はあくまで例です。実際の列名は各チャネル・各テーブルの仕様に合わせてください）。

-- 各チャネルのデータを共通スキーマに統合する例
CREATE OR REPLACE TABLE `myproject.mart.channel_unified` AS

-- Amazon広告（取り込んだ生データを共通形に変換）
SELECT
  CAST(report_date AS DATE)  AS date,
  'amazon_ads'               AS channel,
  campaign_name              AS campaign_name,
  cost                       AS cost,
  orders                     AS orders,    -- 広告経由の注文数
  sales                      AS revenue    -- 広告経由の売上金額
FROM `myproject.amazon.amazon_ads_raw`

UNION ALL

-- 自社EC（GA4の購入イベントを共通形に変換）
SELECT
  PARSE_DATE('%Y%m%d', event_date)              AS date,
  'own_ec'                                       AS channel,
  collected_traffic_source.manual_campaign_name AS campaign_name,
  0                                             AS cost,    -- 集客費は別途突き合わせる
  COUNT(*)                                      AS orders,
  SUM(ecommerce.purchase_revenue)              AS revenue
FROM `myproject.analytics_XXXXXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'
  AND event_name = 'purchase'
GROUP BY date, channel, campaign_name;

UNION ALL で縦に積むだけなので、チャネルが増えても、同じ形に変換するブロックを足すだけで拡張できます。自社ECの広告費（GoogleやMeta経由など）まで含めたい場合は、それぞれの広告データを同じ共通スキーマに変換するブロックを追加していきます。

チャネルミックス（媒体別貢献）の見方

共通スキーマができてしまえば、チャネルミックスの集計はとてもシンプルになります。先ほどの channel_unified を使って、チャネル別の貢献度合いを並べてみます。

-- チャネル別に、費用・売上・構成比・ROASの代わりとなる指標を並べる
SELECT
  channel,
  SUM(cost)                                AS total_cost,
  SUM(orders)                              AS total_orders,
  SUM(revenue)                             AS total_revenue,
  SAFE_DIVIDE(SUM(revenue), SUM(cost))     AS roas,  -- 売上 ÷ 広告費
  SAFE_DIVIDE(
    SUM(revenue),
    SUM(SUM(revenue)) OVER ()
  )                                        AS revenue_share  -- 売上構成比
FROM `myproject.mart.channel_unified`
WHERE date BETWEEN '2026-08-01' AND '2026-08-31'
GROUP BY channel
ORDER BY total_revenue DESC;

SAFE_DIVIDE を使っているのは、費用が0のチャネルでゼロ除算エラーにならないようにするためです。revenue_share は、全チャネル合計の売上に対する各チャネルの構成比で、これが「チャネルミックス」を一目で表す数字になります。これで「今月は売上の何割をAmazonが、何割を自社ECが占めたか」「広告費に対する売上効率はどちらが高いか」が同じ表で見えます。

日別の推移をチャネルごとに見たいときは、次のようにします。

-- 日別・チャネル別の売上推移
SELECT
  date,
  channel,
  SUM(revenue) AS daily_revenue
FROM `myproject.mart.channel_unified`
WHERE date BETWEEN '2026-08-01' AND '2026-08-31'
GROUP BY date, channel
ORDER BY date, channel;

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

Amazon内売上には計測の限界がある点に注意

ここで一つ、正直にお伝えしておきたい限界があります。Amazon内で完結する購入の行動は、自社ECほど細かくは追えません。

GA4で見える自社ECは、ユーザーがどの流入元から来て、どのページを見て、どこで購入したかという一連の流れをイベント単位で追えます。一方、Amazon内での購入は、Amazonというプラットフォームの中で起きるため、自社側で取得できるのは基本的にAmazonが提供するレポートの範囲（広告の実績や注文データなど）に限られます。たとえば次のような点は、自社ECと同じ精度では見えないことが多いです。

  • Amazon内で広告を見てから購入に至るまでの細かい経路
  • 同じ顧客が自社ECとAmazonをまたいで購入したかどうかの紐づけ
  • 広告に直接ひもづかない、Amazon内検索や関連商品からの購入の内訳

つまり、共通スキーマに乗せたAmazon側の数字は「Amazonが提供するレポートで確認できる範囲の集計値」であって、GA4のような生のイベント単位ではない、という前提を持っておく必要があります。

実務上の割り切り方としては、チャネル横断では「費用・注文数・売上」という粗い共通指標で全体感をつかみ、細かい行動分析は自社ECはGA4で、AmazonはAmazonのレポートで、それぞれ得意な範囲で深掘りする、という使い分けが現実的です。共通スキーマは全体最適の判断材料、各チャネルの生データは個別最適の分析材料、と役割を分けて考えると整理しやすくなります。

まとめ

Amazonと自社ECのデータが別々の画面に分かれていると、全体の費用対効果がどうしても見えにくくなります。そこを、

  • Amazon広告と売上を（APIまたはレポートで）BigQueryに取り込み
  • GA4の自社ECデータをBigQuery Exportで貯め（流入元は collected_traffic_source.* / session_traffic_source.* から取る）
  • channel 列を持つ共通スキーマにそろえて統合し
  • UNION ALL で積んだテーブルから横断のSQLでチャネルミックスを集計する

という流れに置き換えると、チャネルをまたいだ貢献度合いと費用対効果がSQL一本で出せるようになります。一度作ってしまえば、別の広告チャネルが増えても変換ブロックを足すだけで拡張できるのも利点です。

ただし、Amazon内の購入は自社ECほど細かくは追えないという計測の限界は、最初に理解しておいてください。全体感は共通スキーマで、深掘りは各チャネルの得意な範囲で、と役割を分けるのがおすすめです。

まずは「先月1か月分を、Amazonと自社ECそろえて1つのテーブルに入れてみる」ところから、小さく始めてみてください。Yahoo!やGoogleなど検索広告も横断に加えたい方は Yahoo!広告データをBigQueryに取り込んでGoogle広告と統合分析する もあわせてご覧ください。