CRMのリードソース設計｜広告・展示会・紹介の獲得経路を崩さない管理方法
広告、展示会、紹介、自然検索から見込み客が増えると、CRMの「リードソース」はすぐに崩れます。広告担当は媒体名、イベント担当は展示会名、営業は「紹介」と入力し、連携システムはUTMをそのまま書き込むため、同じ粒度で比較できなくなるからです。
必要なのは、すべての接点を一つの値へ押し込むことではありません。長期比較に使う大分類と、初回・直近の接点、顧客本人の申告、個別キャンペーンの履歴を分けます。CRM全体の役割はCRMとは何か、SFA・MAとの違いで確認できますが、この記事では獲得経路の分類と変更管理に絞ります。
本記事のポイント
- リードソースは媒体名や施策名を詰め込む欄ではなく、チャネル別の獲得を長期比較できる安定した大分類として設計する。
- 初回接点、直近接点、自己申告、個別キャンペーン、レコード作成元は別の問いに答えるため、一つの項目で上書きしない。
- 値の追加・統合・廃止はCRM管理者が承認し、フォーム、連携、レポート、自動化、過去データを同じ変更単位で検証する。
この記事の直接回答
CRMのリードソースは、広告、自然検索、展示会、紹介、パートナー、アウトバウンドなど、時間が経っても比較できる大分類として設計します。初回接点は原則として上書きせず、直近接点は条件を満たす新しい接点で更新し、本人の自己申告と個別キャンペーンは別の項目・履歴に残します。リードソースは「最後にクリックした媒体」ではなく、「顧客との接点を同じ粒度で残し続けるための分類規則」です。
リードソースは4種類の情報を分けて設計する
最初に「リードソース」という言葉で何を知りたいのかを分けます。Salesforceの標準Lead Sourceは、Advertisement、Partner、Webなどを例にした管理者設定の選択リストです。一方、キャンペーンは具体的な施策との関係を持ち、商談のPrimary Campaign Sourceは売上への主なキャンペーンを表します。同じ「獲得元」に見えても、答える問いは異なります。
HubSpotも、最初の既知接点を表すOriginal Traffic Sourceと、最近の接点を表すLatest Traffic Sourceを別に持ちます。また、レコードがインポートや連携など何によって作られたかはRecord Sourceで確認し、流入経路とは分けています。この考え方を製品に依存しないCRM設計へ置き換えると、少なくとも次の役割が必要です。
| 情報 | 答える問い | 更新ルール | 保存例 |
|---|---|---|---|
| 初回リードソース | 最初に把握できた接点は何か | 空欄のときだけ設定し、原則上書きしない | 自然検索、展示会、紹介 |
| 直近リードソース | 最近の有効な再接触は何か | 新しい外部接点が成立したとき更新する | メール、広告、ウェビナー |
| 自己申告ソース | 本人は何をきっかけと認識しているか | フォームや会話の回答を日時付きで残す | 同僚の紹介、展示会で知った |
| キャンペーン履歴 | どの具体的施策へ反応したか | 接点ごとに追加し、現在値で上書きしない | 展示会名、広告キャンペーン、資料DL |
| レコード作成元 | CRMにどう登録されたか | システムが記録し、流入元の代用にしない | フォーム、CSV、API、手入力 |
たとえば、自然検索で初めてサイトを訪れた人が、後日ウェビナーへ申し込み、営業との会話で「取引先から紹介された」と答えた場合、三つとも有効な情報です。最後の回答で初回ソースを「紹介」へ書き換えると、最初のWeb接点を失います。逆に、初回ソースだけを残すと、直近のウェビナー施策と本人が認識しているきっかけが見えません。
Google Analyticsも、ユーザー単位のFirst user sourceと、訪問ごとに変わるSession sourceを別のスコープとして扱います。GA4の値をそのままCRMへコピーする必要はありませんが、「初回」と「セッション単位の直近」を分ける発想は、CRMの上書き事故を防ぐ参考になります。
広告・展示会・紹介は3階層の粒度で分類する
分類は、全期間で比較する大分類、媒体や接点種別を表す中分類、個別施策を表す明細の3階層にすると扱いやすくなります。リード本体の選択リストには大分類を置き、媒体・施策の明細は別項目やキャンペーン履歴へ逃がします。大分類へ「東京DX展示会2026」「Google検索広告_7月」と入れると、施策が終わるたびに選択肢が増え、前年との比較もできません。
| 大分類 | 中分類の例 | 明細の例 | 入力元 |
|---|---|---|---|
| 有料検索 | Google広告、Yahoo!広告 | キャンペーンID、広告グループ、検索語 | 自動タグ・UTM・広告連携 |
| 有料ソーシャル | LinkedIn、Meta | キャンペーンID、広告、クリエイティブ | UTM・広告連携 |
| 自然検索 | Google、Bing、AI検索参照 | 入口ページ、参照ドメイン | アクセス解析・フォーム連携 |
| イベント | 展示会、ウェビナー、自社セミナー | イベントID、開催日、申込・参加状態 | 受付、配信ツール、CSV |
| 紹介 | 顧客紹介、社員紹介、専門家紹介 | 紹介元企業、紹介者、同意・確認日 | フォーム・営業入力 |
| パートナー | 販売代理店、協業先、マーケットプレイス | パートナーID、案件登録、紹介プログラム | ポータル・API・営業入力 |
| アウトバウンド | 架電、個別メール、営業接触 | リスト、担当、接触活動 | 営業活動・インポート |
| その他・不明 | 分類外、情報不足 | 原文、確認状況、補正理由 | 例外キュー |
大分類は、担当部門ではなく「同じ獲得行動として比較できるか」で決めます。ウェビナー担当と展示会担当が別でも、イベントという大分類の下で中分類を分ければ、全体と内訳の両方を見られます。紹介とパートナーは、単発の人脈紹介と契約に基づく継続チャネルで運用が違うなら分けます。
「その他」と「不明」も同じではありません。その他は既知だが現行分類に当てはまらない接点、不明は判断材料がない状態です。空欄は連携失敗や未入力と区別できないため、集計対象へ入ったレコードには明示的な状態を付けます。分類語の作り方はMarketing Opsのタクソノミー設計と共通しますが、CRMでは過去レコードと連携への影響まで管理します。
UTM・キャンペーン・自己申告を一つの項目へ上書きしない
UTMはWeb接点を識別する入力データであり、CRMの最終分類そのものではありません。Google Analyticsの公式ガイドは、手動キャンペーンでutm_source、utm_medium、utm_campaignを一貫して設定し、大文字と小文字の違いも別値として扱われると説明しています。UTM側の命名はUTM命名規則テンプレートで整えたうえで、CRMでは変換表を通して大分類へ正規化します。
| 元データ | CRMでの保存先 | 上書き条件 | 残す原本 |
|---|---|---|---|
| utm_source / utm_medium | 初回・直近の中分類と大分類 | 初回は空欄時のみ、直近は新しい外部セッション時 | 受信したUTM値、URL、取得日時 |
| utm_campaign / campaign ID | キャンペーン履歴 | 同一IDは更新、別施策は追加 | キャンペーンID、名称、接点日時 |
| 展示会・ウェビナー名 | イベントキャンペーンとメンバー履歴 | 参加状態は該当イベント内だけ更新 | 申込、参加、欠席、相談希望 |
| 紹介元 | 大分類「紹介」＋紹介明細 | 確認済みの新情報を追加し、初回は保持 | 紹介種別、企業、確認日、入力者 |
| 「何で知ったか」の回答 | 自己申告ソース | 回答ごとに履歴を残す | 選択値、自由記述、フォーム・会話の別 |
自己申告は、計測できなかった接点を補う有用な情報ですが、UTMやアクセス解析の「正解」に置き換えるものではありません。本人が最も印象に残ったきっかけと、最初のWeb接点が違うことはあります。両方を保持し、レポートでは「システム計測の初回」「システム計測の直近」「本人認識」を別軸で比較します。
イベントの場合も、リードソースへ展示会名を入れて終わりにしません。リード本体には大分類としてイベントを残し、具体的な申込・参加・欠席・相談希望はキャンペーンメンバーへ持たせます。値と営業フォローのつなぎ方はSalesforceキャンペーンメンバーステータスの設計で詳しく整理しています。
6ステップでリードソースを実装する
新しい選択リストを作る前に、現在の値がどこから来て、どのレポートと自動化で使われているかを確認します。実装は次の順で進めると、過去データを壊さず段階的に切り替えられます。
- 利用目的を3つ以内に固定する。チャネル別の獲得数、商談化率、費用対効果など、リードソースで答える問いを決めます。売上の全接点への貢献まで一つの項目で説明しようとせず、キャンペーン影響や別のアトリビューションモデルへ分けます。
- 現行値と入力元を棚卸しする。フォーム、MA、広告、展示会CSV、API、営業手入力から実際に入る値を抽出し、空欄、表記ゆれ、複数の意味を持つ値を数えます。値だけでなく、入力者、更新時刻、連携名も確認します。
- 大分類・中分類・明細の変換表を作る。既存値を新しい分類へ対応付け、対応不能は例外キューへ送ります。自動補正してよい表記ゆれと、人の確認が必要な紹介・パートナー・その他を分けます。
- 初回・直近・自己申告・キャンペーンの項目を分離する。各項目のデータ型、入力権限、更新条件、原本値、履歴を決めます。初回ソースを手入力で上書きできないようにし、修正が必要な場合は理由と承認を残します。
- 少数データで並行稼働する。広告、自然検索、展示会、紹介、パートナー、アウトバウンドを少なくとも1件ずつ通し、重複リード、既存顧客の再接触、Cookie拒否、UTM欠損、CSV再取込を再現します。旧項目と新項目を一定期間比較します。
- レポートと営業運用を切り替える。チャネル別件数だけでなく、空欄率、その他率、変換失敗、上書き回数、商談・キャンペーンへの接続を監視します。旧項目をすぐ削除せず、入力停止、参照切替、保持、廃止の順で閉じます。
Salesforceでは、リードを変換したとき、リードに関連するキャンペーンが商談のPrimary Campaign Sourceへ引き継がれる動作があります。複数キャンペーンがある場合は最も最近関連付いたキャンペーンが使われる仕様もあるため、「初回リードソース」と「商談の主キャンペーン」を同じ意味として集計しません。製品固有の自動設定は、移行テストで実際のレコードを確認します。
値の追加・統合・廃止を変更管理する
リードソースの値は、施策担当者が必要になるたび自由に追加するのではなく、CRM管理者またはMarketing Opsを管理責任者にします。申請には、既存値で表現できない理由、想定件数、入力元、レポート上の利用目的、開始日、終了条件を含めます。特定キャンペーンだけの名前なら、大分類へ追加せずキャンペーン履歴へ置くのが基本です。
| 変更 | 承認前の確認 | 実施方法 | 実施後の確認 |
|---|---|---|---|
| 新規追加 | 既存値との差、利用期間、入力元、集計目的 | 変換表、フォーム、連携、権限を同時更新 | 空欄・その他が減り、類似値が増えていない |
| 名称変更 | API値、レポート条件、翻訳、連携参照 | 表示名と内部値の影響を分けてテスト | フィルターと自動化が旧名を参照していない |
| 統合 | 統合先の意味、過去比較、件数、依存関係 | バックアップ後に対応表で一括変換 | 旧値件数、レポート差分、更新失敗を照合 |
| 廃止 | 新規入力を止める日、既存値の保持要否 | 先に無効化し、必要なら後から置換・削除 | 新規発生がなく、履歴と集計が説明できる |
Salesforceの公式仕様では、選択リスト値を削除すると既存レコードを別値へ置換でき、既存値を残したまま新規選択だけ止めたい場合は無効化を選べます。ただし、値名の変更や無効化はレポートのフィルターやバケットへ影響する場合があります。変更画面の操作だけで完了とせず、依存するレポート、Flow、数式、APIマッピング、データ連携を先に調べます。
月次では、値別件数、空欄率、その他率、手動修正率、変換失敗、入力元別の偏りを確認します。特定フォームだけ「不明」が増えた、展示会CSVだけ旧値が復活したといった兆候は、分類体系ではなく連携や運用の障害です。集計を自動化する場合も、BtoBマーケティングレポート自動化で扱うように、変換規則と例外件数をレポートの前提として残します。
公式仕様で確認できる判断根拠
製品ごとに項目名や自動更新条件は異なります。実装時は管理画面の現在値とあわせ、次の公式情報を確認します。
- Salesforce Help: Lead Fields：Lead Sourceが管理者設定の選択リストであり、Campaignとは別の項目であることを確認できます。
- Salesforce Help: When to Use Account Engagement Campaign or Source Field：初回接点を持つキャンペーンとSourceフィールドの役割差を確認できます。
- Salesforce Help: Lead Conversion Field Mapping：リード変換時のCampaignとPrimary Campaign Sourceの対応を確認できます。
- Salesforce Help: Remove a Picklist Value：値の置換、空欄化、無効化の違いを確認できます。
- HubSpot Knowledge Base: Understand Original and Latest traffic source properties：初回・直近の流入元、ドリルダウン、Record Sourceとの違いを確認できます。
- Google Analytics Help: トラフィックソースディメンションのスコープ：First userとSessionのスコープが異なることを確認できます。
- Google Analytics Help: カスタムURLでキャンペーンデータを収集する：UTM項目と命名の一貫性、大小文字の扱いを確認できます。
よくある質問
CRMのリードソースとは何ですか？
見込み客を最初に、または一定の更新規則で獲得したチャネルを表す分類です。広告、自然検索、イベント、紹介、パートナー、アウトバウンドなど、期間をまたいで比較できる大分類にします。特定の広告名や展示会名はキャンペーン履歴へ分けます。
初回接点と直近接点は別項目にすべきですか？
はい。初回接点は獲得の入口、直近接点は最近の再接触に答えるため、更新条件が違います。初回は原則固定し、直近は新しい外部接点が成立したとき更新します。自己申告とキャンペーン履歴も別に残すと、上書きで経路を失いません。
広告・展示会・紹介をどの粒度で分類しますか？
リード本体は有料検索、イベント、紹介などの大分類、補助項目は媒体・接点種別の中分類、キャンペーン履歴は具体的な施策名やIDに分けます。担当部門名や年度ごとの施策名を大分類へ追加し続けないことが重要です。
入力値の追加・統合を誰が管理しますか？
CRM管理者またはMarketing Opsが一つの変更窓口を持ちます。施策担当者は理由、入力元、利用期間、集計目的を申請し、管理者が既存値との重複、フォーム、連携、レポート、自動化、過去データへの影響を確認して承認します。
リードソースとアトリビューションは同じですか？
同じではありません。リードソースは接点を共通分類で残すデータ設計です。アトリビューションは、複数接点のどれへ成果や売上の貢献を配分するかという分析方法です。リードソース一項目だけで複数接点の貢献を説明しようとしません。
UTMがない展示会や紹介はどう記録しますか？
イベントID、受付・参加データ、紹介種別、紹介元企業、入力者、確認日など、オフライン接点専用の原本を残し、変換表で共通の大分類へ正規化します。Web流入のように見せるため架空のUTMを付けず、入力元と接点種別を明示します。
まとめ
CRMのリードソースは、広告、自然検索、イベント、紹介、パートナー、アウトバウンドなど、時間が経っても比較できる大分類として設計します。媒体名は中分類、具体的な施策名やIDはキャンペーン履歴へ分けると、選択肢が増え続けません。
初回接点は原則として保持し、直近接点、自己申告、キャンペーン、レコード作成元を別の情報として残します。追加・統合・廃止の承認窓口を一つにし、フォーム、連携、レポート、自動化、過去データを同時に検証すれば、施策が増えても獲得経路を説明できるCRMを維持できます。
