結論
拡張コンバージョン（リード）は、設定画面で有効化すれば完了する施策ではありません。フォームで取得した情報と、CRMや営業管理表に記録された商談・受注情報が、同じ定義と形式で継続的につながって初めて計測基盤として機能します。
Googleは、拡張コンバージョン（リード）について、ウェブサイトで取得したユーザー提供データとオフライン成果を用いて広告接点との照合を補完する仕組みとして案内しています。実装時は、技術設定だけでなく、取得目的、同意、社内のデータ管理、営業ステータスの品質まで含めて点検する必要があります。
1. 先に「何を成果として返すか」を決める
フォーム送信、有効リード、商談、受注では、事業にとっての価値も発生までの期間も異なります。複数の成果を取り込む場合は、名称だけでなく判定条件を文書化します。
- 有効リードに含める条件と除外条件
- 商談として記録するタイミング
- キャンセルや重複をどう扱うか
- 受注金額や粗利をいつ確定するか
- ステータスを更新する担当者と期限
営業担当ごとに判定が異なれば、連携が正常でも広告側へ不均一なデータが返ります。まず一貫して記録できる成果から始めます。
2. 取得・保存・送信の経路を一枚にする
フォーム入力からGoogle広告への連携まで、どのシステムが何の情報を保持するかを書き出します。メールアドレスや電話番号は、表記ゆれや空欄によって照合品質が変わるため、入力時と送信前の形式を確認します。
ハッシュ化は重要な技術的処理ですが、それだけで個人情報やプライバシーに関する確認が不要になるわけではありません。プライバシーポリシー、同意表示、社内規程、アクセス権、保存期間、Googleの顧客データに関する規約は、法務・情報システム部門などの専門担当者と確認します。
3. 成功件数だけでなく診断結果を見る
データ連携の運用では、アップロードの成否だけでなく、次の状態を定期的に確認します。
- 送信対象件数と実際の送信件数
- 必須項目の欠損や形式エラー
- 同一成果の重複送信
- 成果発生から送信までの日数
- タグや連携元の変更履歴
- 拡張コンバージョンの診断レポートに表示される警告
件数が急に減った場合、広告成果が落ちたとは限りません。フォーム改修、CRM項目の変更、担当者の入力遅延など、計測経路の障害を先に切り分けます。
4. 広告と営業で週次点検を分担する
広告担当だけでは、商談・受注データの妥当性を判断できません。営業側はステータスと失注理由、広告側はタグ・連携・診断結果を確認し、週次で差分を共有します。
変更を行う際は、変更日、対象項目、理由、想定される影響、確認日を記録します。入札目標、コンバージョン定義、データ連携を同時に変更すると原因が分かりにくくなるため、影響を観察できる単位に分けます。
拡張コンバージョン（リード）を導入する目的は、送信件数を増やすことではありません。広告接点から商談・受注までを同じデータ定義でつなぎ、成果を継続的に検証できる状態を保つことです。技術設定、営業運用、プライバシー確認を週次点検の対象に組み込み、変更のたびに記録を更新することが、計測を止めない体制につながります。