BtoBのオフラインコンバージョン送信｜設計と実装の完全ガイド

オフラインコンバージョン送信とは何か（BtoBで重要な理由）

このセクションでわかること：オフラインコンバージョン送信の定義と、なぜBtoB広告でこの仕組みが効くのかを整理します。

まず用語を整理します。コンバージョンには大きく二種類あります。ひとつは、フォーム送信や資料ダウンロードのように、ウェブサイト上で完結し媒体がその場で計測できる「オンラインコンバージョン」です。もうひとつが、商談化や受注のように、ウェブの外、たとえば営業のやり取りやCRM上の処理として後日発生する「オフラインコンバージョン」です。オフラインコンバージョン送信とは、この後者を媒体に手動またはシステム連携で送り、広告効果として扱えるようにする作業を指します。

BtoBでこれが重要になる理由は、検討期間の長さと意思決定者の多さにあります。BtoCのように「クリックして即購入」という流れはまれで、フォーム送信のあとにインサイドセールスの架電、商談、稟議、見積もりといった工程を経て受注に至ります。媒体が見えているのはこの入り口だけです。入り口の件数（フォーム送信）だけを最適化の目標にすると、媒体は「とにかくフォームを埋めやすい層」へ配信を寄せます。これは必ずしも「受注しやすい層」と一致しません。むしろ、無料の情報目的で資料請求するだけの層を集めてしまうことすらあります。

オフラインコンバージョン送信は、この情報の非対称を解消します。受注や商談化を媒体に返せば、媒体は「どんなキーワード・クリエイティブ・ユーザー属性が受注につながったか」を学習でき、配信が本来の事業成果へ向きます。これはアトリビューションの考え方とも地続きです。経路ごとの貢献度を可視化する話はBtoBのアトリビューション分析で詳しく扱っていますが、オフラインコンバージョン送信は「可視化」にとどまらず「媒体の最適化そのものを動かす」点が異なります。

広告に投資しているのに商談が増えないと感じている場合、配信設定そのものより「何をコンバージョンとして数えているか」に原因があることが少なくありません。自社の広告とCRMをどう接続すべきか整理したい方は、こちらからご相談ください。

仕組み：クリックと成果をどう結びつけるか

このセクションでわかること：媒体が「どのクリックが受注になったか」を判定するための、二つの照合のしくみを説明します。

送信したオフラインコンバージョンが意味を持つのは、媒体側が「その成果は、過去のどの広告クリックから生まれたものか」を結びつけられたときだけです。この紐づけ（マッチング）には、大きく二つの方法があります。

ひとつは、クリック識別子を使う方法です。Google広告では、広告がクリックされるたびにGCLIDと呼ばれる固有のIDがURLに付与されます。フォーム送信時にこのGCLIDを取得してCRMに保存しておき、後日その人が受注したタイミングで「このGCLID＝受注」という情報をアップロードします。媒体は受け取ったGCLIDを過去のクリックと突き合わせ、該当キャンペーンの成果として計上します。

もうひとつは、ユーザー提供データを使う方法です。クリック識別子ではなく、フォームで取得したメールアドレスや電話番号をハッシュ化（暗号化して復元できない形に変換）して送り、媒体側のログイン情報と照合します。GCLIDの取得・保存の実装が不要なため、これから始める企業にとって導入しやすいのが特徴です。Google広告の「リードの拡張コンバージョン」やMetaのコンバージョンAPIは、基本的にこの考え方に立っています。

どちらの方法でも、前提になるのは「フォーム送信時の情報と、受注時の情報を、同一人物として確実に結びつけられる」ことです。ここがCRM側のデータ整備と直結します。メールアドレスの表記揺れや重複レコードがあると照合が崩れます。送信の精度を上げるには、HubSpotのデータクレンジングのような土台づくりが前提になることを、最初に押さえておいてください。

Google広告での送信方法（オフラインCVインポートとリードの拡張コンバージョン）

このセクションでわかること：Google広告でオフラインコンバージョンを送る二つの方式と、それぞれの選び方を整理します。

Google広告での送信方法は、現在おおきく二系統あります。従来からある「オフラインコンバージョンのインポート」と、その上位版にあたる「リードの拡張コンバージョン」です。

オフラインコンバージョンのインポートは、前述のGCLIDを照合キーに使う方式です。フォーム送信時にGCLIDを保存し、受注や商談化が発生した時点で、GCLID・コンバージョン名・コンバージョン発生日時をまとめてアップロードします。クリック単位で厳密に紐づけられる一方、運用上の制約として、GCLIDの保持期間が90日である点に注意が必要です。フォーム送信から90日を超えてからアップロードすると、そのクリックには紐づかなくなります。BtoBの長い商談サイクルでは、この期限が現実的なボトルネックになりやすいところです。

リードの拡張コンバージョンは、このインポートをアップグレードした方式で、ハッシュ化したメールアドレスや電話番号などのユーザー提供データを照合に使えます。GCLIDと併用することも可能です。Googleは公式に、これから導入する場合はリードの拡張コンバージョンから始めることを推奨しています。また、GCLIDとファーストパーティデータ（メールアドレスや電話番号など）を併用した広告主は、標準的なオフラインコンバージョンインポートのみの場合と比べて、コンバージョン数が中央値で10%増加したとGoogleは説明しています。この数値は実装環境によって変わる参考値として捉えてください。

取り込みの具体的な手段としては、Google広告のデータマネージャー、Google Ads API、Zapierなどのツール、そしてCRMとの直接連携が利用できます。少量ならスプレッドシート経由の手動アップロードも可能ですが、継続運用には自動化が前提になります。この点は後半の運用の章で詳しく扱います。検索広告全般のつまずきはBtoBリスティング広告が失敗する理由でも整理しています。

Meta広告での送信方法（コンバージョンAPI）

このセクションでわかること：Meta広告でオフラインの成果を送る仕組みと、Google広告との違いを整理します。

Meta広告（Facebook・Instagram）でも、CRM上で発生した商談化や受注をコンバージョンとして送ることができます。かつては「オフラインイベント」という独立した仕組みがありましたが、現在はサーバー間でイベントを送る「コンバージョンAPI（CAPI）」に統合される形で扱うのが基本です。

流れとしては、CRMから成果データ（誰がいつ商談化・受注したか）を抽出し、ハッシュ化したメールアドレスや電話番号などの顧客情報を付けてサーバー経由でMetaに送信します。Metaは受け取った顧客情報を、広告に接触したユーザーと照合し、該当する広告の成果として計上します。ここでの精度は「イベント一致率」と呼ばれ、送る顧客情報の質と量に左右されます。情報が欠けていたり表記が乱れていたりすると一致率が下がり、せっかく送っても多くが紐づかない、という事態になります。

実装手段は三通りに整理できます。第一に、自社でサーバー側のコードを実装する方法。第二に、パートナー統合（外部連携ツール）を使い、CRMとMeta広告を自動でつなぐ方法。第三に、CRMが標準で備える広告連携機能を使う方法です。自社実装は柔軟ですが、APIの仕様変更に追従する保守が継続的に必要で、エンジニアの関与が前提になります。Meta広告の基本的な運用設計はBtoBのMeta広告運用でも扱っています。

どのステージを「送信」すべきか（設計の肝）

このセクションでわかること：受注・商談化・MQLのどれを最適化の目標にすべきか、判断の軸を示します。

技術的な実装よりも成果を分けるのが、「どのステージを送るか」という設計判断です。ここを間違えると、仕組みを作っても効果が出ません。基準になるのは、データ量と質のトレードオフです。

ファネルの下流（受注）ほど成果としての質は高いものの、件数は少なくなります。多くのBtoBでは、月間の受注件数が数件から数十件にとどまります。媒体の機械学習は、ある程度のコンバージョン件数がないと安定して学習できません。受注だけを送ると、データが少なすぎて最適化が回らない、という事態に陥りがちです。一方で、ファネル上流のフォーム送信は件数こそ多いものの、質のばらつきが大きく、最適化の目標にすると入り口の数だけを増やしてしまいます。

そこで現実的な落としどころになるのが、中間のステージです。具体的には、商談化（SQL）や、精度の高いMQLを主たる最適化コンバージョンに据える設計です。これなら、機械学習が回る程度の件数を確保しつつ、フォーム送信よりは事業成果に近い指標で配信を動かせます。受注は、件数が十分にある場合は併用し、足りない場合は金額の送信や効果検証用に使う、という役割分担が扱いやすいでしょう。MQLとSQLの線引きそのものが曖昧なまま送信を始めると判断がぶれるため、MQL・SQLの定義と設計方法を先に固めておくことをおすすめします。

送るステージが決まったら、商談化率の現状把握とセットで運用するとさらに精度が上がります。何を送ると商談につながりやすいかは、BtoBの商談化率を上げる考え方とあわせて検討してください。最適化指標の設計に迷う場合は、無料相談で整理のお手伝いができます。

よくある失敗パターンと回避策

このセクションでわかること：オフラインコンバージョン送信でつまずきやすい代表的な失敗を、重要度の高い順に挙げます。

実装の前に、典型的な失敗を知っておくと遠回りを避けられます。特に影響の大きいものから順に挙げます。

1. 受注だけを送り、件数不足で最適化が効かない：最も多い失敗です。月数件の受注しか送らないと機械学習が安定せず、配信は改善しません。前章のとおり、まずは商談化や精度の高いMQLを主の指標に据えるのが定石です。
2. GCLIDの90日期限切れ：GCLID方式では保持期間が90日です。アップロード頻度を上げる、または90日以内に発生した成果を確実に送る運用にしないと、紐づかないデータが積み上がります。商談が長期化しやすいBtoBでは、リードの拡張コンバージョン（ユーザー提供データ）の併用で緩和できます。
3. CRMのデータ不整合・重複で一致率が落ちる：メールアドレスの表記揺れや重複レコードがあると、送っても照合できません。送信の精度は、突き詰めればCRMのデータ品質に依存します。データクレンジングを運用に組み込んでおきましょう。

このほか、ステージ定義が曖昧で「何を送ったのか」が時期によってぶれる、同意取得やプライバシーの前提を確認しないまま顧客情報を送ってしまう、といった点も注意が必要です。後者は法令や媒体ポリシーに関わるため、取得時の同意範囲を必ず確認してください。広告予算全体の配分やKPIの組み方はBtoB広告のKPI設計もあわせて参照すると、送信指標を全体設計の中に位置づけやすくなります。

運用を継続させる仕組み（CRM／HubSpot活用と内製・外注）

このセクションでわかること：手動運用で頓挫しないために、送信を自動化する考え方と内製・外注の判断軸を示します。

オフラインコンバージョン送信が頓挫する理由の多くは、技術ではなく運用です。最初はスプレッドシートで手動アップロードしていても、担当者の負荷や属人化で次第に止まり、いつのまにか送られていない、というのはよくある経過です。継続のカギは、CRMのステージ変更をトリガーに送信を自動化することにあります。

たとえばHubSpotには「広告の最適化イベント（Ads Optimization Events）」という機能があり、CRMのライフサイクルステージの変更を、Google広告・Meta広告・LinkedIn広告にコンバージョンとして同期できます。ステージが「マーケティング有効リード」や「顧客」に変わったタイミングで、自動的に媒体へ成果が送られる、という流れです。GCLIDを自前で保存・管理する手間を肩代わりしてくれるため、実装と運用のハードルが大きく下がります。なお、Meta広告については、リード獲得広告に接触したコンタクトのライフサイクルデータのみが同期対象になるなど、媒体ごとに条件がある点は確認が必要です。HubSpotと広告媒体の連携全体像はHubSpotとGoogle広告の連携、広告経由リードの自動処理は広告リードの自動化で詳しく扱っています。

内製か外注かの判断軸は、自動化の方式で決まります。CRMの標準連携機能で完結するなら内製でも回せます。一方、自社サーバーでのAPI実装や、複数媒体をまたぐ複雑な連携が必要な場合は、保守を含めて外注を検討する価値があります。判断のポイントは「一度作って終わり」ではなく「仕様変更に追従し続けられるか」です。広告運用そのものの内製・外注の整理は広告運用の内製と外注も参考になります。

まとめ

オフラインコンバージョン送信は、媒体が見えていない「フォーム送信から受注まで」の区間を埋め、広告の最適化を事業成果に向け直すための仕組みです。要点は次の三つに集約されます。第一に、媒体はフォーム送信しか見えていないため、放置すると「埋まるが商談にならないリード」に最適化が寄ること。第二に、何を送るかの設計が成否を分け、受注単独ではなく商談化や精度の高いMQLを主の指標に据えるのが現実的であること。第三に、手動運用は続かないため、CRMのステージ変更を起点にした自動化が前提になることです。

Google広告ならリードの拡張コンバージョン、Meta広告ならコンバージョンAPIが中心の手段になりますが、いずれも土台はCRMのデータ品質と、ステージ定義の明確さです。技術的な実装に入る前に、自社のファネルとMQL・SQLの定義を整えることが、遠回りに見えて最短の道筋になります。

よくある質問（FAQ）

オフラインコンバージョン送信とアトリビューション分析は何が違うのですか。

アトリビューションは、成果に至った経路ごとの貢献度を「可視化・分析」する考え方です。オフラインコンバージョン送信は、その成果データを媒体に返し、配信アルゴリズムの「最適化そのものを動かす」点が異なります。分析にとどめるか、媒体の入札に反映するかの違いと捉えてください。

受注と商談化、どちらを送るべきですか。

件数次第です。受注は質が高い一方で件数が少なく、機械学習が安定しないことが多いです。多くのBtoBでは、まず商談化（SQL）や精度の高いMQLを主の最適化指標に据え、受注は件数が十分なら併用、足りなければ金額や効果検証用に使う設計が現実的です。

GCLID方式とリードの拡張コンバージョンは、どちらを選べばよいですか。

これから始めるなら、Googleはリードの拡張コンバージョンを推奨しています。GCLIDの保存・管理が不要で、ハッシュ化したメールアドレスなどで照合できるためです。GCLIDの90日保持期限に縛られにくい点も、商談が長期化しやすいBtoBには利点になります。

受注件数が少ない小規模事業でも導入する意味はありますか。

あります。ただし「受注だけを送る」と件数不足で最適化が効きにくいため、商談化やMQLなど件数を確保できるステージを送るのが前提です。可視化・効果検証の目的だけでも、何が成果につながったかの理解は深まります。

HubSpotがあれば実装は簡単になりますか。

手間は大きく下がります。HubSpotの広告最適化イベントを使えば、CRMのライフサイクルステージ変更を媒体にコンバージョンとして自動同期でき、GCLIDの自前管理が不要になります。ただし媒体ごとに同期条件があるため、設定時の確認は必要です。