BtoBフォームのプログレッシブプロファイリング｜質問項目を段階的に増やす設計
資料請求や問い合わせのフォームを短くすると送信しやすくなる一方、会社規模、役職、導入時期、利用中のツールなど、営業やナーチャリングに必要な情報が足りなくなります。反対に、初回から全項目を必須にすると、まだ情報収集段階の読者へ大きな負担をかけます。
この両立に使えるのがプログレッシブプロファイリングです。初回は申込完了に必要な最小項目を受け取り、再訪や次のコンバージョン時には、CRMでまだ分かっていない項目だけを少しずつ尋ねます。重要なのはフォーム機能を有効にすることではなく、質問順、既知リードの判定、既存値の扱い、次の業務への利用方法まで決めることです。
本記事のポイント
- 初回フォームには識別と申込完了に必要な項目を残し、役職・課題・導入時期などは次の接点で段階取得します。
- 質問順は集めたい情報ではなく、次の配信・優先順位付け・営業引き渡しに使う順で決めます。
- CRMでは空欄、未回答、古い値、確認済み値を分け、フォーム回答で高信頼の既存値を自動上書きしないようにします。
この記事の直接回答
プログレッシブプロファイリングは、既知のリードへ同じ質問を繰り返さず、次の判断に必要な不足項目だけを表示するフォーム設計です。初回はメールアドレス、申込内容、必要な同意などに絞り、再訪時は部署・役職、課題、導入時期、利用環境などを段階的に取得します。プログレッシブプロファイリングは「フォームを毎回長くすること」ではなく、「既に分かっていることを聞かず、次に必要な情報だけを一つずつ集める運用」です。
プログレッシブプロファイリングは再訪ごとに質問を変える仕組み
プログレッシブプロファイリングでは、フォームを開いた人が既知のコンタクトかを判定し、CRMやMAに値がある項目を非表示または別の質問へ置き換えます。氏名とメールアドレスを取得済みなら、次は部署と役職、その次は課題と導入時期というように、接点を重ねながらプロフィールを補います。
似た機能に、入力済みの値を表示するプリフィル、同じフォームを複数画面に分けるマルチステップフォーム、回答内容で設問を分岐する条件分岐があります。これらは併用できますが、役割は異なります。フォーム製品を選ぶ際は、BtoBフォーム作成ツールの機能要件に、既知リードの識別方法、空欄判定、質問キュー、上書き制御、テスト機能を追加して確認します。
| 仕組み | 何を変えるか | 適した場面 | 注意点 |
|---|---|---|---|
| プログレッシブプロファイリング | 過去に取得した値に応じて次の質問を変える | 資料請求、ウェビナー、相談など複数接点がある | 既知リード判定とCRMの値品質が必要 |
| プリフィル | 既存値を入力済みとして表示する | 同じ情報の再入力を減らしたい | 共有端末や誤った本人判定では情報露出につながる |
| マルチステップ | 一回の入力を複数画面へ分ける | 一度に必要な項目が多い申込 | 総項目数は減らず、途中離脱の計測が必要 |
| 条件分岐 | 現在の回答によって追加質問を出す | 製品、地域、用途で必要項目が変わる | 分岐が増えるほどテスト組み合わせも増える |
製品ごとに実装の意味も違います。Salesforce Account Engagementは、過去のフォームで特定項目に値が入っている場合に条件付き項目を表示します。Adobe Marketo Engageは、プログレッシブ対象の項目群と、一度に表示する空欄数を設定します。HubSpotの公式ヘルプは、2026年1月2日時点でプログレッシブフィールドを旧フォームエディター向け機能とし、更新されたフォームエディターでは未対応と案内しています。製品名だけで可否を決めず、利用中のフォーム世代と設定条件まで確認する必要があります。
初回フォームと再訪フォームの質問順を決める
質問順は「会社として知りたい順」ではなく、「その回答が得られたら次に何を変えるか」で決めます。回答を配信内容、営業の優先順位、担当割り当て、提案準備のどれにも使わないなら、段階質問へ入れてもデータが増えるだけです。
初回フォームには、申込を成立させる識別項目と、その場の手続きに必要な項目を残します。BtoBでは業務用メールアドレス、氏名、会社名、申込対象、必要な同意が候補です。ただし会社名をドメインや既存CRMから安全に補える場合、初回の必須項目から外せることもあります。コンバージョンファネルの離脱箇所と照らし、項目を減らした結果だけでなく、その後の商談化まで確認します。
| 取得段階 | 質問候補 | 回答後に変える業務 | 入れすぎの兆候 |
|---|---|---|---|
| 初回接点 | メールアドレス、氏名、会社、申込内容、必要な同意 | 本人識別、資料送付、受付、重複確認 | 申込完了に不要な質問が必須になっている |
| 2回目 | 部署、役職、会社規模、関心テーマ | セグメント、担当割り当て、配信内容 | 一つの回答で何も分岐しない |
| 3回目 | 課題、利用中の仕組み、導入時期 | ナーチャリング、優先順位、提案準備 | 自由記述が多く比較や自動処理に使えない |
| 営業接続前 | 対象部門、意思決定への関与、希望条件 | 商談準備、関係者確認、次回アクション | まだ相談意思のない人へ購買質問を急ぐ |
一度の再訪で出す新規質問は、回答負担と利用価値のバランスで決めます。固定の正解はありませんが、まず2〜3項目で始め、フォーム完了率とCRMの不足解消率を見ながら調整すると原因を追いやすくなります。ツール選定ではBtoBフォーム作成ツールの比較だけでなく、自社が使うフォーム世代で段階質問を実現できるかを実画面で試します。
役職や会社規模のような属性だけを集め続けても、次に送る情報が変わらなければ価値は限られます。属性、行動、検討段階を組み合わせる方法はBtoBメールのセグメント設計で整理し、段階取得した値を実際の配信ルールへ接続します。
CRMの空欄判定と上書きルールを先に設計する
プログレッシブプロファイリングが壊れる主因は、空欄の意味が一つではないことです。まだ聞いていない、本当に該当しない、回答を控えた、古くなった、連携に失敗したという状態をすべて空欄にすると、同じ質問を繰り返したり、聞くべき項目を飛ばしたりします。
項目ごとに、値、取得元、取得日時、確認日時、信頼度、上書き可否を持つと判断しやすくなります。特にCRMの営業担当が確認した値を、古いフォームや誤認した訪問者の回答で自動上書きしないよう、情報源の優先順位を決めます。
| CRMの状態 | フォーム表示 | 保存ルール | 運用上の確認 |
|---|---|---|---|
| 未取得 | 質問キューの順番に従って表示 | 入力形式を検証して新規保存 | 次の業務で本当に使う項目か |
| 現在も有効な既知値 | 原則として再質問せず次項目へ進む | 既存値を維持 | 有効期限や確認周期が定義されているか |
| 古い可能性がある値 | 新規質問ではなく確認・更新として提示 | 回答日時と旧値を残して更新 | 役職、会社規模、利用ツールなど変化頻度 |
| 高信頼の値と回答が競合 | その場で自動確定しない | 競合キューへ送り担当者が確認 | 営業確認値、基幹連携値、本人回答の優先順位 |
| 回答保留・非該当 | 一定期間は再質問しない | 空欄と区別する状態を保存 | 再質問までの間隔と解除条件 |
| 同意・配信設定 | 用途に応じて明示的に確認 | 他の属性から推定しない | 対象、文面、取得日時、変更履歴 |
本人識別も一つの信号に依存させません。Cookieがある、同じメールアドレスを入力した、ログイン済み、CRM ID付きリンクから来た、といった条件は確度が異なります。共有端末や転送されたメールでは別人を既知リードと誤認する可能性があります。個人情報や営業上センシティブな値をプリフィル表示する場合は、表示前の本人確認を強くし、判定できないときは短い初回フォームへ戻します。
フォーム送信後は、受付、重複確認、CRM登録、担当通知を同じIDで追跡します。フォーム送信後の初動自動化へ段階取得の状態を渡すと、情報が十分なリードだけ営業へ送り、不足している人には次のコンテンツを案内する分岐を作れます。
6ステップで段階取得を実装し、営業引き渡しまで検証する
プログレッシブプロファイリングは、フォームだけを設定しても完成しません。CRM項目、質問の利用先、既知リード判定、例外処理、営業への引き渡しを同じテストに含めます。
- 取得目的を決める。各項目について、配信分岐、担当割り当て、優先順位、提案準備のどこで使うかを一文で書きます。利用先がない項目はキューへ入れません。
- CRM項目を棚卸しする。項目名、型、選択肢、必須性、取得元、空欄の意味、更新責任者、確認周期を整理します。似た項目が複数ある場合は統合してからフォームへ接続します。
- 初回項目と質問キューを分ける。識別と申込完了に必要な項目は常時表示し、属性、課題、導入時期、利用環境は業務で使う順に並べます。一度に表示する新規項目数も決めます。
- 表示・保存・上書き条件を定義する。未取得なら表示、確認済みならスキップ、古ければ更新確認、競合すれば担当者確認という分岐を項目ごとに決めます。同意や配信停止は一般属性と別ルールにします。
- 利用者状態ごとにテストする。新規訪問、既知で一部空欄、既知で全項目あり、Cookieなし、共有端末、メールアドレス変更、入力エラー、CRM連携失敗を試し、表示と保存結果を照合します。
- 下流指標で改善する。フォーム完了率だけでなく、本人識別率、項目別回答率、CRM不足率、重複作成率、競合件数、営業受入率、商談化まで追います。質問を増やして完了率が保たれても、営業判断に使われなければ外します。
| テスト対象 | 期待する表示 | 期待する保存結果 | 失敗時のフォールバック |
|---|---|---|---|
| 新規訪問者 | 短い初回フォーム | 新規コンタクトと取得元を記録 | CRM停止時は受付ID付きで再送キューへ置く |
| 既知・一部空欄 | 不足項目を優先順に表示 | 既存IDへ追加し取得日時を更新 | 本人判定が弱ければ初回フォームへ戻す |
| 既知・値が古い | 現在値の確認または更新質問 | 旧値と更新履歴を残す | 自動上書きせず確認キューへ送る |
| 共有端末・別人 | 既知情報を露出しない | 別コンタクトとして重複確認 | メール確認後に統合判断する |
| 入力・連携エラー | 項目と原因が分かるエラー | 不完全な値を確定しない | 再入力案内と運用担当への通知を行う |
最初から全フォームへ展開せず、再訪が多く、次の質問を業務で使いやすい一つの資料請求やウェビナーから始めます。フォーム別に質問順を変えすぎると、同じCRM項目へ異なる定義の回答が入ります。共通の項目辞書と上書きルールを保ち、キャンペーン固有の質問だけを追加します。
導入しない方がよい条件とアクセシビリティの注意点
再訪接点がほとんどない、既知リードを安定して判定できない、CRMの項目定義が重複している、取得後の利用先がない場合は、プログレッシブプロファイリングより先に基盤を整えます。本人確認や契約に必須の情報を「次回に聞けばよい」と後回しにする用途にも向きません。
製品機能の制約も導入判断に含めます。HubSpotのようにフォーム世代で対応状況が異なる場合、旧エディターを機能のためだけに延命すると、保守や移行の負担が残ります。自社で条件分岐を組む場合も、Cookieが拒否されたとき、JavaScriptが動かないとき、CRM照合が遅いときの短い標準フォームを用意します。
動的に質問が変わっても、各入力欄には目的が分かるラベルを付け、必須項目、入力形式、エラー内容を明示します。プレースホルダーだけをラベル代わりにせず、キーボード操作、読み上げ、エラー後のフォーカス移動を確認します。W3C WAIは、必要な情報だけを尋ねることに加え、ラベル、入力支援、検証、完了・エラー通知を一体で設計するよう案内しています。
製品ごとの条件とフォーム実装の基準は、次の公式情報で確認できます。
- HubSpot Knowledge Base: Use progressive fields in forms (legacy)：旧フォームの質問キュー、既知値の置換、メール項目と重複防止、更新エディターでの非対応を確認できます。
- Salesforce Help: Gather Prospect Data Over Time：Account Engagementで過去の取得値を条件に項目を表示する設定を確認できます。
- Adobe Experience League: Configure Form Progressive Profiling：Marketo Engageの対象項目群、表示する空欄数、必須項目の注意点を確認できます。
- W3C WAI: Labeling Controls：入力欄とラベルの関連付け、見えるラベル、モバイルでの配置を確認できます。
- W3C WAI: Form Instructions：必須項目、入力形式、全体説明と項目別説明の示し方を確認できます。
よくある質問
プログレッシブプロファイリングとは何ですか？
既知のリードが過去に回答した項目を再表示せず、CRMやMAで不足している次の質問へ置き換える仕組みです。複数の資料請求、ウェビナー、問い合わせなどを通じて、初回の負担を抑えながらプロフィールを補います。
初回フォームにはどの項目を残しますか？
本人を識別し、申込内容を届け、必要な受付処理を行うための最小項目を残します。業務用メールアドレス、氏名、申込対象、必要な同意が基本候補です。会社名などを安全に補完できない場合は初回に含めます。
再訪時にどの質問を追加しますか？
次の配信、担当割り当て、優先順位、提案準備に使う項目から追加します。部署・役職、会社規模、課題、導入時期、利用中の仕組みなどを、1回に2〜3項目から試し、回答後に変わる業務がない質問は外します。
CRMの既存値とフォーム回答の競合をどう管理しますか？
項目ごとに取得元、取得日、確認日、信頼度、上書き可否を持ちます。営業担当が確認した値や基幹システムの値と競合する場合は自動上書きせず、旧値と新回答を確認キューへ送ります。
HubSpotの新しいフォームでもプログレッシブフィールドを使えますか？
HubSpotの公式ヘルプは2026年1月2日時点で、プログレッシブフィールドを旧フォームエディター向けとし、更新されたフォームエディターでは対応していないと案内しています。利用中のフォーム世代を確認し、移行予定と合わせて判断します。
Cookieが使えない場合も段階質問はできますか？
Cookieだけに依存せず、ログイン、確認済みメールアドレス、CRM ID付きの安全な導線などを組み合わせれば判定できます。本人性を十分に確認できない場合は既存情報を表示せず、短い初回フォームへ戻す方が安全です。
まとめ
BtoBフォームのプログレッシブプロファイリングは、初回フォームを短くするだけの機能ではありません。初回に必要な識別項目を決め、再訪時の質問を業務で使う順に並べ、CRMの空欄、古い値、確認済み値、回答保留を区別する運用です。
導入時は、一つのフォームで質問キューと上書きルールを作り、新規、既知、Cookieなし、共有端末、値の競合、連携失敗をテストします。完了率だけでなく、CRMの不足率、重複、営業受入率まで確認すると、入力負担を増やさずに商談へ必要な情報を揃えられます。
