計測設計の地図とGA4の限界 ― 5層で考える

計測のどこを自前で設計し、どこをGA4に任せればいいのか。結論から言えば、計測は「収集 → 同意 → 識別 → 保管 → 送信」の5層に分けられ、GA4は収集の一部に強い一方、識別・送信・保管には自前の設計が必要です。この記事では、その5層の地図でGA4の限界を構造として切り分け、以降の各回（イベント設計・サーバーサイド・同意・識別・送信）がどの層を担うのかを位置づけます。

連載の起点では、計測は分析手法ではなく計測そのものが静かに壊れること、そして下流の予測・因果の上限を「接合率」が決めることを見ました。本回はその地図を一枚に広げ、「GA4で足りる層」と「自前で設計しないと埋まらない層」を分けます。GA4を貶すためではありません。役割を取り違えると、強い道具を弱い用途に使い、本来自前で設計すべき層を放置することになるからです。

計測の5層（収集→同意→識別→保管→送信）

計測を一枚で捉えるために、データが生まれてから使われるまでを5つの層に分けます。順番に意味があります。上流が壊れると、下流をどれだけ精緻に作っても土台ごと崩れるからです。

この5層は独立ではなく直列です。全体の信頼性は、最も弱い層（律速段階）で決まります。だから「どの層から手をつけるか」は、流行りの手法ではなく、自社のどの層が一番薄いかで決めるのが筋です。その薄さを一つの数字で言えるようにしたものが、前回導入した接合率でした。

GA4が得意なこと・構造的に届かないこと

GA4は5層のうち、主に「収集」を担う道具です。識別や送信まで担えると誤解すると事故が起きるので、まず強みと限界を構造で切り分けます。

計測（収集）の強み

GA4の強みは、ユーザー行動を低コストでイベント化し、加工しないまま BigQuery に出せることです。GA4 BigQuery Export を有効にすれば、UIの集計に縛られず、自分で再集計・再結合できるローイベントが手に入ります。ここまでは収集の道具として素直に強い。

-- GA4 BigQuery Export のローイベント（収集層の出力）
-- GA4が強いのは「行動を低コストでイベント化し、加工しないまま BigQuery に出せる」こと
SELECT
  event_date,
  event_name,
  user_pseudo_id,                                    -- GA4標準の識別子（端末/Cookie由来）
  (SELECT ep.value.int_value FROM UNNEST(event_params) ep
     WHERE ep.key = 'ga_session_id') AS ga_session_id,
  traffic_source.source AS source,
  traffic_source.medium AS medium
FROM `solna.analytics_000000.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260501' AND '20260531'
  AND event_name IN ('session_start', 'page_view', 'purchase')

問題は、このクエリで一意に使える識別子が user_pseudo_id しか無い、というところから始まります。

識別・保管・送信の限界

識別の限界。user_pseudo_id は端末・Cookie由来の識別子で、ブラウザを変えれば分裂し、Cookieが消えればリセットされます。同一人物が複数の user_pseudo_id に割れる一方、会員の customer_id とは一意に対応しません。さらに、成果額（実成約・手数料・LTV）はそもそもGA4の世界に無く、purchase の value もタグや媒体任せの自己申告です。「お金の真実」はCRMや orders にあります（この判断面は記述・予測編で詳述）。つまり、広告接触から成果まで一本に辿る背骨は、GA4単体では作れません。背骨を作るには、GA4の user_pseudo_id を自社の会員IDへ橋渡しする層を、自前で持つ必要があります。

-- 「識別」は自前で設計する層：GA4の pseudo_id を自社の会員IDへ橋渡しする
-- ここで埋まらない割合が、そのまま下流（予測・因果）の上限になる（＝接合率）
WITH ga AS (
  SELECT DISTINCT user_pseudo_id
  FROM `solna.analytics_000000.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260501' AND '20260531'
)
SELECT
  COUNT(*)                                                   AS pseudo_ids,
  COUNTIF(m.customer_id IS NOT NULL)                         AS resolved_to_customer,
  SAFE_DIVIDE(COUNTIF(m.customer_id IS NOT NULL), COUNT(*))  AS resolve_rate
FROM ga
LEFT JOIN `solna.mart.id_map` m   -- 自前で持つ pseudo_id × customer_id の対応表
  USING (user_pseudo_id)
-- resolve_rate ≒ 識別の接合率。第5回で「測る・上げる・監視する」を扱う

保管の限界。GA4のUIレポートには、しきい値処理・サンプリング・カーディナリティ上限（(other) 行への丸め）がかかります。BigQuery Export はそれを回避する保管の入口ですが、出力されるのは設定日以降のデータだけで、過去には遡れません。長期の再集計に耐える保管そのものは、BigQuery／自社基盤側（＝整える＝dbtの領域）の仕事です。

送信の限界。GA4は基本「受け取って見る」道具で、整えた実成果を媒体最適化へ返す経路は持ちません。実成果（成約・LTV）を媒体に戻すのは Conversions API やオフラインCV連携の役割です（第6回）。

まとめると、GA4は収集に強く、BigQuery Export で保管の入口までは伸ばせます。しかし識別と送信は構造的に自前です。GA4が悪いのではなく、収集の道具を識別・送信の道具と取り違えると事故る、という役割の話です。

計測の品質保証という横串

5層は一度作って終わりではありません。計測は静かに壊れます。タグの差し替え、同意UIの変更、媒体仕様の更新、リダイレクトの追加。どれも単体ではエラーを出さず、数字だけが少しずつズレていきます。だから品質保証（QA）を、5層を貫く横串として常設します。

点検（debug）と監視（monitoring）は別物です。DebugView やリアルタイムは「今この瞬間、意図通り飛んでいるか」を見る点検で、これだけでは来月静かに始まる取りこぼしは捕まりません。継続監視は、壊れを時系列で検知する仕組みです。最低限、次のあたりは見ておきます。

• 主要イベントの日次件数と、結合キーが欠けたイベントの割合（null率）
• user_pseudo_id → customer_id の接合率の時系列（識別層の健康診断）
• 媒体報告CVと BigQuery 集計の差分（収集・送信層のズレ検知）
• 同意状態別のイベント比率（同意UI変更の影響検知）

接合率は一度測って満足する数字ではありません。下流の予測・因果の上限を決める指標なので、施策やUI変更のたびに動きます。ここで一つだけ伏線を置きます。計測が担保するのは「辿れるか」までで、「効いたか（因果）」「当たるか（予測）」はその先の話です。土台が傾いていれば上の階は必ず傾く——順序が逆にならないようにします。

実務で計測監査をすると、識別の接合率は流入経路や会員化率で大きく振れ、同じ業態でも他社の数字は当てになりません。だからこそ、他社の数字を借りるより、自社で一度測ることに意味があります。

どこに自前設計が必要か（以降の地図）

5層のうち、GA4で概ね足りるのは収集の一部だけでした。残りは自前設計の領域で、それぞれを以降の回が担います。

ここで大事なのは、全層を一度に作らないことです。5層は直列なので、全体の精度は最も弱い層で決まります。接合率を一度測れば、自社のボトルネックがどの層かが見えます。識別が薄いのにサーバーサイド計測から入っても、辿れないデータが増えるだけです。弱い層を一つ特定し、そこに資源を寄せる——「今はやらない層＋それを着手する条件」まで言えると、計測投資は説明可能になります。

章末チェックリスト

• 自社の計測を「収集 → 同意 → 識別 → 保管 → 送信」の5層で説明できる
• GA4の限界を「役割」ではなく「構造」で言える（一意キーが user_pseudo_id しか無い・成果額が無い・送信経路が無い）
• GA4 BigQuery Export を有効化しているか（過去は遡れない）
• 5層のうち、自社の律速段階（最も弱い層）を一つ特定した
• 接合率を継続監視する仕組みがあるか、無ければ次に作ると決めた

次回は、後から集計・結合できる計測にするためのイベント設計とタクソノミー（命名規約・パラメータ・データレイヤー）に入ります。収集層を「とりあえず取る」から「後で使える」へ変える設計原則です（第2回 イベント設計とタクソノミー）。

そして、ここまでの5層のどこに自社が投資すべきか——どの手法がいま成立し、何を後回しにするかの判断は、対になる記述・予測編に置いています。実装（本回）と判断（あちら）を行き来してください。