なぜ計測は静かに壊れるのか ― 計測設計という土台
媒体CVと実成果の乖離、Cookie規制による取りこぼし、二重計上、同意未取得データの混入。GA4を入れても数字が合わない原因は分析手法ではなく計測そのものにあります。連載の地図と、下流の予測・因果の上限を決める「接合率」を紹介します。
by Shin
GA4を入れたのに、なぜ媒体と数字が合わず、意思決定がぶれるのか。問題は分析手法ではなく、計測そのものにあります。収集・同意・識別・送信のどこかが静かに壊れていて、下流の予測も因果も、その壊れた範囲を超えては正確になりません。この回では、計測が壊れる典型と連載全体の地図、そして下流手法の天井を決める「接合率」を示します。
扱うのは新しいツールの話ではなく、「データが生まれる前」の構造の話です。ダッシュボードに数字が出ているからといって、その数字が辿れているとは限りません。辿れていない数字の上に予測モデルや効果検証を積んでも、土台ごとぶれます。本連載(lab)はその土台を設計して直す側に立ち、判断の側(どの数字でどの意思決定を動かすか)は対になる記述・予測編に分けます。
計測が静かに壊れる4つの典型
計測は派手には落ちません。多くの場合、エラーは出ず、ダッシュボードは動き続け、数字も出ます。ただ、その数字が少しずつ実態からずれていく。構造として起きる典型が4つあります。いずれも、下流の予測(学習に使える実弾)と因果(突合できる対象)を静かに削ります。
媒体CV ≠ 実成果(媒体の自己申告)
媒体の管理画面が数える「CV」は、媒体自身が「これは自分の成果だ」と申告した数です。クリック後のアトリビューションウィンドウ、ビュースルーの扱い、媒体ごとの帰属ルールが背後にあり、CRM上の実成約とは粒度も定義も別物です。とくにB2Bや高単価商材では、フォーム送信から成約まで数週〜数ヶ月のラグがあり、媒体CVと実成果の距離が開きます。下流への影響は、予測の目的変数をこの自己申告に置くと、モデルが「媒体が拾いやすい成果」を学習してしまうこと。何を成果とみなすかの定義は、計測の最初の設計判断です。
これは概念の話ではなく、実際に起きます。あるB2B案件では、GA4 が数えていた問い合わせCV(generate_lead)と、CRM に実登録されたフォーム送信件数が6倍以上乖離していました。内訳を開くと、GA4 側は全チャネル・全フォーム種別を横断してカウントしており、tel: リンクのクリックや確認ページの閲覧でも発火していた。一方の CRM 側は実登録のみを計上していた。つまり GA4 も CRM も、それぞれの定義どおり「正しく」動いていたのです。壊れていたのは数字ではなく、定義でした。
この経験から確立した原則が、表示値と分析用で定義ソースを分離することです。経営や顧客が「問い合わせ数」と認識する数字は CRM の実登録を正とし、GA4 の CV はセッション分析や CVR の分母としてのみ使う。同じ言葉に2つの数字がある状態を放置しないこと。これは次節の接合率が「成果側から遡って辿れた割合を測る」のと同じ方向を向いています——成果の定義は成果側に置く、が共通の型です。
二重計上(同じ成果が複数経路で重なる)
同じ1件が、複数の経路から重複して記録されることがあります。クライアント計測とサーバーサイド計測の並行運用、タグの重複設置、SPAでの page_view 多重発火、媒体ピクセルとConversions API(CAPI)の重複送信で重複排除キーを渡していないケース。合計は実態より膨らみ、見かけ上は好調に見えます。下流では、成果ラベルが水増しされて学習データが汚れ、真のCAC を過小評価します。「増えた」の半分が同じ1件の影だった、という事故です。
Cookie規制とクロスデバイスの取りこぼし
ITP/ETPなどのブラウザ規制、サードパーティCookieの廃止、ファーストパーティCookieでも有効期限の短縮が進み、広告接触と成果が同一人物として結びつきにくくなっています。スマホで認知してPCで成約する、といった行動は、別人の別イベントとして分断されて記録されます。問題は「データが減る」こと自体より、特定の層だけが消えて母集団が偏ることです。欠損がランダムでない(特定ブラウザ・特定デバイスに偏る)と、その上の予測も効果検証もバイアスを背負います。
同意未取得データの混入(あるいは欠落)
同意管理(CMP)や同意モードの設定次第で、同意した人だけが計測される、あるいは同意前のデータが混ざる、という状態が生まれます。同意した人とそうでない人は属性が違うことが多く、ここには選択バイアスが入ります。同意者だけのデータで予測や因果を出すと、全体への一般化が崩れます。なお、何が適法かの判断は計測設計者の領分を超えるため、本連載では断定せず、第4回で弁護士確認を前提に整理します。また、同意の設定が実装層で静かに落ちて「全員拒否」相当のデータになる失敗(consent update の形式ミス・CSP による計測ブロック)も、同意管理とプライバシー で扱います。
接合率という一本の指標
4つの典型に共通するのは、広告接触 → 識別子(ID)→ 成果を一本で辿れないことです。この「辿れた割合」を一つの数で掴むのが接合率です。記述・予測編で spine coverage として導入した指標で、本回はそれを概念ではなく「測る側」で扱います。
操作的に定義すると、接合率は次のとおりです。
なぜ一本の指標として持つ価値があるのか。これが下流のすべての天井になるからです。予測モデルが学習に使える実弾、因果が突合できる対象、媒体に返せる実成果——どれも「接合できた範囲」に限られます。接合率が3割なら、どれだけ高度な手法でも実質3割のデータで動かすことになります。手法を選ぶ前に、自社の上限を数字で知っておく、という順序です。
一次データで見ると、経路によって接合率は大きく割れます。実在の受託案件(匿名・レンジ表記)で経路別に測ったところ、プラットフォーム内で完結するフォーム経由は手前の行動データがそもそも無く接合率はほぼゼロ、自社サイトのフォーム経由は大半が辿れる、というように経路でほぼ両極に分かれました。ここで重要なのは、全体を1つの平均値で出すと低接合の経路に引きずられて像を誤る、という点です。接合率は必ず経路別に分解して見ます。
実際に測る最小構成は次のようになります。成果(orders)を起点に、同一顧客の手前のセッションが辿れるかを判定し、経路別に割合を出します。SOLNA(架空D2C・既存連載と共通スキーマ)を例に、BigQuery想定で書きます。
-- 接合率(経路別): 成果のうち、手前の行動セッションまで辿れた割合
-- SOLNA: orders(成果) を customers 経由で sessions に突合する最小構成
with outcomes as (
select
o.order_id,
o.customer_id,
c.acquisition_channel as channel
from `solna.orders` o
join `solna.customers` c using (customer_id)
where o.order_type = 'first' -- 初回成果に限定(成果の定義を固定する)
and o.order_at >= '2026-01-01'
),
joined as (
select
x.order_id,
x.channel,
-- 成果より前に、同一顧客のセッション(広告接触/行動)が1つでも辿れるか
exists (
select 1
from `solna.sessions` s
where s.customer_id = x.customer_id
and s.session_start < x_first_order.first_order_at
) as has_spine
from outcomes x
join (
select customer_id, min(order_at) as first_order_at
from `solna.orders` group by customer_id
) x_first_order using (customer_id)
)
select
channel,
count(*) as outcomes,
countif(has_spine) as traceable,
round(countif(has_spine) / count(*), 3) as join_rate -- ← 経路別の接合率
from joined
group by channel
order by join_rate;この連載の地図(収集 → 同意 → 識別 → 保管 → 送信)
計測を5つの層に分けると、先ほどの4つの壊れがどの層の問題かを整理できます。各層を一文で置くと次のとおりです。
| 層 | 何をする層か | 主な扱い回 |
|---|---|---|
| 収集(collect) | イベントを発生源で正しく取る | 第2回(イベント設計)・第3回(sGTM) |
| 同意(consent) | 取ってよいデータかを判定する | 第4回(同意・プライバシー/弁護士確認前提) |
| 識別(identify) | 広告接触と成果を同一人物に束ねる | 第5回(ID統合・接合率) |
| 保管(store) | 後で結合・監査できる形で残す | dbt連載(整える)へ接続 |
| 送信(activate) | 実成果を媒体最適化へ返す | 第6回(Conversions API)・第7回(クリーンルーム) |
二重計上は収集層、Cookie規制の分断は識別層、同意の混入は同意層、媒体CV≠実成果は収集と送信の定義のずれ——というように、症状を層へ割り付けられると打ち手が定まります。第1回ではこの5層を地図化し、GA4が5層のどこに強く、どこに構造的に届かないかを切り分けます。GA4が悪いのではなく、得意な層と自前設計が必要な層があるという役割の話です。
読者の現在地チェック
自社がいまどの段階にいるかは、次の3つの問いで自己診断できます。
- 媒体CVを実成果と同一視していないか。成果はCRM(実成約・手数料・LTV)に、媒体CVは媒体に置いて、別物として扱えているか。
- 接合率を一度でも測ったか。上のSQLを自社スキーマに当てて、経路別に1回出してみたか。
- 5層のどこが弱いか、言葉にできるか。
どれかが「No」なら、入口は明確です。接合率を経路別に測る → 弱い層を特定する → 該当回へ進む、が最短ルートになります。大事なのは「全部いっぺんに直す」ことではなく、下流の意思決定を変える順に直すことです。測れないものを測れたことにせず、辿れる範囲を最大化する——計測設計は、その地道な配分の問題です。
章末チェックリスト
- 媒体CVを実成果と同一視していないか
- 接合率を経路別に一度でも測ったか
- 計測の5層(収集 → 同意 → 識別 → 保管 → 送信)で自社を俯瞰したか
- 「辿れなかった成果」を施策構造の問題と計測の穴に分けて数えているか
参考(補助)
この領域は良質な書籍が薄く、公式ドキュメントや個別ツール記事への依存が起きやすい性質があります。本連載はそれらを本文に並べず私的参考に留め、概念と自社の一次データ(接合率レンジ)で説得力を担保します。入口として、計測・広告効果測定の入門書を一冊持っておくと全体地図が描きやすくなります。
「何を測り、どの意思決定を動かすか」という判断の側は、対になる記述・予測編 本当の成果で測る にまとめています。次回(第1回)は、計測設計の全体地図とGA4の構造的限界を、5層で切り分けて見ます。