はじめに：サードパーティCookie制限で広告効果が見えにくくなった

「広告費を増やしたのに、管理画面のコンバージョン数が前ほど伸びない」「同じキャンペーンなのに、媒体ごとに報告される成果がバラバラで、どれを信じればいいのか分からない」——最近、こうした相談がEC事業者さんから増えています。

原因のひとつが、サードパーティCookieをめぐる環境の変化です。ブラウザのトラッキング防止機能（Safariの ITP など）が強化され、広告媒体がブラウザをまたいでユーザーを追いかけることが難しくなりました。Google Chrome のサードパーティCookie廃止については方針が二転三転しており、最終的な扱いは要確認ですが、いずれにせよ「Cookieに依存した計測はだんだん効かなくなる」という方向は変わっていません。

その結果、起きているのが次のようなことです。

  • 広告管理画面のコンバージョン数が、実際の受注より少なく見える（計測の取りこぼし）
  • 「モデル化されたコンバージョン」など、推定値の割合が増える
  • 媒体ごとにアトリビューションがダブり、合計すると実売上を超える

つまり、これまで頼ってきた「媒体が教えてくれる成果」だけでは、もう正確な判断ができなくなりつつあるということです。

では、何を軸にすればいいのか。答えのひとつが ファーストパーティデータ です。

ファーストパーティデータを軸に据えるという考え方

ファーストパーティデータとは、ざっくり言えば「自社が直接持っているデータ」です。ECなら、次のようなものが該当します。

  • 購買データ：受注テーブル、いつ・誰が・何を・いくら買ったか
  • 会員データ：会員登録情報、メールアドレス、購入履歴の紐付け
  • 自社サイトの行動ログ：GA4 で取得しているページ閲覧やイベント

これらは、ブラウザのCookie規制を受ける外部の追跡データではなく、自分の店の帳簿に近いものです。広告媒体がどれだけ計測しにくくなっても、「実際にいくら売れたか」という事実は自社のデータベースに残っている。ここが一番大事なポイントです。

発想を切り替えます。

「媒体に成果を教えてもらう」から、「自社の売上を起点に、どの広告が効いたかを自分で照らし合わせる」へ。

広告媒体の数字をそのまま正とするのではなく、自社の購買データという「動かない事実」を中心に置き、そこに広告の情報を寄せていく。この順番の逆転が、Cookie規制後の効果測定の出発点になります。

全体像：自社購買 × GA4 × 広告費を BigQuery に集める

軸が決まったら、次は「データを一箇所に集めて突き合わせられる場所」を用意します。ここで BigQuery が役立ちます。

理由はシンプルで、性質の違う3種類のデータを、同じ場所で SQL で結合できるからです。

データ主な出どころ持っている情報
購買データ自社DB / ECカートのエクスポート受注ID・金額・顧客ID・注文日時
行動データGA4（BigQuery エクスポート）セッション・流入元・UTM・イベント
広告費データ各広告媒体のレポート媒体・キャンペーン・日次のコスト

これらを BigQuery に集約すると、次のような問いに自社の数字で答えられるようになります。

  • このキャンペーンに使った広告費に対して、実売上ベースでいくら返ってきたのか
  • どの流入元から来た人が、最終的にリピート購入まで進んでいるのか
  • 媒体が報告するコンバージョンと、自社の受注実績はどれくらいズレているのか

GA4 は管理画面でも分析できますが、購買データや広告費と突き合わせるには手が届きません。BigQuery に出してはじめて、「自社の売上を真ん中に置いた効果測定」が現実的になります。

イメージとしては、こんな流れです。

[自社購買DB] ──┐
              ├─→ [BigQuery に集約] ─→ [突き合わせ・集計] ─→ [媒体別ROAS / LTV]
[GA4 export] ─┤
              │
[広告費レポート]┘

結合のキーになるのは、GA4 側で取得しておいた識別子（後述）と、受注データを結びつけるための設計です。ここがうまく繋がるかどうかで、再構築の成否が決まります。

なお、GA4 から広告費や検索キーワードまで踏み込んで「本当のROAS」を見ていく具体的な進め方は、BigQueryでGoogle広告とGA4をつないで、キーワード単位の本当のROASを出す でも整理しています。あわせてどうぞ。

実装の勘所

考え方が固まったら、実装で気をつけたいポイントが3つあります。

1. 同意のあるデータを使う

大前提として、集めて使えるのは ユーザーの同意が取れているデータ です。Cookie規制への技術的な対応と、プライバシー・同意の遵守はセットで考えなければいけません。

GA4 のデータ収集でも、同意の状態に応じて計測を制御する仕組み（Consent Mode）の整備が前提になります。サーバーサイドでの計測や同意管理の具体的な進め方は、サーバーサイドGTMと同意モードv2で広告計測を立て直す で扱っています。「とにかくデータを集める」のではなく、「同意の範囲で、正しく集める」が出発点です。

2. ID設計を先に決める

購買データと行動データを突き合わせるには、両者をつなぐ「キー」が必要です。ここを後回しにすると、データは集まったのに結合できない、という事態に陥りがちです。

実務でよく使うのは次のような考え方です。

  • 会員IDがある場合：ログイン時に GA4 側へ user_id を渡し、受注データの顧客IDと突き合わせる
  • 会員IDがない場合：受注完了ページで採番した注文IDを GA4 のイベントパラメータにも持たせ、共通キーにする

⚠️ 注意：GA4 に メールアドレスや生の会員IDなどの個人情報（PII）をそのまま送ってはいけません。GA4 の利用規約・ポリシー違反になりうるためです。GA4 側へ渡す識別子は ハッシュ化した値や、自社で対応表を保持する擬似ID にとどめ、実際の顧客情報との突き合わせは 自社側（BigQuery）で行う のが安全です。user_id や共通キーには、PII を直接含まない値を使ってください。

-- 受注を起点に、GA4 のセッション情報を突き合わせるイメージ（簡略）
SELECT
  o.order_id,
  o.order_amount,
  s.source,
  s.medium,
  s.campaign
FROM `your_project.sales.orders` AS o
LEFT JOIN `your_project.analytics.ga4_sessions` AS s
  ON o.order_id = s.order_id   -- 共通キーで結合

大事なのは「どのIDで両者をつなぐか」を、実装に入る前に紙の上で決めておくことです。

3. コンバージョンを自社で定義する

媒体任せにしていたコンバージョンの定義を、自社の言葉で決め直します。

  • 「フォーム送信」ではなく「入金確認済みの受注」をコンバージョンとする
  • 初回購入とリピートを分けて見る
  • キャンセル・返品を差し引いた 正味の売上 で評価する

媒体の管理画面では「フォーム送信」までしか見えないことが多いですが、本当に知りたいのは「ちゃんとお金になった注文」のはずです。自社データを軸にすると、この定義を自分で握れるようになります。これが Cookie規制後の効果測定で得られる、一番大きなメリットかもしれません。

注意：プライバシー・同意・法令の遵守

⚠️ ファーストパーティデータの活用は「自社が持っているデータだから自由に使える」という意味ではありません。個人情報の取り扱いには、利用目的の明示や同意取得など、法令上の義務がともないます。日本の個人情報保護法、対象に EU 圏の利用者が含まれる場合は GDPR など、関係する法令は事業の状況によって異なります。プライバシーポリシーへの記載、同意管理の仕組み、データの保管・共有範囲については、最新の法令・ガイドラインを確認のうえ、必要に応じて専門家（弁護士など）に相談してください。本記事は技術的な設計の考え方を整理したものであり、法的助言ではありません。具体的な要件は必ず最新情報を要確認のうえご判断ください。

まとめ

サードパーティCookieの制限で「媒体が教えてくれる成果」が当てにしづらくなった今、効果測定の軸を 自社のファーストパーティデータ に移すのが現実的な打ち手です。要点を振り返ります。

  • 広告媒体の数字ではなく、自社の購買データ（動かない事実） を真ん中に置く
  • 購買 × GA4 × 広告費を BigQuery に集約 し、SQL で突き合わせられる状態にする
  • 実装では、同意のあるデータ・先に決めるID設計・自社でのコンバージョン定義 の3点を押さえる
  • 技術的な対応と、プライバシー・同意・法令の遵守 は必ずセットで進める

いきなり完璧な基盤を作る必要はありません。まずは「受注データと GA4 を一度突き合わせてみる」ところから始めると、自社の数字と媒体の数字がどれだけズレているかが見えてきます。そのズレこそが、Cookie規制後の改善の出発点になります。