広告クリックIDの保存・引き継ぎ管理｜GCLID・MSCLKIDをCRMの商談までつなぐ方法
Google広告やMicrosoft広告の流入を商談・受注まで評価したい場合、ランディングページに付くGCLIDやMSCLKIDをフォーム送信時だけ保存しても不十分です。フォーム、MA、CRM、SFAのどこかで値が消えたり、再訪時に上書きされたり、リード統合で元の接点が失われたりすると、オフラインコンバージョンを正しい広告クリックへ戻せません。
安全な設計は、クリックIDをUTMやリードソースと別の原本として取得し、内部のリードIDと接点履歴に結び付け、商談化・受注後も参照できる形で保持することです。初回と直近の表示用項目だけでなく、クリックごとの履歴、取得時刻、同意状態、統合元、送信結果を残すと、欠損と二重送信を切り分けやすくなります。
クリックIDの引き継ぎが完了するのは、フォームに値が入った時ではなく、リード統合後の商談・受注イベントまで元の接点と送信結果を追跡できた時です。
本記事のポイント
- GCLIDとMSCLKIDはUTMやリードソースと分け、文字列を加工せずクリックごとの接点履歴へ追記します。
- フォーム、MA、CRM、商談は自社の不変なリードIDでつなぎ、重複統合後も全接点を正規人物へ残します。
- 送信前に広告アカウント、成果名、時刻、期限、金額、同意、重複キーを媒体別に照合します。
GCLID・MSCLKIDをUTMと分けて保存する
GCLIDはGoogle Click Identifier、MSCLKIDはMicrosoft Click IDで、広告クリックを広告プラットフォーム側の記録と結び付けるための識別子です。Google広告の自動タグ設定では広告のリンク先URLにgclidが追加され、リダイレクトを使う場合も最終ランディングページまで渡す必要があります。Microsoft Advertisingでも、オフラインコンバージョンのMicrosoftClickIdとしてMSCLKIDを受け取ります。
これらはutm_source、utm_medium、utm_campaignの代替ではありません。UTMは人が読めるキャンペーン分類に向き、クリックIDは広告側の個別クリックと照合するための不透明な値です。UTMの命名はUTM命名規則テンプレートで統一し、CRMではクリックIDを別列・別オブジェクトに保存します。
| データ | 主な用途 | 保存単位 | 上書き方針 |
|---|---|---|---|
| GCLID | Google広告クリックとオフライン成果の照合 | クリック接点ごと | 文字列を加工せず履歴追加。大文字小文字を保持 |
| MSCLKID | Microsoft広告クリックとオフライン成果の照合 | クリック接点ごと | 履歴追加。別媒体のIDで上書きしない |
| UTM | 媒体・施策・クリエイティブの集計 | セッションまたは接点ごと | 原本辞書に沿って保存し、クリックIDと別管理 |
| リードソース | 広告・展示会・紹介などの安定した大分類 | リードまたは取引先責任者 | 初回、直近、自己申告を分離 |
| 社内リードID | フォーム、MA、CRM、商談をつなぐ主キー | 自社レコードごと | 外部IDとは別に不変の値を発行 |
クリックIDは「Google広告から来た」「Microsoft広告から来た」という分類値ではありません。値の形式を独自に解析して意味を推測したり、短縮・大文字小文字変換をしたりせず、取得した原文をそのまま扱います。Googleの公式手順も、GCLIDは大文字と小文字が区別されるため、正しく保存・アップロードするよう求めています。
クリックIDだけをリード本体の1項目へ保存すると、同じ人が別の広告を再度クリックした時にどちらかが消えます。実務では、リード本体に「初回GCLID」「直近GCLID」「初回MSCLKID」「直近MSCLKID」を表示用に持たせても、原本は接点履歴テーブルへ追記します。接点履歴には媒体、クリックID、UTM、ランディングページ、取得時刻、同意状態、フォーム送信IDをまとめ、後から表示項目を再計算できるようにします。
フォーム・MA・CRM・商談を一つの内部IDでつなぐ
引き継ぎの中心はGCLIDやMSCLKIDそのものではなく、自社が発行する不変の内部IDです。フォーム表示時にURLから許可済みのクリックIDを取得し、ブラウザ内だけに依存せず、フォーム送信レコードへ格納します。送信成功後はフォーム送信IDと社内リードIDを結び、MAやCRMへの連携ジョブが再試行されても同じ対応を使います。
ランディングページから入力フォームまでリダイレクトや別サブドメインを挟む場合は、クリックIDがどの地点で消えるかを実測します。Googleは、リダイレクトを使うサイトでは最終ランディングページまでGCLIDを渡す必要があると説明しています。URLパラメータを一律削除するCDN、短縮URL、フォームサービス、同意管理ツール、SPAのルーティング、サーバー側リダイレクトは、テスト用クリックIDで経路を通して確認します。
フォームのhidden項目に値が見えるだけでは、保存完了ではありません。次の対応表を作り、各システムの項目型、最大長、NULLと空文字の扱い、更新権限、再送時の冪等条件を固定します。
| 段階 | 最低限残すもの | 主な欠損原因 | 照合キー |
|---|---|---|---|
| ランディングページ | クリックID、UTM、取得時刻、同意状態 | リダイレクト、URL正規化、同意前の取得停止 | 匿名セッションID |
| フォーム送信 | 送信ID、クリックID、フォーム種別、送信時刻 | hidden項目欠落、外部フォームの項目制限 | フォーム送信ID |
| MA | 社内リードID、接点履歴ID、同期状態 | 空欄上書き、項目マッピング漏れ | 社内リードID |
| CRM | 初回・直近表示値、全接点履歴、統合元ID | 重複統合、リード変換、手動編集 | 社内リードIDと接点履歴ID |
| 商談・受注 | 商談ID、成果種別、成果時刻、金額、通貨 | リードとの関連付け切れ、複数商談の混同 | 商談IDと成果イベントID |
| 広告送信 | 送信対象、プラットフォーム、応答、エラー、再送回数 | 期限超過、時刻ずれ、目標名不一致、二重送信 | 成果イベントID |
CRMのリード統合では、勝ちレコードの1項目だけを残すと負けレコード側のクリックIDが失われます。統合前に両方の接点履歴を共通の正規リードへ付け替え、元リードID、統合日時、統合ルールを残します。表示用の初回値は最も古い有効接点、直近値は最も新しい有効接点から再計算します。CRMの獲得経路全体はCRMのリードソース設計と組み合わせると、クリック単位の証拠と長期集計の分類を混同せずに済みます。
リードから取引先責任者や商談へ変換する製品では、標準の項目マッピングだけで履歴オブジェクトまで移るとは限りません。変換後の正規人物IDを接点履歴へ追記し、商談には人物またはキャンペーン接点を関連付けます。1人から複数商談が生じる場合は、同じクリックIDを全商談の受注へ機械的に送らず、広告接点後の対象期間、商談作成経路、成果定義に合うものだけを選びます。
同意管理も別の証跡として保持します。クリックIDがあること自体は、計測や広告プラットフォームへの送信について同意があることを意味しません。適用法令、契約、利用している同意管理プラットフォーム、GoogleやMicrosoftの最新ポリシーに合わせ、取得時と送信時の同意状態、ポリシーバージョン、地域、停止理由を記録します。広告・分析タグの発火条件を変える場合は、実装担当だけで判断せず、法務・プライバシー担当と確認してください。
8ステップで取得から送信まで実装する
- 広告アカウントと成果定義を固定する。
Google広告とMicrosoft Advertisingで自動タグ設定、対象アカウント、コンバージョン目標、計測期間、主・補助の扱いを確認します。「商談化」「有効商談」「受注」など複数段階を測る場合は、段階ごとに成果イベントを分け、同じ成果名へ押し込みません。 - URLパラメータの通過試験をする。
本番と同じCDN、リダイレクト、サブドメイン、フォーム、同意画面を通し、テスト用のgclidとmsclkidが最終フォームまで変化せず届くか確認します。公開URLへ実在の他社クリックIDを流用せず、明確なテスト値を使います。 - フォーム送信IDと内部リードIDを発行する。
クリックIDを主キーにせず、フォーム送信とCRMレコードに自社IDを付けます。同じ送信が再試行されても同じIDを使い、二重リードと二重成果を防ぎます。 - 接点履歴を追記型で保存する。
クリックID、媒体、UTM、ランディングページ、取得時刻、フォーム送信ID、同意状態を1接点として保存します。リード本体の初回・直近項目は参照用とし、履歴原本を上書きしません。 - MA・CRM連携の空欄上書きを止める。
連携元が空欄の時に既存のクリックIDを消さないよう更新条件を設けます。別媒体のIDを同じ列へ入れず、GoogleとMicrosoftを分離します。失敗キュー、再送回数、最終成功時刻を監視します。 - 重複統合とリード変換を試験する。
同じメールアドレスで別の広告接点が2件あるケース、既存顧客の再訪、手動作成済みリードとの統合、リードから商談への変換を試します。勝ちレコードだけでなく、全接点が正規人物へ残ることを確認します。 - 成果イベントを広告形式へ変換する。
商談化や受注の内部イベントから、クリックID、コンバージョン名、発生時刻、金額、通貨を作ります。GoogleとMicrosoftで時刻形式、対象期間、必須項目が異なるため、共通CSVをそのまま両方へ送らず、媒体別アダプターで変換します。 - 少量送信と結果照合から定常運用へ移す。
まず補助コンバージョンまたは検証用の少量データで、受理・拒否・重複・期限超過を確認します。送信件数、受理件数、広告管理画面の反映、CRMの成果件数を日次で突き合わせ、差分理由を分類してから自動入札への利用範囲を広げます。
Googleは、GCLIDを使うオフラインコンバージョンでは自動タグ設定、URLに追加されたGCLIDの取得、見込み顧客情報との関連付け保存を要件として示しています。また、2026年9月3日時点の公式案内では、新規導入ではリードの拡張コンバージョンから始めることを推奨しています。既存のGCLID方式を続ける場合も、将来の移行を考え、クリックIDだけに依存しない社内リードIDと同意証跡を整えておく方が安全です。
Microsoft Advertising APIでは、オフライン成果にConversionName、ConversionTime、任意の金額・通貨、MicrosoftClickIdなどを指定します。APIの時刻はUTCが必要で、コンバージョンは過去90日以内かつ広告クリックより後、設定したコンバージョン期間内である必要があります。管理画面アップロードとAPIで時刻の扱いが違うため、CRMのローカル時刻をUTCへ変換した値と元タイムゾーンを両方保持します。
送信前に欠損・重複・時刻・期限を照合する
オフラインコンバージョンは、APIがHTTP 200を返しただけでは正しく計測されたと判断できません。送信前の適格性、送信応答、広告管理画面への反映、CRM原本の4段階を分けて確認します。媒体別にエラー理由を保存し、同じデータを修正せず再送し続けない運用が必要です。
| 確認項目 | Google側の注意 | Microsoft側の注意 | 自社で残す証拠 |
|---|---|---|---|
| クリックID | 大文字小文字を保持し、対象アカウントのクリックか確認 | MSCLKIDと対象アカウント・目標を確認 | 接点履歴ID、取得元、原文、取得時刻 |
| 成果名 | アップロード先に存在するコンバージョン名と一致 | 既存のオフラインコンバージョン目標名と一致 | 社内成果種別との変換表 |
| 成果時刻 | クリックより後。タイムゾーンとデータソース別対象期間を確認 | APIはUTC、過去90日以内、目標の期間内 | 原時刻、タイムゾーン、UTC変換値 |
| 重複 | 同じGCLID・成果名・成果時刻の組み合わせを管理 | 同じMSCLKID・成果時刻の重複は最初の1件のみ | 不変の成果イベントID、送信履歴 |
| 金額・通貨 | 受注、税、取消、返金の定義を固定 | 省略時の目標既定値に注意 | 原通貨、換算日、換算レート、調整履歴 |
| 同意・送信可否 | 同意モードと最新ポリシーを確認 | 適用ポリシーと取得条件を確認 | 同意状態、規程版、停止理由 |
Googleの公式FAQでは、同じGCLID、Conversion_Name、Conversion_Timeの組み合わせは重複として処理され、最初の1件だけが数えられると説明されています。Microsoftも、同じMicrosoftClickIdとConversionTimeの重複は無視し、目標のCountTypeがAllなら異なる時刻の複数成果、Uniqueなら広告クリック後の最初の成果だけを数えるとしています。媒体側の重複排除だけに頼らず、自社側では商談段階・受注・取消ごとに不変の成果イベントIDを発行し、同じ論理イベントを二度作らないようにします。ブラウザとサーバーのイベント重複を扱う場合は、Meta CAPIのevent_id重複排除も同じ考え方の参考になります。
監視指標は「送信成功率」だけでは足りません。クリックID取得率、フォームからCRMまでの保持率、リード統合後の履歴保持率、クリックから成果までの経過日数、期限超過率、目標名不一致、時刻エラー、重複判定、送信から反映までの遅延を媒体別に出します。広告管理画面のコンバージョン数とCRMの受注件数は定義や帰属期間が異なるため、完全一致を期待せず、差分理由を説明できる状態を目標にします。
週次・月次のレポートでは、広告費、クリック、リード、商談、受注を同じ粒度へ無理に揃えません。クリックIDで照合できた成果、UTMやキャンペーンで集計した成果、自己申告しかない成果、識別不能な成果を分けます。定期集計の設計はBtoBマーケティングレポート自動化に沿って、変換規則と例外件数もレポートの前提に含めます。
よくある質問
広告クリックIDはフォーム送信からCRMへどう保存しますか？
ランディングページでGCLIDまたはMSCLKIDを取得し、フォーム送信IDと一緒に保存します。送信後は自社の不変なリードIDへ接点履歴として紐付け、MA・CRMの連携では空欄上書きを防ぎます。リード本体の初回・直近項目は表示用とし、クリックごとの履歴を原本にします。
GCLID・MSCLKIDの上書きと欠損をどう防ぎますか？
GoogleとMicrosoftを別項目にし、取得した文字列を加工せず追記型で保存します。リダイレクト、サブドメイン、外部フォーム、同意画面を通すE2Eテストを行い、連携元が空欄の更新では既存値を消さない条件を設定します。
リード統合や商談化後もクリックIDをどう引き継ぎますか？
統合前の全接点履歴を勝ちレコードの正規人物IDへ付け替え、元リードIDと統合日時を残します。商談には正規人物またはキャンペーン接点を関連付け、1人に複数商談がある場合は対象期間と成果定義に合う商談だけを広告送信対象にします。
オフラインコンバージョン送信前に何を検証しますか？
クリックID、広告アカウント、成果名、成果時刻、タイムゾーン、クリック後の経過日数、金額、通貨、同意状態、重複キーを確認します。少量送信後に受理結果、部分エラー、広告管理画面への反映、CRM原本を突き合わせます。
GCLIDとUTMは両方保存すべきですか？
両方保存します。GCLIDはGoogle広告側のクリック照合、UTMは媒体・施策・クリエイティブの集計に使います。どちらか片方で代用せず、同じ接点履歴に別フィールドとして残すと、クリック照合できないケースでもキャンペーン単位の分析を続けられます。
クリックIDがないリードは捨てるべきですか？
捨てません。直接流入、紹介、展示会、同意条件、ブラウザ制約、連携障害などでクリックIDがないリードは存在します。識別不能を空欄のままにせず理由コードを付け、UTM、リードソース、自己申告、キャンペーン参加履歴など別の証拠と分けて評価します。
関連ページと関連記事
- UTM命名規則テンプレート：クリックIDと併記するsource、medium、campaignの原本を整えます。
- CRMのリードソース設計：初回・直近・自己申告・キャンペーンを分けて獲得経路を管理します。
- MetaコンバージョンAPIの重複排除：不変のイベントIDと再送時の冪等性を整理できます。
- BtoBマーケティングレポート自動化：広告、リード、商談、受注の集計差を継続監視する方法を確認できます。
