従業員3,000人の同じ企業のセキュリティ責任者、プロダクトマネージャー、調達アナリストが、同じ週にあなたのウェブサイトを開きます。3人は同じ購買委員会に属し、同じ製品を評価しているのに、同じホームページ、同じ導入事例、同じデモフォームを目にします。セキュリティ責任者はSOC 2レポートを、プロダクトマネージャーはチームが実際にそれを使うかどうかを、調達は価格を知りたいのです。役職別にウェブサイトをパーソナライズするとは、それぞれに自分の疑問に真っ先に答えるページを見せることです。
しかも、言うほど簡単ではなく、ほとんどのガイドは難しい部分を飛ばしています。業界と企業規模は、最初のページビューでの IP 照合からほぼ自動的に得られます。役職はそうはいきません。役職は個人に属するものであり、ほとんどの B2B サイトでは個人は匿名だからです。このガイドは、役職ベースのパーソナライゼーションを誠実に行うためのものです。使うべき役職の区分、雑多な肩書きをそこに振り分ける方法、役職データが実際にどこから得られるか（そしてどこからは得られないか）、各ページで何を変えるか、そしてそれが効果を上げたかを見極める方法を解説します。
役職が重要な理由と、それが見落とされる理由
B2Bの購買はグループでの意思決定です。Forresterの2024年のバイヤージャーニー調査では、購買の意思決定には平均13人が関与していることがわかりました。その一人ひとりが、異なる疑問を持ってサイトを読みます。アカウント単位のパーソナライゼーションでは、ドイツの物流企業の誰かが訪問していることは認識できますが、その企業の全員を同じ読者として扱います。CFOとエンジニアを区別するのが、役割という層です。
チームがこれを省くのには現実的な理由があります。データが乏しいのです。リバースIPルックアップで特定できるのは企業であり、個人ではありません。相手の役職がわかるのは、すでにCRMに登録されている場合、その役職向けのキャンペーン経由で来た場合、または行動から推測できる場合だけです。そのため、役職別のパーソナライゼーションが届くのは常にセッションの一部にすぎず、すべての訪問者にタグを付けられるふりをするのではなく、その事実を前提にプログラムを設計する必要があります。
私たちの立場:役職は、業種や規模によるパーソナライゼーションがすでに動いてから追加する価値があり、最も効果があるのは3つのページ(ホームページ、料金ページ、デモフォーム)です。役職から始めるべきではなく、20ものペルソナを作るべきでもありません。
最初にセグメント化すべき4つの役割
購買委員会の役割分担は4つのグループでカバーできます。それ以上に分けると、各セグメントのトラフィックが少なすぎて測定できません。
| 役割 | 典型的な役職 | 知りたいこと | 読み取れること | 適切なCTA |
|---|---|---|---|---|
| 決裁者 | CEO、CFO、予算を持つVP | 費用、得られる効果、契約の内容 | 料金、ROI のコンテンツ、成果を示した導入事例 | 料金・ROIのワークシート、シニア営業担当者との打ち合わせ |
| 技術評価者 | CTO、セキュリティ責任者、アーキテクト、エンジニアリングマネージャー | アーキテクチャ、連携、セキュリティ、データの取り扱い | ドキュメント、APIリファレンス、セキュリティとトラストのページ | アーキテクチャの概要、売り込みのない技術説明 |
| 実務担当者 | アナリスト、オペレーションマネージャー、スペシャリスト | 自分の1週間が楽になるか、習得にどれくらいかかるか | 機能ページ、チュートリアル、スクリーンショット、ヘルプセンター | プロダクトツアー、サンドボックス、録画デモ |
| チャンピオン | ディレクター、シニアマネージャー、チームリーダー、プロダクトマネージャー | 社内で通せるか、チームに何がもたらされるか | 比較ページ、同業他社の導入事例、ROI資料 | 社内説明用の資料一式、リファレンスコール |
多くのサイトが十分に対応できていないのがチャンピオンです。チャンピオンは契約書に署名する人ではありませんが、署名を取り付けるための社内メールを書く人です。転送できるもの（1ページの概要、比較資料、セキュリティFAQ）を渡すことは、施策全体の中で最も低コストな成果になることが少なくありません。
役職とカテゴリーの対応表
難しいのはルールを書くことではありません。CRM、フォーム送信、データプロバイダー（ZoomInfo、Apollo、6senseなど）から実際に受け取る自由記述の役職名を、上記の4つのカテゴリーに対応付けることです。以下の表を出発点となる分類として使い、自社の市場に合わせて調整してください。
| カテゴリー | Cレベル & VP | ディレクター＆部門責任者 | マネージャー&リーダー | 個人の担当者 |
|---|---|---|---|---|
| 決裁者 | CEO、CFO、COO、CRO、最高収益責任者、社長、財務担当VP、オペレーション担当VP、購買担当VP | Director of Finance、Director of Procurement、Director of Operations、Head of Finance、Head of Procurement | 財務マネージャー、調達マネージャー、購買担当者、カテゴリーマネージャー | Procurement Specialist、Finance Analyst（購買権限あり） |
| 技術評価者 | CTO、CIO、CISO、Chief Architect、Chief Data Officer、VP Engineering、VP Technology、VP Security、VP IT、VP Data、VP Platform | エンジニアリングディレクター、プラットフォームディレクター、インフラストラクチャディレクター、セキュリティディレクター、エンジニアリング責任者、プラットフォーム責任者、セキュリティ責任者 | エンジニアリングマネージャー、テックリード、アーキテクト、ソリューションアーキテクト、セキュリティエンジニアリングマネージャー | シニアエンジニア、スタッフエンジニア、プリンシパルエンジニア、セキュリティエンジニア、DevOpsエンジニア、SRE |
| 実務担当者 / エンドユーザー | （このレベルではまれ） | （このレベルではまれ） | Marketing Manager、Operations Manager、Sales Operations Manager、RevOps Manager | アナリスト（マーケティング、営業、ビジネス、データ）、スペシャリスト、コーディネーター、アソシエイト、リサーチャー、ジュニア／中堅エンジニア |
| チャンピオン／インフルエンサー | マーケティング担当VP、プロダクト担当VP、カスタマーサクセス担当VP（経済的な決裁者でない場合） | マーケティングディレクター、プロダクトディレクター、デマンドジェネレーションディレクター、グロースディレクター、マーケティング責任者、プロダクト責任者、グロース責任者 | シニアマネージャー、プロダクトマネージャー、シニアプロダクトマネージャー、プログラムマネージャー、チームリーダー | （ここから始まることはまれ） |
この表には注意点が1つあります。同じ肩書きでも、製品によって意味が異なります。マーケティングソフトウェアを販売しているなら、VP Marketingはチャンピオンではなく決裁者です。表を使う前に、自社製品が対象とする部門に合わせて行を並べ替えてください。
あいまいな役職の扱い方
きれいに当てはまらない役職も多くあります。よくあるケースは、次のデフォルトでカバーできます。
- 職務が明確でない「Director of X」：デフォルトでチャンピオンとして扱います。一般的な肩書きのディレクターは、署名する側よりも社内で提案する側であることが多いからです。
- 従業員50人未満の企業の「Head of X」や「VP」：決裁者として扱います。この規模では、通常その部門のリーダーが予算を握っています。
- シニアエンジニアやスタッフエンジニア、アナリスト：実務担当者として扱います。ただし従業員約30人未満の企業では、権限がフラットなため技術評価者として扱います。
- プロダクトマネージャー：チャンピオン。予算を持つことはまれですが、ベンダー評価を主導することがよくあります。
- コンサルタントと業務委託者：役職に含まれる職能で対応付けます（「マーケティングコンサルタント」は実務担当者）。影響力はありますが、購入することはまれです。
- 小規模企業のオーナーや創業者：決裁者。
- 空欄または汎用的な役職名（「社員」「技術スタッフ」「エンジニア」）：未分類の区分に入れ、それらのセッションでは行動に頼ります。
対応付けは、すべてのページルールの中で繰り返すロジックとしてではなく、パーソナライゼーションツールや CDP の1つのルックアップテーブルとして管理しましょう。そうすればマーケティングは1か所でカテゴリーを変更でき、データベンダーを切り替えても分類体系を書き直す必要はありません。
役職データの実際の入手元
「役職を選んでください」というポップアップは避けましょう。ほとんどの訪問者は閉じてしまい、好奇心から別の役職をクリックする人もいて、全員に摩擦を加えることになります。代わりに、次のデータソースを使いましょう。おおむね信頼できる順に並べています。
| ソース | 仕組み | 信頼性 | 注意点 |
|---|---|---|---|
| 既知のコンタクトのCRMレコード | フォーム入力やメールのクリック後に、Cookieで照合されたリピーター | 高い：役職が記録済み | 役職は古くなるため、少なくとも年に1回はデータプロバイダーから更新する |
| キャンペーンのターゲティング | UTM から、訪問者が特定の役職向けの広告やメール（例：職務でターゲティングした LinkedIn キャンペーン）から来たことがわかる | 中〜高 | ターゲティングは漏れ、同僚同士でリンクが転送される |
| サイト上の行動 | セッション内で読まれたページから、訪問者が抱えている疑問がわかります | 中。ページが増えるほど向上 | 何かを判断するには2回以上のページビューが必要 |
| 個人レベルの識別ベンダー | 第三者が匿名の訪問者を個人と照合できると主張している | 大きく異なる。主に米国をカバー | GDPRではこれは個人データの処理に当たり、法的根拠が必要です。EUのトラフィックで有効にする前に確認してください |
企業レベルの訪問者特定は、これらと組み合わせて使えます。個人の役職まではわかりませんが、企業はわかるため、役職を業種や規模と組み合わせられます。既知の連絡先の役職をWebサイトに戻す方法は、WebサイトパーソナライゼーションのデータをCRMと連携する記事で解説しています。
役職を推定するための行動ルール
匿名の訪問者については、行動が主なシグナルです。最初のうちは、説明も検証もできるシンプルなルールの方が複雑なモデルより効果的です:
- 1セッション内で料金または ROI のコンテンツを2回以上閲覧：決裁者。
- ドキュメント、APIリファレンス、セキュリティのページを2回以上閲覧：技術評価者。
- 機能ページ、チュートリアル、プロダクトツアーを2回以上閲覧：実務担当者。
- 導入事例と、比較ページまたは代替ツールのページ：チャンピオン向け。
- それ以外：役割なし。デフォルトを表示します。
データソース同士が食い違う場合は、平均を取るのではなく優先順位を使います。CRMの役職はキャンペーンのコンテキストより優先され、キャンペーンのコンテキストは行動より優先されます。行動がCRMの役職より優先されるのは、それが強く最近のものである場合だけです（今週APIのページを4つ読んだ既知の「マーケティングマネージャー」は、今回の購買では技術評価者として動いています）。スコアリングの側面については、B2Bウェブサイトの行動セグメンテーションの記事で詳しく解説しています。
公開前に、ルールを実態と照らし合わせましょう。前四半期にデモフォームに入力したコンタクトを取り出し、コンバージョン前に閲覧したページを調べ、ルールが割り当てたであろう役職を実際の役職と比較します。多くの人で役職を間違えるなら、誰かがパーソナライズされたページを目にする前にルールを修正しましょう。
役職別に各ページで変えるべきこと
役職別のパーソナライゼーションとは、すべてのページを4回書くことではありません。各ページで2〜4つの要素を変え、残りはそのままにします。
ホームページ
ヒーローの見出し、メインの証拠、主要な CTA を変えます。コピーの例（架空のアナリティクス製品を想定した説明用）：
| 役割 | ヒーローの見出し | 表示する実績 | メインCTA |
|---|---|---|---|
| デフォルト | 購入の準備ができているアカウントを把握 | ロゴバー | デモを予約 |
| 決裁者 | ウェブサイトがすでに生み出しているパイプラインを把握 | 財務または収益部門の責任者による、成果についてのコメント | 料金とROIワークシートを見る |
| 技術評価者 | スクリプトタグ1つだけ。既存のツール構成への変更は不要 | セキュリティ認証、連携先のロゴ | アーキテクチャの概要を読む |
| 実務担当者 | 最初のセグメントを半日で作る | 日々のワークフローのスクリーンショット | 製品ツアーを見る |
| チャンピオン | 今四半期にチームがリリースできること | 類似チームの導入事例 | 社内提案用の資料セットを入手する |
ホームページの残りの部分はホームページのパーソナライゼーション・プレイブックで解説しています。新しい要素を増やすのではなく、すでにパーソナライズしている要素に役職の軸を加えましょう。
料金ページ
ここで役割ごとの違いが最も大きくなります。経済的な決裁者は契約期間全体の総コストとその正当化の材料を求めるため、年間ベースの表示とROIワークシートを前面に出しましょう。技術評価者は、各プランに何が含まれるか（APIの上限、SSO、データの保管場所、サポートレベル）を知りたがります。実務担当者は、各プランで実際に何ができるかを知りたがります。チャンピオンは財務部門に持っていける資料、つまりビジネスケースと2社の参考顧客をまとめた1ページの概要を求めています。
価格そのものはすべての役職で同じにします。見せ方を変えるのは問題ありませんが、同じ会社の人に異なる数字を見せると、彼らが情報を突き合わせた途端に信頼を失います。このページについて詳しくは、B2Bの料金ページのパーソナライゼーションの記事をご覧ください。
製品・機能ページ
製品ページは最も書き直しが少なくて済みます。変えるのはファーストビューの内容です。技術評価者にはアーキテクチャ図と連携一覧、実務担当者にはワークフローのスクリーンショットとチュートリアル、決裁者とチャンピオンには類似企業の成果を軸にした導入事例を見せます。最初の段階では機能一覧そのものは固定のままにしておきます。
デモフォーム
ずれが最も大きな損失を生むのはフォームです。予算決裁者は、誰が通話に参加し、どのくらい時間がかかるかを知りたがります。技術評価者は、営業の電話ではなく技術的なセッションやドキュメントを求めることがよくあります。実務担当者は、会議なしで製品を見たいと考えています。標準のデモ申し込みの横に役割に応じた選択肢（たとえば評価者向けの「技術説明会」）を用意すれば、本来なら離脱してしまう人を引き留められます。
具体例:1つのアカウント、3人の訪問者
説明用の例です。従業員600人の物流ソフトウェア企業がレポーティングツールを検討しています。2週間のうちに、その企業から3人が訪問します。
- 訪問者Aは、財務職をターゲットにしたLinkedInキャンペーンから流入し、料金ページを2回閲覧しました。役割：経済的購買者（キャンペーンと行動が一致）。料金ページでは、年間コストのビューとROIワークシートを最初に表示します。
- 訪問者Bは匿名で、APIリファレンス、セキュリティページ、連携一覧を閲覧しています。役割：技術評価担当者（行動から推定）。次回訪問時、ホームページのヒーローは「既存スタックの変更不要」のバリアントに切り替わり、デモフォームでは技術説明会が提案されます。
- 訪問者Cは既知のコンタクト（1年前にウェビナーのフォームに入力）で、役職は「シニアプロダクトマネージャー」です。役割：推進者（CRMの役職より）。同業者の導入事例と、社内説得用資料パックのCTAが表示されます。
一方、企業単位の識別では、同じアカウントから2週間で3人が訪れていることがわかります。これは役職に関係なく営業に伝えるべき購買グループのシグナルです。役職は各個人が見るものを変え、アカウント単位の視点は営業がいつ関与するかを決めます。後者についてはアカウントスコアリングの記事で解説しています。
60日間の導入プラン
- 1〜10日目：役割の推定。役職のマッピング表を読み込み、CRMの役職を連携し、行動ルールを作成して、前四半期のデモ申し込みに対してバックテストします。
- 11〜25日目：ホームページ。役職ごとにヒーロー、実績、CTAのバリアントを1つずつ用意し、標準ページを見続けるホールドアウト群を設けます。A/Bテスト計画を使い、開始前に成功指標を確定させましょう。
- 26〜40日目:料金ページ。変えるのは打ち出し方とメインCTAだけにします。料金のコピーは商業的な影響を伴うため、最初の改善は小さく抑えましょう。
- 41〜55日目：製品ページ。ファーストビューで強調する内容と、機能一覧の下に置く導入事例。
- 56〜60日目：レビュー。各役職セグメントをそのホールドアウトと比較します。信頼できるサンプルで勝ったバリエーションは残し、残りは廃止して、次に新しいコンテンツを用意する役職を決めます。
トラフィックが少ないなら、計画を縮小しましょう。1つの役職、1つのページ、1か月です。ホームページでの技術評価者向けのテストは、行動シグナルが明確で、コンテンツもたいていドキュメントにすでにあるため、最初のテストに適しています。
役割別パーソナライゼーションを失敗させるミス
役割が多すぎる。ペルソナの資料には10以上の役割が並んでいることがよくあります。役割が1つ増えるごとにトラフィックがさらに分割され、最終的には何も測定できなくなります。最初の四半期は4つで十分です。
デフォルトの体験がない。ほとんどのセッションには役職のタグが付きません。デフォルトのページ自体が単独で優れている必要があり、役職別のバリエーションはそれに上乗せするものであって、置き換えるものではありません。
コピーを変えて CTA を変えない。財務向けの見出しの後に「今すぐ構築を始める」が続くと、努力が台無しになります。CTA は、その役職の人が次に取る行動に合わせる必要があります。
毎回の訪問を初回として扱う。4回目の訪問のCFOは、すでに御社の売り込みを見ています。役割だけでなく訪問回数でも調整しましょう。たとえば、ROIワークシートから直接の商談の提案へと移ります。
企業の文脈を欠いた役職。50人のスタートアップのCFOと5,000人の大企業のCFOでは、関心事が異なります。役職は少なくとも1つのファーモグラフィックの観点と組み合わせましょう。企業規模別のパーソナライゼーションのガイドは、自然な基盤レイヤーになります。
プライバシーを軽視する。訪問者に「ようこそ、財務部のJaneさん」と表示するのは気味が悪く、EUではデータの入手方法によっては違法になる可能性もあります。役職によるパーソナライズは控えめに行いましょう。強調する内容を変えるだけにとどめ、知っていることを決して口に出さないことです。
測定方法
セグメント単位で測定しましょう。サイト全体のコンバージョンは、役職別のバリアントとは無関係な多くの理由で変動します。毎週次の指標を追跡します。
- 役職セグメントごとのコンバージョン率を、それぞれのホールドアウトと比較します。改善が見られない役職には新しいバリアントが必要です。
- 役割のカバー率：役割タグが付与されたセッションの割合。カバー率が低いと効果が限られ、急に跳ね上がった場合はたいていルールが緩くなりすぎています。
- タグの精度。推定した役割と、後にコンバージョンした人の役職を比較して毎月確認します。
- 後工程の質：パーソナライズしたセッションからのリードが、ホールドアウトからのリードよりも高い割合で有望な商談になっているか。
Markettailorのセグメンテーション機能では、CRMの項目、キャンペーンパラメータ、ページ上の行動から役職のセグメントを定義し、セグメントごとのコンバージョンをホールドアウトと比較して報告できます。どのツールを使うにしても、ツールそのものより測定の設計の方が重要です。
1つの役割と1つのページから始める
技術評価者を1人選び、その人向けのホームページのヒーローを1つ作成して、1か月間デフォルトと比較します。勝てば、料金ページや2つ目の役割を追加します。勝てなければ、見出し1つ分のコストで、そのオーディエンスが求めていない問いが何かを学べたことになります。
役割別セグメントと企業レベルの識別を自社のトラフィックでどう組み合わせられるかを確認するには、料金ページからウォークスルーを予約してください。