フォーム・電話・CRMを1本のIDで貫く。ファーストパーティUUIDによる計測設計

「この成約、もともとどの経路で来た人でしたっけ」に答えるため、CRMの電話番号とフォームの電話番号を突き合わせる。ハイフン有無を揃え、国番号を正規化し、それでも家族の番号で登録されていて合わない。属性での突合には、こういう限界が常につきまといます。

ある案件で、この突合を属性頼みからID頼みに切り替える設計をやりました。サイト訪問者ごとにファーストパーティのUUID（＝自社ドメインで発行・保持する固有ID）を振り、それをフォーム・アクセスログ・電話・CRMまで引き回す。この記事ではその設計を、各つなぎ目の実装方式と「IDでも解決しないこと」まで含めて書きます。

結論：発行は1箇所、配る先は4箇所

設計の全体像です。

訪問者がサイトに来る
  └─ GTMのカスタムHTMLタグでUUIDを発行・保持（localStorage + Cookie の二重持ち）
       ├─ ① GA4へ：イベントパラメータとして送信 → アクセスログと紐づく
       ├─ ② フォームへ：隠しフィールドに注入 → 送信データと紐づく
       ├─ ③ 電話タップへ：tel:リンクのクリックイベントに付与 → 通話と紐づく（後述）
       └─ ④ CRMへ：フォーム転記時にID列へ書き込む → 成約と紐づく

発行ロジックはGTMのカスタムHTMLタグに置きます。要点は2つです。

• localStorageとCookieの二重保持。SafariのITP（トラッキング防止機能）はスクリプトが書いたCookieの寿命を縮めるため、片方が消えても復元できるようにする。有効期限は2年に設定
• 既存IDを優先し、なければ生成。訪問のたびに新しいIDを振ってしまったら全部が台無しになるので、読み取り→なければ生成→両方に保存、の順を固定する

つなぎ目ごとの実装

① GA4：イベントパラメータで送る

GA4設定タグのパラメータにUUIDを渡します。ここで1つ罠があり、カスタムHTMLタグが作った値をデータレイヤー変数で受けると、タグ実行順の関係で空のまま送信されます。ストレージを直接読むカスタムJavaScript変数で受けるのが正解です（この罠は別記事に詳しく書きました）。

BigQueryにGA4をエクスポートしていれば、これで「UUID→閲覧したページ全履歴・流入チャネル」が引けるようになります。

② フォーム：隠しフィールドに注入

フォームに hidden フィールドを置き、GTMからUUIDを書き込みます。外部フォームサービス（Jotform等）でも、埋め込み時にURLパラメータやプリフィル機能で渡せます。これで送信1件ごとにUUIDが残り、①と合わせて「この問い合わせの人は、何で検索してどのページを読んでいたか」が確定します。

③ 電話：IDは渡せない。時刻で接続する

電話だけは性質が違います。よくある誤解が「タップした人の電話番号が分かるのでは」というものですが、Webページは訪問者の電話番号を知り得ません。ブラウザにそんなAPIはないからです。

代わりにやるのは時刻突合です。tel:リンクのタップ時に「UUID・ページ・時刻」をサーバーに送っておき、クラウドPBX（電話システム）側の着信ログと「同じ番号への着信が、タップから2分以内に始まったか」で結びつけます。実運用では、2分以内の一致を高確度、それ以降を低確度として段階づけました。タップせず番号を手打ちする人は拾えませんし、確率的な接続であることは割り切る。それでも「電話経由は経路不明」という状態からは大きく前進します。

④ CRM：転記時にID列を埋める

フォームからCRMへ問い合わせを転記する処理（自動化ツールやワークフロー）に、UUIDのマッピングを1列足すだけです。実装としては最小ですが、ここが埋まって初めて「流入→閲覧→問い合わせ→商談→成約」が1本につながります。

優先順位をつけるなら、私はここを最初にやります。電話番号・メールでの突合と違って1対1で確定し、誤マッチがなくなる。分析の信頼性が一段変わります。

IDでも解決しないこと

正直に書いておきます。

• デバイス跨ぎ：スマホで調べてPCで問い合わせる人は別IDになります。ログイン基盤がない限り原理的に避けられません
• ブラウザ・クッキー消失：プライベートブラウジングや端末変更でIDは切れます。だからこそ電話番号・メールでの突合を捨てず、「ID一致→確定、ID欠損→属性でフォールバック」の二段構えにします
• 過去への遡及：仕込んだ日からしかデータは溜まりません。早く始めるほど資産になります

アンチパターン：完璧なID設計を待って何も仕込まない

クロスデバイスが解決できないなら意味がない、と着手を止めるのが一番の損です。実測では、問い合わせ者の9割前後が同一ブラウザで完結していました。まず①と②（GTM半日分の作業）だけで分析の土台はでき、③④は後から足せます。計測設計は一発の完成形ではなく、つなぎ目を1個ずつ増やしていく類の仕事です。

なお、広告クリックID（gclid）をオフラインコンバージョンに戻す設計はこちらの記事で書きました。gclidは広告経由しか持てないIDなので、本記事のUUIDはその上位互換ではなく補完です。広告もオーガニックも電話も同じ背骨に載せたい場合に、この設計が効きます。

まとめ

• 属性（電話番号・メール）での突合は揺れでこぼれる。ファーストパーティUUIDを背骨にする
• 発行はGTMで1箇所、localStorage+Cookie二重保持。配る先はGA4・フォーム・電話タップ・CRMの4箇所
• 電話はIDを渡せないので時刻突合で接続する
• ID一致を主、属性突合をフォールバックにした二段構えが実務解

問い合わせデータと広告・アクセスデータがつながらない状態の整理、ID設計から突合基盤の構築までを支援しています。お問い合わせはこちら。