データクリーンルーム入門 ― 媒体内を測るための窓

媒体の中（ウォールドガーデン）で何が起きたかは、自社のデータだけでは追えません。Meta や Google、YouTube の配信面で「誰が・何回・どの広告に触れたか」は、原則としてその媒体の外に出ないからです。この記事では、その壁に対してデータクリーンルーム（Ads Data Hub / Amazon Marketing Cloud）という制約付きの窓と、観測できない分を埋めるモデル化コンバージョンが、それぞれ何を可能にし何を可能にしないかを概観します。

扱うのは個別ツールの操作手順ではなく、仕組みと限界の地図です。前回（第6回）までで、自社が持てるデータは「収集→同意→識別→保管→送信」の全層にわたって設計しきりました。本回はその外側――構造的に自社が持てない領域に、どこまで・どういう形で迫れるかを見て、最後に「計測で測りきれない部分」を扱う測定戦略へ橋渡しします。これは計測設計の到達点であると同時に、計測単独の限界を認める回でもあります。

ウォールドガーデンという壁

第5回で、自社サイト内の接合率（広告接触→ID→成果を一本に辿れる割合）を引き上げました。過去の受託案件をもとに設計した架空のD2C企業SOLNA（連載共通スキーマ）では ga_client_id と customer_id の紐付けを徹底し、サイト内行動の接合率を7〜8割の水準まで持ち上げられる想定でした。けれど、その努力が効くのは自社プロパティの内側だけです。サイトの外、つまり媒体の配信面で起きたことは、接合率の引き上げとは別の問題として残ります。

ウォールドガーデンとは、Google・YouTube・Meta・Amazon のように、広告のインプレッション単位データを内部に囲い込み、外部に行レベルで持ち出させない閉じた環境を指します。あなたが見られるのは、媒体管理画面が返す集計済みのレポートまでです。次のような問いは、インプレッション単位のデータが手元にないと答えられません。

• 媒体をまたいで重複を除いた正味の到達（reach）は何人か。
• 一人あたり何回まで広告を当てたか（フリークエンシー）。同じ人に当てすぎていないか。
• クリックではなく「見ただけ（ビュースルー）」が成果にどう関わったか。
• YouTube と検索、あるいは複数媒体の到達がどれだけ重なっているか。

これらは、SOLNA がいくら自社サイト内の接合率を上げても埋まりません。customers テーブルにある一人の顧客が、配信前に YouTube 広告に何回触れたかを、自社の sessions だけから個人単位で復元することは構造的にできないからです。自社プロパティの接合率には天井があり、その天井の向こう側が媒体の中です。

データクリーンルームの考え方（ADH/AMC）

データクリーンルームは、この壁に対する制約付きの窓です。発想はシンプルで、「データを自分の手元に持ってこない代わりに、媒体の安全な環境の中で突合し、集計結果だけを受け取る」というものです。自社のファーストパーティデータ（顧客・成果）を媒体側の環境にアップロードし、媒体が持つインプレッション単位データと内部で結合し、出力は集計値に限定されます。

代表的なものに、Google の Ads Data Hub（ADH。Google 広告・YouTube・DV360 を BigQuery 方言の SQL で扱う）と、Amazon の Amazon Marketing Cloud（AMC）があります。Meta も同種のクリーンルーム的な分析環境を提供しています。SOLNA は Google と YouTube に出稿しているので、以降は ADH を例に取ります。共通する設計思想は次の三つです。

要するに、クリーンルームは「庭の中の可視性」を得る代わりに「行レベルの粒度」を差し出す取引です。個人単位で誰が成約したかを庭の中から持ち出すことはできません。得られるのは、しきい値を満たした集計だけです。

SOLNA で具体化すると、たとえば「4月に初回購入した顧客（自社の成果）」を ADH 環境に渡し、「同期間に YouTube と検索広告に触れた人」と内部で突合して、媒体をまたいだ重複排除到達と、そのうちコンバータがどれだけ重なるかを集計で出す、という使い方になります。最小構成は次のとおりです。

-- Ads Data Hub（BigQuery方言）。出力は集計のみ・行レベルのエクスポート不可。
-- テーブル名・結合方法は環境とdocsに従う（ここでは読解優先の最小構成）。
 
-- 1) 自社のコンバータ（BigQueryにアップロード済みのファーストパーティ）
--    SOLNA: 期間内に初回購入した customer_id を、ADHのマッチ用 user_id に解決済みとする
WITH converters AS (
  SELECT user_id
  FROM solna_firstparty.converters          -- customer_id を user_id にマッチ済み
  WHERE first_order_date BETWEEN '2026-04-01' AND '2026-04-30'
),
 
-- 2) 媒体内の広告接触（YouTube + 検索/ディスプレイ）を個人単位で重複排除
exposed AS (
  SELECT user_id FROM adh.yt_reservation_impressions WHERE campaign_id IN (/* 対象 */)
  UNION DISTINCT
  SELECT user_id FROM adh.google_ads_impressions   WHERE campaign_id IN (/* 対象 */)
)
 
-- 3) 重複排除した到達と、コンバータとの重なりを「集計」で出す
SELECT
  COUNT(DISTINCT e.user_id)                                       AS reach_deduped,
  COUNT(DISTINCT IF(c.user_id IS NOT NULL, e.user_id, NULL))      AS reached_and_converted
FROM exposed e
LEFT JOIN converters c USING (user_id)
-- ↑ 最小ユーザー数のしきい値・差分チェックにより、しきい値未満の行は
--   自動的に除外/丸められる。user_id を内部で扱えても、外に持ち出すことはできない。

このクエリが返すのは二つの数字（重複排除到達と、到達かつ成約した人数）だけで、誰がそれに当たるかは決して出てきません。それでも、自社データ単独では絶対に作れなかった「媒体をまたいだ正味の到達」が手に入ります。これがクリーンルームの正味の価値です。

ただし運用上の制約は小さくありません。最小ユーザー数のしきい値（しきい値未満の行は返らない）、複数クエリの差分から個人を逆算させない差分チェック、アップロードしたファーストパーティデータのマッチ率、データの鮮度、クエリの審査――これらは「使えば何でも分かる」ことを許しません。クリーンルームは万能の覗き窓ではなく、覗ける範囲と解像度があらかじめ絞られた窓です。

モデル化コンバージョンの位置づけ

クリーンルームが「庭の中を集計で覗く窓」だとすれば、モデル化コンバージョンは「観測できなかった分を推定で埋める」仕組みです。同意拒否や Cookie 喪失（第4回）で実測できなかったコンバージョンを、媒体や GA4 が集計シグナルから推定して補完します。GA4 の同意モードにおける行動モデリング、各媒体のモデル化コンバージョンが代表例です。

位置づけを誤らないことが肝心です。モデル化コンバージョンは推定であって、測定された事実ではありません。同意やCookieの喪失で生じる系統的な過小計上を緩和する役には立ちます。実測ゼロのまま意思決定するより、欠損を統計的に埋めた数字のほうがましな場面はあります。けれど、それはあくまで仮定と不確実性を抱えたモデルの出力です。

ここで二つの線を引いておきます。第一に、モデル化コンバージョンを CRM の実成果（第6回でいう「お金の真実」）と足し合わせて二重計上しないこと。一方は推定、もう一方は実測で、性質が違います。第二に、推定値を真実として扱わないこと。観測されたファーストパーティの事実から離れるほど、あなたは中身を監査できないベンダーのモデルを信じることになります。

判断軸はこの連載を通じて一貫しています。効果が測定可能か、論証が透明か。モデル化コンバージョンは、後者（透明性）で部分的に点を落とします。どんなシグナルで、どんな仮定のもとに埋めたのかを、利用者が完全には検証できないからです。だからモデル化コンバージョンは「方向性の参考」に留め、実測できるファーストパーティの成果と突き合わせて整合を確認する、という使い方が安全です。埋めること自体を否定するのではなく、埋めた数字をどの位置に置くかを間違えない、ということです。

計測の到達点と限界 ― 測定戦略へ

ここまでで、計測設計が打てる手はほぼ出揃いました。整理すると、自社プロパティの中では接合率を上げて天井を引き上げ（第5回）、庭の中はクリーンルームという制約付きの窓で集計レベルだけ覗き、それでも観測できない残りはモデル化コンバージョンで推定で埋める。収集から送信までの5層を設計しきり、外側にも手を伸ばしました。

それでも、正直に認めるべき限界があります。これらをすべて積み上げても、すべての成果を決定論的に「この接点のおかげ」と割り当てることはできません。庭の壁は窓を開けても壁のままですし、推定は推定のままです。そしてもっと根本的な問題として、たとえ全ジャーニーを完全に観測できたとしても、「ある接点に配分された貢献（credit）」と「その接点が無ければ成果が消えたか（増分）」は別物です。辿れること自体は、効いたことを意味しません。

これは計測を増やせば直る欠陥ではなく、計測という営みの構造的な限界です。だからここで発想を切り替えます。「すべてを一本の線で辿って測りきる」のではなく、「失敗の仕方が異なる複数の不完全な手法を突き合わせ、収束を見る」――測定戦略への移行です。クリーンルームの集計、MMM、geo 実験のような増分テストは、それぞれ別の問いに答え、別のところで間違えます。性質の違う数字を、互いの目盛りを揃えてから束ねると、一つの手法の弱点を他が補えます。

計測設計の役割は、この測定戦略に「信頼できる素材」を供給することでした。接合率の高いファーストパーティデータも、クリーンルームの重複排除到達も、実成果を返す送信（第6回）も、すべて測定戦略の三角形のどこかの頂点を支えます。計測がしっかりしているほど、束ねたときの三角形は安定します。

章末チェックリスト

• ウォールドガーデンで自社が「持てない」のは何か（重複排除到達・フリークエンシー・ビュースルー・媒体間の重なり）を言えるか
• クリーンルームが解く問題（庭の中を集計で覗く）と、解かない問題（個人単位の接合率を延長する／行レベルで持ち出す）を区別できるか
• モデル化コンバージョンを「推定」として位置づけ、実測の成果と二重計上していないか
• 計測単独では決定論的アトリビューションが不可能だと認めたうえで、測定戦略（三角測量）へ進む準備ができたか

計測で測りきれない部分は、測定戦略（アトリビューション三角測量）で補います。クリーンルームの集計・MMM・増分実験という性質の違う手法を、どう較正して束ねるか――その地図は測定戦略の基幹記事に譲ります。また、自社の構造でどこまで測れる／何を測るべきかという判断は、対になる判断レイヤー記述・予測編へ。実装（クリーンルームのクエリやファーストパーティ連携の設計）は、引き続き本 Lab 連載が担います。