Webサイトパーソナライゼーションツールは、どの企業がサイトを訪れ、何を読み、どのセグメントに属するかを知っています。CRMは商談ステージ、連絡先、売上履歴を知っています。両者が一切データを交換しなければ、営業担当者はそのアカウントが直前に何を見たかを知らずに電話をかけ、パーソナライゼーションのルールは進行中の商談と冷えた見込み客を区別できません。
その差は最初の電話で表れます。「当社のWebサイトをご覧になりましたね」は無視されます。「今週、御社のチームがセグメンテーションのドキュメントと料金ページを何度もご覧になっていました」なら、営業担当者に話題ができます。この記事では、後者を実現する仕組みを解説します。何を同期するか、項目をどう対応付けるか、SalesforceとHubSpotで何が違うか、そしてこうしたプロジェクトがどこでつまずきやすいかです。
CRMに本当に必要なパーソナライゼーションデータ
つい、すべてのページビュー、すべてのセッション、すべてのセグメント割り当てを送りたくなります。やめましょう。CRMは構造化された関係データのために作られており、生のクリックストリームのためのものではありません。ページビューを流し込むと、役立つシグナルが埋もれ、APIの割り当てを消費し、レポートの信頼性が下がります。企業項目をエンリッチメントで補えば、リード獲得フォームを短くすることもでき、それも別のメリットです。
同期する価値があるのは5つのカテゴリーです。
1. 企業の識別
訪問者識別で匿名の訪問者が企業と一致したら、その一致によって企業レコードを作成または更新すべきです。営業担当者やレポートが使う項目に絞りましょう。
- 企業名とドメイン
- 業種と従業員数の範囲（エンリッチメントによる）
- 国または本社所在地
- 自社サイトでの初回確認日
- 最初に特定された訪問の流入元またはチャネル
これがなければ、他の何もつながりません。誰かがフォームに入力したときにしかCRMがアカウントを把握できないなら、その企業からのそれ以前の訪問はすべて営業から見えません。
2. セグメントへの所属
セグメントは、そのアカウントが誰なのかについての自社の解釈をすでに含んでいるため、生のページビューより役に立ちます。典型的な値は次のとおりです。
- 業界セグメント（例：「Fintech」「Healthcare」）
- 規模区分（「Mid-Market」「Enterprise」）
- ジャーニーステージ（「認知」「検討」「意思決定」）
- 関心クラスター（「ABM」「分析」「プライバシー」）
セグメントの変化は速やかにCRMに届くべきです。アカウントが火曜日に比較検討段階から決定段階に移っても、日曜日に届く週次のバッチ処理では遅すぎます。高速な同期とは、通常は定期的な取得ではなくイベント駆動の送信を意味します。それぞれが適する場面は、WebhookとAPIの比較記事で説明しています。
3. 単一のエンゲージメントスコア
アカウントに同期するのは、内訳ではなく算出済みの単一スコアにしましょう。0〜100の数値フィールドなら、営業担当者が読み取りやすく、絞り込みにも使いやすくなります。量だけでなく直近性にも重みを付けます。昨日15ページ閲覧したほうが、3か月前に20ページ閲覧したよりも高いスコアになるべきです。可能であれば、理由を記した短いテキストフィールド（「今週料金ページを2回閲覧」）も追加しましょう。理由付きのスコアは行動につながりますが、単なるページ数は読み飛ばされます。
4. すべてのページ訪問ではなく、重要ページの訪問
購買意図を示すページへの訪問だけを同期します。
- 料金（タイムスタンプと回数）
- 個別の機能ページ
- 導入事例（どの業種またはユースケースか）
- 比較ページと競合ページ
- 連携とドキュメントのページ
営業担当者が電話の前にざっと確認できるよう、アクティビティまたはタイムラインの項目として記録します。誰かがスクロールした47本のブログ記事のリストは、役に立つ背景情報にはなりません。
5. 文脈付きのコンバージョンイベント
フォーム入力、デモ申し込み、ダウンロードは、その周辺の文脈とともに届くべきです。訪問者がどのパーソナライズされたバリアントを見たか、どのセグメントにいたか、その時点のエンゲージメントスコアです。それによって営業担当者は、リードの温度感とどの切り口で話を始めるべきかがわかります。
2つの連携方法
| 直接API | ミドルウェア（CDP／iPaaS） | |
|---|---|---|
| 仕組み | パーソナライゼーションツールが CRM の API を呼び出し、レコードを作成または更新する | ツールがSegment、Workato、Tray.io、またはCDPにイベントを送信し、そこで変換してCRMやその他のシステムに振り分けます |
| 適している用途 | 送信先が1つ、運用チームが小規模、ネイティブのコネクタがある | 連携先が多い、またはすでにCDPやiPaaSを運用している |
| デメリット | 送信先が増えるたびに新たな連携が必要。レート制限の影響を直接受ける。CRMのAPIが変わると動かなくなる | 追加コスト、保守するシステムの増加、レイテンシーが1段階増える |
すでに他のデータをCDPやiPaaS経由で送っているなら、パーソナライゼーションのデータも同じ方法で送りましょう。送信先がCRMだけなら、直接接続のほうがシンプルです。2つのシステムの連携のためにミドルウェアを構築しても、ほとんどの場合、数か月の期間が延びるだけです。MarkettailorはSalesforceとHubSpotに訪問者と企業のデータを直接同期できるため、カスタムコードなしで直接接続を実現できます。
フィールドマッピング：誰もが過小評価する部分
API接続は簡単な部分です。難しいのは、パーソナライズのデータをCRMのレコードにどう対応付けるかを決めることです。ここを誤ると、重複、項目の上書き、そしてデータを信頼しなくなる営業担当者が生まれます。
企業のマッチング
パーソナライゼーションツールは企業を特定し、CRMにはアカウントがあります。両者が一致するかどうかは照合のロジック次第です。信頼性の高い順に選択肢を挙げます:
- 共通の外部 ID。両方のシステムが同じエンリッチメント ID（例：LinkedIn の企業 ID）を持っている状態です。最も信頼性が高い方法ですが、両方が同じプロバイダーでエンリッチされている場合にしか使えません。
- ドメイン照合：訪問者の企業ドメインを、CRMの取引先にあるWebサイト項目と照合します。CRMデータが整っていれば機能しますが、Webサイト項目が空欄の場合や、複数のドメインを持つ企業では照合できません。
- あいまいな名前の一致。「Acme Corp」＝「Acme Corporation」。フォールバックとしては有用ですが、よくある名前ではリスクがあります。
実際には、ほとんどのチームがドメインを主キーにし、あいまいな名前一致を代替手段にし、残りは手動レビューのキューに回します。下流の処理を自動化する前に、自社のデータで各段階のマッチ率を測定しましょう。
重複の防止
- 作成する前に検索する。必ずまず既存のレコードを確認します。
- 更新のみのモードで始めます。最初の数週間は、既存のレコードだけを更新します。これにより、害を及ぼす前に、マッチングが実際にどれほど正確かが分かります。
- 信頼度のしきい値を超えた場合のみ作成する。信頼度の低いマッチは人による確認待ちにします。
更新のみのモードを省くと、こうしたプロジェクトは最初の週にCRMを重複アカウントで埋めてしまうのが常です。その後始末には、ドライランにかかる時間よりはるかに多くの運用工数がかかります。
カスタム項目
同期を構築する前に項目を設計します。Accountオブジェクト上で使える出発点となる項目セットは次のとおりです（SalesforceのAPI名を記載。HubSpotでは会社プロパティに相当します）。
| 項目 | タイプ |
|---|---|
Personalization_Engagement_Score__c | 数値、0〜100 |
Personalization_Segment__c | 選択リスト |
Buyer_Journey_Stage__c | 選択リスト：認知、検討、意思決定 |
First_Website_Visit__c / Last_Website_Visit__c | 日付 |
Website_Visit_Count__c | 数値 |
Top_Content_Interest__c | テキスト |
アクティビティのタイムラインには、料金ページの訪問、主要機能ページの訪問、セグメントの変化、大きなスコアの上昇（例：40から75へ）を記録します。
Salesforceのメモ
APIの割り当て。Salesforceは、REST、SOAP、Bulkの呼び出しを24時間単位の割り当てに対してカウントします。Salesforceの制限クイックリファレンスによると、割り当てはエディションとライセンスの数・種類によって異なり、Enterprise Editionは24時間あたり100,000リクエストからです。同期頻度を決める前に、［設定］>［システムの概要］で自社組織の実際の数値を確認してください。割り当て内に収めるには：
- バッチで更新します。sObject Collections エンドポイントなら、1回のリクエストで最大200件のレコードを更新できます。
- エンゲージメントスコアは、変更のたびではなく、スケジュール（数時間ごと）でプッシュします。
- 主要ページの訪問のみを同期します。
- 初回のバックフィルにはBulk APIを使います。
アクティビティタイプと権限。専用の「Webサイトパーソナライゼーション」アクティビティタイプを作成し、営業担当者が自分のアクティビティとこれらのイベントを区別してフィルタリングできるようにします。パーソナライゼーション関連の項目は営業には読み取り専用にしましょう。営業担当者がエンゲージメントスコアを編集すべきではありません。
初日に作成すべき2つのレポート。1つ目は、進行中の商談がない高エンゲージメントのアカウント、つまり誰も手を付けていないパイプラインです。2つ目は、パーソナライゼーションのセグメント別の受注率で、これはセグメンテーション戦略にフィードバックされます。
HubSpotのメモ
「Website Personalization」というプロパティグループを作成し、すべてのカスタムプロパティをそこにまとめます。プロパティの種類はシンプルに対応づけられます。スコアや件数には数値、セグメントや段階にはドロップダウン選択（リストやフィルターで使えるように）、初回・最終訪問には日付、関心タグには単一行テキストを使います。
主要ページの訪問やセグメントの変化については、HubSpot のタイムラインイベントを使えば、アプリが企業や連絡先のタイムラインにカスタムイベントタイプを書き込めます。ページ URL、ページカテゴリー、セグメントをプロパティとするテンプレート（「Website Personalization Activity」）を1つ定義しましょう。これらの書き込みもアプリの API 制限にカウントされるため、Salesforce の場合と同じようにバッチ処理します。
データがHubSpotに入れば、ワークフローでそれをアクションに変えられます。たとえば：
- エンゲージメントスコアが70を超えたら：企業の担当者にタスクを作成します。
- 購買段階が「意思決定」に変わる：主要な連絡先をシーケンスに登録する。
- ターゲットアカウントが3回目の料金ページ訪問：営業のSlackチャンネルに投稿。
ここで、パーソナライゼーション分析は「誰かが開くのを忘れずにいなければならないダッシュボード」ではなくなります。
何をどのくらいの頻度で同期するか
| 数分以内 | 1〜4時間ごと | 日次バッチ |
|---|---|---|
| フォーム送信とデモ依頼 ターゲットアカウントからの料金ページ訪問 新たに識別された企業 | エンゲージメントスコア セグメントの変化 ジャーニーのステージの変化 | 訪問回数の集計 関心タグ 初回 / 最終訪問日 |
すべてをリアルタイムで同期するとAPIの割り当てを使い果たし、レコードが更新であふれます。すべてを日次でまとめて処理すると、ターゲットアカウントの料金ページ訪問が一晩見過ごされます。上記の分け方なら、時間に敏感なシグナルは速く、それ以外は低コストのバッチで処理できます。
こうしたプロジェクトがつまずくポイント
誰も読まないデータを同期する。何かを構築する前に、数人の営業担当者とそれぞれ30分ずつ話し、電話の前に何を知りたいかを尋ねましょう。その答えを中心に構築します。営業担当者が見つけられる短い項目リストの方が、スクロールで読み飛ばされる15個の項目よりも役立ちます。
データの所有ルールがない。両方のシステムが同じフィールド（たとえば業種）を持つ場合は、どちらを優先するか決めましょう。通常は、営業担当者が管理する情報（商談ステージ、コンタクト）はCRMが、行動データ（スコア、セグメント、訪問）はパーソナライゼーションツールが所有します。これを決めないと、2つのシステムが互いの値を延々と上書きし合います。
ドライランを行わない。CRMに対してドライランモードでマッチングを実行し、100件のマッチを抽出して手作業で確認します。誤りが多すぎる場合は、本番環境に書き込む前にロジックを修正してください。
1つのチームだけで構築する。マーケティングオペレーションはどんなデータがあるかを知り、セールスオペレーションは営業担当者がどの項目を見るかを知っています。マーケティングだけで作れば、データは誰も見ない項目に入ります。営業だけで作れば、最良のシグナルが抜け落ちます。設計の打ち合わせそのものが、訪問者データによる営業とマーケティングの連携の一部なのです。
設定して放置する。毎月レビューの場を設け、営業担当者にどのデータを使い、何が足りないかを話してもらい、項目、スコアリング、アラートを調整しましょう。
うまくいっているかの見極め方
目標は自社で設定しつつ、稼働前後で次の項目を測定しましょう:
- 活用度：過去7日間にパーソナライズの項目やアクティビティを開いた営業担当者の割合。
- 健全性：同期のエラー率と、抜き取りチェックによるマッチ精度。
- カバー率:最近Webサイトでの活動があるアカウントのうち、パーソナライゼーションのデータが入力されている割合。
- フォローアップの速さ：エンゲージメントの急増から営業の最初の接触までの時間。
- パイプライン：パーソナライゼーションが起点のアラート後に創出された商談。
最初の3つで、1〜4週目に仕組みが機能しているかが分かります。最後の2つで、その後の数か月で営業の行動が変わるかどうかが分かります。
5週間の展開計画
- 1週目：設計。営業担当者数人にヒアリングします。5〜8個の項目を選び、カスタム項目を作成します。マッチングのロジックと所有権のルールを書き出します。
- 2週目、構築とドライラン。システムを接続し、ドライランモードでマッチングを実行し、100件のマッチを手作業で確認して、誤りを修正します。
- 3週目：更新のみ。レコードを作成せずに同期を5営業日オンにします。エラーと対応付けの問題を監視し、2〜3人の営業担当者からフィードバックを得ます。
- 第4週：本格稼働。確信度の基準値を超えるものはレコード作成を許可し、段階的な同期スケジュールを設定し、2つのレポートを作成して、データの場所を営業に示します。
- 5週目以降。営業との月次レビュー。項目、スコアリング、自動化を調整します。
ひとつだけやるなら
企業の識別情報とエンゲージメントスコアをアカウントレコードに同期しましょう。それだけで、今まさにどの企業が自社を調べているかを営業に伝えられます。訪問者識別の設定が企業データを提供し、アカウントスコアリングモデルがスコアを定義し、CRMは営業担当者が普段から見ている場所です。この記事のほかの内容は後回しで構いません。