識別子の統合と接合率の作り方 ― 広告接触から成果までを一本に

広告接触・行動・成果を、どうやって一人の顧客として辿るのか。答えは、ファーストパーティIDとIDリソリューションでそれらを紐付け、「辿れた割合＝接合率」を測り、引き上げ、監視し続けることです。この回では、customer_id と ga_client_id をどう束ねて接合率を作るかを、SOLNA（過去の受託案件をもとに設計した架空D2C・連載共通スキーマ）のBigQueryで具体化し、下流の予測・因果・最適化が「どこまで使えるか」を自分で測れる状態にします。

連載の前半（第0〜4回）で、計測を収集→同意→識別→保管→送信の5層に分け、収集と同意の前提を整えてきました。本回はその5層の中央に位置する「識別」を扱います。ここが連載の背骨です。記述・予測編の insights 記事では接合率を「測って手法を仕分ける」話をしましたが、本回はそれを「設計して上げる」側のコードを書きます。

なぜ識別が分析の上限を決めるのか

予測でも因果でも、その手前に「広告接触 → 識別子（ID）→ 成果」を一本に繋ぐ背骨が必要です。背骨が通っていない成果レコードは、どれだけ精緻なモデルを組んでも学習に使えません。識別ができていない成果は、分析にとって存在しないのと同じだからです。

ここで一度だけ定義を確認します。接合率とは、成果のうち、その手前の行動（あるいは広告接触）まで一本で辿れるものの割合です。接合率は、これから作ろうとする各手法の「適用可能な範囲の上限」を画定します。全成果の半分しか行動が紐づかないなら、予測モデルが学習に使える実弾はその半分。残りはモデルから見えません。

重要なのは、接合率が「繋がる／繋がらない」の二択ではなく、流入経路ごとに濃淡を持つことです。だから「自社の接合率は何パーセントか」を単一の数字で答えるのは粗すぎます。経路別に測って初めて、どこを直せば上限が上がるかが分かります。

ファーストパーティIDとIDリソリューション

識別の素材は二種類に大別できます。

ひとつはファーストパーティID。自社が発行・保持する識別子で、会員ID（SOLNAなら customer_id）、ログインアカウント、ハッシュ化したメールアドレスなどが該当します。サードパーティCookieの規制が進んでも、これは自社の資産として残ります。識別設計の主役はここです。

もうひとつはデバイス/ブラウザ単位の識別子。GA4の ga_client_id（Cookieスコープ）や、広告クリックに付く gclid / fbclid がこれにあたります。これらは「行動」と「広告接触」を捉える側ですが、Cookieの寿命やデバイスをまたぐと途切れます。

**IDリソリューション（ID resolution・名寄せ）**は、これら複数の識別子を「一人の顧客」に束ねる作業です。やり方は大きく二つあります。

決定論的（deterministic）な紐付けは、確かなキーで結合します。ログイン時や、フォーム送信時に ga_client_id を hidden field でCRMへ引き渡す、といった方法です。B2Bや会員ECでは、これが背骨の中心になります。

確率論的（probabilistic）な紐付けは、端末・IP・行動パターンの類似から「同一人物らしさ」を推定します。決定論で埋まらない隙間を補えますが、誤った紐付け（別人を同一視する）リスクを常に抱えます。盛りすぎると、偽の接合で下流を汚します。ここで一言入れておくと、「接合率が確率論的マッチで急に上がった」ときは、上がったのではなく濁った可能性をまず疑うべきです。

設計上の肝は、結合キーを確保する場所が計測時（第2回のイベント設計）に決まっていることです。後から「繋ぎたい」と思っても、送信の瞬間に ga_client_id や gclid を成果側へ渡していなければ、決定論的な背骨は通りません。識別は識別の回だけの問題ではなく、イベント設計の段階で勝負が半分ついています。

実際、筆者が運用している都内のオフィス仲介サイト（匿名化した受託案件・数値はレンジで表記）では、CVフォームをCRM（HubSpot）のフォームで実装しているため、サイトフォーム経由の主経路は ga_client_id と gclid / fbclid を hidden field で成果側に渡し、広告接触→行動→成果が決定論的に一本で通っています。一方で、媒体内で完結するインスタントフォーム経由は成果ラベルしか取れず、行動の背骨がそもそも存在しません。これは計測の穴ではなく、経路の構造的な死角です。

接合率を測る

ここからコードです。SOLNAのスキーマで、成果（注文）が行動（セッション）まで辿れるかを測ります。最小の考え方は「成果の母数に対し、customer_id で行動セッションに紐づくものが何件あるか」です。

まず単純な全体接合率の最小構成です。

-- 全体接合率：新規成果のうち、行動セッションに一本で辿れる割合
WITH outcomes AS (
  SELECT customer_id, order_id, order_at
  FROM `solna.orders`
  WHERE order_type = 'first'              -- 新規獲得を母数にする
),
identified_sessions AS (
  SELECT DISTINCT customer_id
  FROM `solna.sessions`
  WHERE customer_id IS NOT NULL           -- 決定論的に紐づいたセッションのみ
)
SELECT
  COUNT(*)                                              AS outcomes_total,
  COUNTIF(s.customer_id IS NOT NULL)                   AS outcomes_with_behavior,
  SAFE_DIVIDE(COUNTIF(s.customer_id IS NOT NULL),
              COUNT(*))                                AS join_rate
FROM outcomes o
LEFT JOIN identified_sessions s USING (customer_id);

ただし全体接合率は粗い指標です。前述のとおり、どこを直せば上がるかは経路別でしか見えません。経路別、かつ「行動まで辿れたか」「広告接触（クリックID）まで辿れたか」を分けて測ります。

-- 経路別接合率：広告接触→行動→成果を一本に辿れるかを分解
WITH first_orders AS (
  SELECT customer_id, order_id
  FROM `solna.orders`
  WHERE order_type = 'first'
),
spine AS (
  SELECT
    o.order_id,
    c.acquisition_channel,
    -- 行動まで辿れたか（決定論的に紐づくセッションがあるか）
    EXISTS(
      SELECT 1 FROM `solna.sessions` s
      WHERE s.customer_id = o.customer_id
    ) AS has_behavior,
    -- 広告接触まで辿れたか（クリックIDが残っているか）
    EXISTS(
      SELECT 1 FROM `solna.sessions` s
      WHERE s.customer_id = o.customer_id
        AND (s.gclid IS NOT NULL OR s.fbclid IS NOT NULL)
    ) AS has_exposure
  FROM first_orders o
  JOIN `solna.customers` c USING (customer_id)
)
SELECT
  acquisition_channel,
  COUNT(*)                                                   AS outcomes,
  SAFE_DIVIDE(COUNTIF(has_behavior), COUNT(*))               AS behavior_join_rate,
  SAFE_DIVIDE(COUNTIF(has_exposure), COUNT(*))               AS exposure_join_rate
FROM spine
GROUP BY acquisition_channel
ORDER BY outcomes DESC;

このクエリの出力で、経路ごとに天井が見えます。決定論的な背骨が通っている経路（自社例ではサイトフォーム経由）は behavior_join_rate が高く、広告接触のクリックIDまで残っていれば exposure_join_rate も高い。逆に媒体内完結の経路は両方が低く、その低さが「その経路の成果に対しては予測も精緻なアトリビューションも効かない」という上限を意味します。

ここで、記述・予測編で置いた区別を実装の言葉で繰り返します。「行動なし」には二種類あります。そもそも行動接点が無い経路（施策構造の問題）と、接点はあったが同意拒否やCookie喪失で計測できなかった分（計測の穴）です。前者は導線設計、後者は計測設計で打ち手が違うので、可能なら別々に数えます。実務では、媒体名やランディングページで前者の経路をフラグ立てし、残差を後者として扱う、という近似がよく効きます。

自社の実数について、N=1の限界を明示しておきます。経路別接合率は媒体構成・同意UX・タグの改修履歴に強く依存し、季節や広告予算配分の変化と交絡します。だから「サイトフォーム経由は高く、インスタントフォーム経由はほぼゼロ」という構造の差は安定して観測できても、特定の数字を他社にそのまま当てはめることはできません。

接合率を引き上げる打ち手

接合率を上げる打ち手は、原因の二分類（構造の死角／計測の穴）に対応して整理できます。

第一に、決定論的アンカーを増やすこと。最も効くのは、成果が発生する瞬間に行動・広告接触の識別子を成果側へ確実に引き渡すことです。考え方は単純で、フォーム送信前に ga_client_id と gclid / fbclid を取得し、CRMコンタクトの hidden field に載せるだけです。

// 成果（CRMコンタクト）に、行動(client_id)と広告接触(gclid/fbclid)を
// 決定論的に引き渡す = 接合率のアンカー。送信の瞬間に確保する。
gtag('get', GA_MEASUREMENT_ID, 'client_id', (clientId) => {
  setHidden('ga_client_id', clientId);
  setHidden('gclid',  getParam('gclid'));   // 広告接触（Google）
  setHidden('fbclid', getParam('fbclid'));  // 広告接触（Meta）
  // 会員ログイン中なら customer_id も同時に載せる
});

ログイン導線を作る、会員化の動機を増やす、購入後のサンクスページでアカウント連携を促す——いずれも「決定論的に束ねられる接点」を増やす施策です。ツール固有の設定手順（sGTMの変数定義やCMPとの順序）は公式ドキュメントへ送り、ここでは原理だけを置きます。

第二に、計測の穴を塞ぐこと。これは第3回（サーバーサイド計測）・第4回（同意管理）と地続きです。サーバーサイドで customer_id を付与し直す、ファーストパーティCookieの寿命を延ばす、同意取得UXを改善して同意率自体を上げる。同意の有無で母集団が変わる以上、同意率の改善は接合率の改善でもあります。

第三に、構造の死角は計測ではなく施策設計で対処すること。行動接点がそもそも無い経路（媒体内完結のフォーム等）は、いくらタグを直しても背骨は通りません。打ち手は「その経路をサイト遷移型に寄せる」か、「別バケットとして成果ラベルだけで扱い、下流の手法から切り離す」かのどちらかです。ここを混ぜて一つのモデルに入れると、行動特徴が欠損した行が混入してモデルを濁します。

接合率を監視し続ける

接合率は一度作って終わりではなく、静かに壊れます。タグの改修、同意UXの変更、新しいランディングページ、ブラウザのCookieポリシーやSDK更新——どれも接合率を下げ得ます。第1回で「計測の品質保証は全層に通す横串」と書きました。識別層におけるその具体化が、接合率の継続監視です。

日次で経路別の接合率をスナップショット化し、時系列で見られるテーブルに落とします。

-- 日次・経路別の接合率スナップショット（壊れの検知用）
SELECT
  DATE(o.order_at)                                           AS d,
  c.acquisition_channel,
  COUNT(*)                                                   AS outcomes,
  SAFE_DIVIDE(
    COUNTIF(EXISTS(SELECT 1 FROM `solna.sessions` s
                   WHERE s.customer_id = o.customer_id)),
    COUNT(*)
  )                                                          AS behavior_join_rate
FROM `solna.orders` o
JOIN `solna.customers` c USING (customer_id)
WHERE o.order_type = 'first'
GROUP BY d, acquisition_channel;

このスナップショットに対して、移動平均からの乖離で急落を検知し、閾値を割ったら通知を飛ばす——という運用に乗せます。通知はReverse ETLでSlackに流すのが手軽で、これは活性化の連載（Reverse ETLとモデル駆動オーディエンス）で扱う「サイト行動トリガーの逆ELT通知」と同じ仕組みです。監視で大事なのは、絶対水準より変化を見ること。昨日まで高位だった経路が一晩で半分に落ちたら、それはタグかCookieか同意UXのどこかが折れたサインです。

監視を持つと、接合率は「一度測る指標」から「壊れを早期に教えてくれるセンサー」に変わります。下流の予測や因果が突然おかしくなったとき、原因がモデルなのか計測なのかを切り分けられるのは、この識別層のセンサーがあるからです。

章末チェックリスト

• 接合率の意味（広告接触→行動→成果を辿れる割合＝下流手法の上限）を自分の言葉で言えるか
• customer_id と ga_client_id の決定論的な結合を、計測時（フォーム/ログイン）に確保しているか
• 自社の接合率を、母数を新規コホートに固定して経路別に算出したか
• 「行動なし」を構造の死角と計測の穴に分けて数えたか
• 引き上げ施策の効果を接合率そのもので測り、確率論的マッチで盛っていないか
• 日次・経路別の接合率を監視し、急落を検知できる状態にしたか

ここまでで、広告接触から成果までを一本に辿る背骨と、その太さ（接合率）を測り・上げ・見張る仕組みができました。次回は、こうして作った「実成果」を媒体最適化に戻す前段——Conversions API／オフラインCV連携です。識別がつながっていれば、媒体CVではなく実際の成約・LTVを送り返せます。

設計の前提として「何を実成果として測るか」「接合率がどこまで遡れるか」を決める判断は、対になる記述・予測編（本当の成果で測る）に整理しています。あわせて読むと、本回のコードが「何のための上限づくりか」が腑に落ちるはずです。