B2BイベントのデータをCRMに連携する方法

B2BイベントのデータをCRMに連携するスキーム：エンティティ、ID、ステータス、フィールド、同意、重複、受け取ったレコードの検証。

B2B（business-to-business）イベントのデータは、会場とCRM（顧客関係管理システム）の間でしばしば意味を失います。フォームには氏名とemailがあり、バッジには番号が現れ、スキャナーがアクションを記録します。しかしターゲットシステムには、どのイベント、セッション、ミーティング、招待元かが分からない新しい連絡先が残るだけです。

「Aventura」では別の側から始めます。顧客のシステムに届くべき事実を記述し、CRMがその受信をどう確認するかを合意します。このような契約は登録開始前に必要です。後から識別子（ID）、ステータス、フィールドの用途を変更するのは格段に難しくなります。データはすでに複数のポイントから同時に流れているからです。

ビジネスイベントを準備していて、登録、到着確認（check-in）、会場でのアクティビティを事前に顧客のシステムと結び付けたい場合は、プロジェクトの実務的な打ち合わせをお申し込みください。イベントのデータスキームと合同テストの要件の記述をお手伝いします。CRMの設定と管理は顧客の専門チームが担当します。

CRMに入れるべきデータは何か？

CRM内の具体的なアクションを支えるデータだけを渡してください。各フィールドと事実について、目的・所有者・受信者を事前に定めます。誰がその値を使い、次に何をするのかをチームが説明できない場合、そのフィールドはフォームや連携から外すべきです。

B2Bイベントには複数のソースがあります。招待はキャンペーンと流入チャネルを示します。登録は誰が参加を申し込んだかを伝えます。

到着の記録は出席を裏付けます。セッション、ミーティング、ブースでのアクションは新たな事実を追加します。CRMはこれらの部分を共通のコンテキストとともに受け取るべきですが、必ずしも1つのオブジェクトに保存する必要はありません。

各ソースに対する最小限の問いは次のとおりです。

UTM（Urchin Tracking Module）タグは、流入元・チャネル・キャンペーンを区別するのに役立ちます。これらは登録のコンテキストに属し、個人や申し込みの識別子を置き換えるものではありません。バッジ番号も汎用キーにしてはいけません。その役割は特定のプロジェクトとアクセス方法に限定されます。

登録と連邦法第152-FZの要件に関する別記事では、フォームの法的・運用的側面を詳しく扱っています。ここではより狭い範囲、すなわちどのエンティティとフィールドがCRMの確定レコードに至るかを扱います。

1つの過負荷な連絡先ではなく5つのエンティティ

人物、企業、登録、出席、アクティビティはそれぞれ異なる問いに答えます。これらを1つの連絡先カードにまとめてフィールドを絶えず上書きすると、システムは履歴を失います。関連レコードは事実の順序を保ち、各転送を個別に検証できるようにします。これによりチームは連絡先の現在の状態だけでなく、特定のイベントにおける参加者の経路も把握できます。

人物（Person） - 参加者のマスターレコードです。マスターレコードには安定した連絡先情報と採用済みの識別子が含まれます。人物は複数のイベントに参加し、何度も登録し、さまざまなアクションを行うことができます。

企業（Company） - 組織です。企業はすべての場合でメールのドメインと等しいわけではないため、関連付けのルールを承認する必要があります。企業ドメインは強い指標になり得ます。パブリックメール、子会社、コンサルタントは別の判断を要し、時に手動での確認が必要です。

登録（Registration） - 特定のイベントに対する人物の申し込みです。独自のID、event ID、ソース、作成時刻、ステータスを持ちます。同じ人物が別のイベントに再参加すると、新しい人物ではなく新しい登録が作成されます。

出席（Attendance） - 在席の事実です。登録は来場を証明しません。Microsoft Customer Insightsもevent registrationとcheck-inを分けており、check-inはイベント全体または個別セッションに関連付けられる場合があります。そのため「登録済み」と「出席済み」のフィールドを同義と見なすことはできません。

アクティビティ（Activity） - 個別のアクションです。セッションへの出席、ミーティング、資料のスキャン、ブースへの来訪、その他合意された事実です。アクティビティは独自のID、タイプ、時刻、コンテキストを保持します。HubSpot Meetings APIも同じ論理に従います。ミーティングは独立したCRMアクティビティとして存在し、連絡先や企業と関連付けられます。

このモデルはすべてのCRMで同一の構造を要求するものではありません。あるシステムでは登録が独立したオブジェクトになり、別のシステムではキャンペーンへの参加、アクティビティはアクションログのレコードになります。意味はどのような技術的表現でも保持されるべきです。

全行程のための識別子システム

各オブジェクトと事実には、個別の安定したIDが必要です。発行元は識別子を一度だけ発行し、後続のシステムはそれを再生成せずに引き継ぎます。そうすれば、再配信は重複として認識され、チームはフォーム、連携ログ、CRMで同じレコードを見つけられます。

実用的なセットには以下を含められます：

1. event_id - 特定のイベント。
2. person_id - 合意された領域における人物のマスターレコード。
3. company_id - 顧客システムまたは連携ディレクトリ内の組織。
4. registration_id - このイベントへの人物の申し込み。
5. attendance_id - 個別のチェックイン事実。
6. activity_id - セッション、ミーティング、ブース、その他のアクション。
7. source_system - その事実を作成したシステム。
8. schema_version - データ契約のバージョン。

RFC標準はUUIDを規定しています。これは中央登録なしで発行できる、汎用一意の128ビット識別子です。フォーム、モバイルアプリ、会場の機器を異なるシステムが処理する場合に便利です。UUIDv7はさらに時間順序をサポートしますが、具体的なバージョンは二次的なものです。重要なのは別の点です。1つのチームが発行ルールを定め、すべての参加者がその値を保持します。

CloudEvents仕様は、イベント伝送の有用なモデルを定義しています。source + idのペアが個別のイベントを特定し、再送された事実は同じIDを保持できます。受信側はそれにより、名前、email、時刻から推測することなく重複を認識できます。

重要。伝送される事実の識別子は、人物の識別子やイベントのevent_idとは異なります。Adobe XDM ExperienceEventのイベントモデルは、イベントレコードの_idと人物のidentityを明確に分けています。1人の参加者が多くのアクティビティを生み出すことができ、それぞれが固有の識別子を持ちます。

カンファレンスやフォーラムでは、このアプローチが特に有用です。登録、共通入場、トラックへの参加、設定されたミーティングはプロジェクトの異なる部分から来ますが、共通のevent_idとperson_idの周りに集約されます。これによりチームは、異なるエンティティを連絡先カード内で混同することなく、各事実の経路を検証できます。

請負業者がフォーム、バッジ、スキャナーを設定する前に、イベントのデータスキーマを合意する必要があります。データスキーマの検討と概算見積もりをご依頼ください。当社はイベントのタッチポイントを1つの技術仕様にまとめ、顧客側のCRMオーナーとともにテストを実施します。

ステータスについて合意するには？

ステータスにはコード、定義、所有者、および許容される遷移が必要です。「来場した」「参加した」「関心を示した」といった自由記述は、意味がすぐに拡散してしまいます。マスタは、どの事実が状態を変え、CRMが何を受け取るのかを固定します。登録、来場、ミーティングに別々の辞書を用意すれば、同じ言葉が異なるイベントを指すことはなくなります。

まずは個別の辞書から始めてください。登録ステータスは、出席ステータスやミーティングの結果と混在させてはいけません。

表内の名称は構造の例です。最終的なコードは依頼元のチームが選択します。CRMに既にマスタがある場合、送信側は明示的なマップを通じてそれに合わせます。送信側が独自の辞書を使う場合、マップは各対応関係と未知の値に対する動作を示さなければなりません。

各ステータスについて、4つのルールを記録してください：

1. どの観測可能な事実がそのステータスを設定するか。
2. 誰が値を変更する権限を持つか。
3. 前の状態に戻すことができるか。
4. 遅延イベントや重複イベントが発生した場合に何が起こるか。

例えば、checked_in は入場時のスキャンが受理された後に発生します。同じ attendance ID の再スキャンは2回目の来場を生成しません。登録の遅延キャンセルは、依頼元のポリシーが履歴の保存を求める場合、既に確認された出席の事実を削除しません。

キャンペーン中に既存コードの値を変更しないでください。新しいスキーマバージョンを追加し、移行について合意してください。そうしないと、変更前と変更後で同じ status=confirmed が異なる意味を持つことになります。

フィールドとコンテキストのマップをどう作成するか

フィールドマップは、名前、型、必須性、変換、エラー時の挙動のレベルでソースとCRMを結び付けます。単なる列のリストでは不十分です。受信側は、値がどこから来たのか、どのエンティティに属するのかを理解する必要があります。論争のあるフィールドについては、参照辞書、スキーマのバージョン、意思決定のオーナー、不正な値に対するシステムの応答をすぐに記録します。

HubSpot Properties APIは、データ型とフィールドのインターフェースの違いをよく示しています。文字列、日付、数値、enumerationはそれぞれ異なる形で保存されます。ステータスの参照辞書には、テキストフィールドではなく限定された値のセットが適しています。独自の外部IDは、対象のCRMがそのモードをサポートしていれば、一意性を要求するフィールドに設定できます。

最小限のフィールドマップは次のとおりです。

コンテキストはブースにとって特に重要です。badge_number=1842だけを送信しても、受信側には何も伝わりません。event ID、activity ID、アクションの種類、時刻、スキャンのソース、personまたはregistration IDが必要です。参加者が特定の資料をリクエストした場合、資料コードは受信側に合意されたアクションがある場合にのみ、別のフィールドで送信されます。

展示会への参加の場合、マップは一般的な登録だけでなく、ゾーン、ブース、スキャナー、異なるデータオーナーもカバーする必要があります。ソースが多いほど、統一されたsource_system、スキーマのバージョン、拒否されたレコードのログがより重要になります。

最小化のルールで許可されている場合は、元の値を変換後の値の隣に保存しておくと便利です。そうすれば、論争のあるステータスを会場に再問い合わせすることなく分析できます。このような技術的痕跡の保存期間は発注者が決定します。

データ最小化と同意

フォームとデータ連携は、目的に対して必要最小限の項目のみを収集すべきです。項目が増えるほど、確認作業の量、エラーの数、法的負担が増加します。W3C WAIは、プロセスを完了するために必要な情報のみを尋ね、わかりやすいラベル、説明、エラーメッセージを提供することを推奨しています。

当社はシンプルな項目フィルターを使用しています：

1. その項目はイベントやCRMでどのような課題を解決するのか？
2. その値の所有者は誰か？
3. 受け取った後にどのようなアクションが続くのか？
4. 登録時点ですでに正確性が必要か？
5. マスターシステムから後で値を取得できるか？
6. 参加者が項目を入力しなかった場合、何が起こるか？

最初の3つの問いに答えがない項目は、通常削除されます。たとえば、詳細な業界プロファイルはプログラムに役立つ場合がありますが、誰もセグメンテーションを利用せず、データが参加者の動線に影響しないのであれば、収集すべきではありません。

同意およびその他の処理の根拠は、目的ごとに設計されます。欧州データ保護会議（EDPB）は、一般データ保護規則（GDPR）に関するガイダンスにおいて、具体的で、情報に基づいた、明確な同意、およびそれがいつ、どのように取得されたかを証明できることを求めています。この文書はロシアの法的審査の代替にはなりませんが、有用な原則を示しています。すなわち、イベントへの参加とその後のマーケティングコミュニケーションを、区別できない1つの欄に隠すべきではありません。

処理が同意に基づく場合、データ契約には以下が必要になることがあります：

• 目的；
• テキストのバージョン；
• 時刻；
• インターフェースの取得元；
• 選択結果；
• 顧客のシステムにおける変更または撤回の方法。

Google Customer Matchはもう一つの境界を示しています。広告プラットフォームは企業自身のオンラインおよびオフラインデータを扱いますが、欧州経済領域のユーザーデータのパートナーによるアップロードには同意シグナルを要求します。登録データをCRMに運用上転送すること自体は、あらゆる広告アクティベーションの許可を意味するものではありません。この目的、項目の構成、根拠については、顧客が別途合意します。

重複を作らないためには？

重複排除には、類似レコードの検索と、それに対する処理を個別に判断することが含まれます。安定した外部IDの完全一致は自動で処理できます。氏名、会社、メールアドレス、電話番号による確率的な一致には、ルールや優先順位、場合によっては手動での確認が必要です。運用開始前に、チームはどの項目を完全一致とみなし、どの項目を照合対象とするだけかを定義します。

Salesforceは、一致検索ルール（matching rules）と重複処理ルール（duplicate rules）を分けています。前者は候補を検索し、後者は警告する、許可する、作成をブロックするといったアクションを決定します。このロジックは特定のプラットフォーム以外でも有用です。

実務上の手順：

1. external_person_idが既に判明している場合は、それでレコードを検索する。
2. 顧客のポリシーが検索キーとして許可している場合は、正規化されたメールアドレスの完全一致を確認する。
3. その他の確認済み識別子を確認する。
4. より弱い項目の組み合わせで候補を生成する。
5. 結果が曖昧な場合は自動で統合しない。
6. ルールを通過した後にのみ、新しいマスターレコードを作成する。
7. 履歴を上書きせずに、新しい登録やアクティビティをそれに紐付ける。

正規化は送信側と受信側で同じように実行されます。電話番号は合意された形式に変換されます。メールアドレスは空白を除去し、採用された大文字・小文字のルールで検証されます。会社名は唯一のキーとして使用すべきではありません。表記の揺れや企業グループの構造により、誤った一致が生じるためです。

別の課題は冪等性、つまり安全な再送信です。書き込み後にネットワークが切断された場合、送信側は結果を把握できずにリクエストを繰り返す可能性があります。同じregistration_id、attendance_id、またはactivity_idは、2つ目のオブジェクトを作成するのではなく、既存のオブジェクトを更新または確認する必要があります。

最低4つのケースを確認してください：

1つのマスターレコードは、すべてを1行にまとめることを意味しません。マスターは人物に属します。登録、出席、アクティビティは、その人物を中心とした別個の履歴として残ります。

送信・受信・エラーの責任者

データ連携には、送信側と受信側の2名の責任者を定める必要があります。前者は完全性、フォーマット、再送を担当します。後者はCRMスキーマ、受入ルール、リレーション、レコードの検証読み取りを担当します。このペアがいないと、チームは誰がエラーを修正し、誰が再受信を承認するのかを把握できません。

役割分担は次のように定めることができます。

record_id、時刻、スキーマバージョン、理由コード、再処理状態を含むエラーログが必要です。ログ内の個人データは必要最小限に削減します。通常、チームには技術IDと保護されたレコードへの参照があれば十分です。

Aventuraでは、お客様のCRMの導入や、その内部ルールの策定は行いません。イベントのデータソースを記述し、専門チームと送信フォーマットを合意し、会場のシナリオが期待されるファクトを提供することを確認することは可能です。受入モデルとアクセス権限については、お客様のCRMの責任者が担当します。

登録受付開始までの経路をどう検証するか

エンドツーエンドテストは参加者のアクションから始まり、CRMからのレコードの検証読み取りで終わります。その間、チームはデータのソース、転送、処理を個別に検証します。APIの応答やフォルダ内のファイルの出現は、あくまで中間ステップを確認するものです。レコードは、対象システムで主要フィールド、関連、所有者、ステータスが確認された時点で受理されたとみなされます。

実在の人物のデータを含まない、専用のテストイベントと合成レコードのセットを用意してください。その後、シナリオを順番に実行します。

1. 正常な登録。 フォームに入力し、UTMコンテキストを保存し、registration IDを確認します。
2. 既知の人物。 既存のテスト用マスターレコードのperson IDで登録を繰り返します。
3. チェックイン。 テスト用バッジをスキャンし、別個のattendance IDを確認します。
4. セッションまたはブース。 event_id、アクション種別、時刻occurred_at、ソースシステムsource_systemを指定してactivity_idを作成します。
5. ミーティング。 時刻、所有者、結果、人物および企業との関連を送信します。
6. 再送信。 同じレコード識別子をもう一度送信し、重複が作成されないことを確認します。
7. マスタのエラー。 未知のステータスを送信し、合意されたルールに従ってシステムがレコードを拒否することを確認します。
8. 必須フィールドの欠落。 エラー原因が送信者に明確に伝わることを確認します。
9. 検証読み取り。 CRMレコードを読み取り、値、関連、所有者を期待値と比較します。
10. 修正。 元のIDと履歴を失うことなく、修正後にレコードを再送信します。

各検証について、期待結果と実際の結果を保存します。差異には担当者、修正期限を設定し、同じシナリオを再実行する必要があります。

登録とチェックインの負荷検証は隣接する課題を扱います。すなわち、システムが計画された流量に耐えられるか、障害時に何が起こるかです。そのシナリオは登録とチェックインの負荷リハーサルの記事にまとめています。ここでの受け入れ基準は、経路全体を通じた1件のレコードの意味と整合性に限定されます。

テスト後、双方がフィールドマップ、ステータス辞書、テスト結果のバージョンに署名します。これらの文書のいずれかを変更した場合、影響を受けるシナリオの再検証が必要です。

ローンチ準備チェックリスト

プロジェクトの関係者がエンティティ、フィールド、受理済みレコードの判定基準を同じように理解したとき、設計は完成します。このチェックリストは、フォーム公開前の最終合同セッションで使用できます。フィールドマップ全体を繰り返すものではなく、チームが重複や紛争ステータスを管理するために欠かせない決定事項を確定するものです。

1. イベントには安定した event_id があり、登録、来場、アクティビティにはそれぞれ固有の識別子がある。
2. 人物、企業、登録、来場、アクティビティが意味の上で区別されている。
3. ステータスにはコード、定義、オーナー、辞書のバージョンがある。
4. フィールドマップが型、必須性、変換、キャンペーン、エラーを記録している。
5. 一致検索、再送信、重複処理のルールが別途合意されている。
6. 送信、受信、エラー修正のオーナーが明示されている。
7. エンドツーエンドテストに正常レコード、既知の人物、重複、エラー、検証読み取りが含まれている。
8. CRMオーナーが登録公開前にリレーションとスキーマバージョンを確認済みである。

この準備状態は、今後のデータ作業を代替するものではありません。イベントとコマーシャルシステムの全体的な連携については、event-led growthとファネルの記事で解説しています。イベント後にマーケティングと営業へアクションを引き渡す手順は、SLA follow-upの記事にまとめています。現在の設計は、CRMが正しいリレーションとオーナーを持つ検証可能なレコードを受理した時点で終了します。

Aventuraでは、イベントのデータポイントを1つの技術仕様にまとめ、ゲストの導線をたどり、発注者チームと共同テストを実施できます。プロジェクトの相談と概算見積もりをご依頼ください。打ち合わせでは、イベントデータのソース、当社の作業範囲、CRM側の受け入れ担当者を決めます。

出典

• European Data Protection Board - Guidelines 05/2020 on consent
• CloudEvents specification 1.0.2
• HubSpot - CRM Properties API Guide
• HubSpot - Meetings API Guide
• Google Analytics - URL builders and UTM parameters
• IETF - RFC 9562: Universally Unique IDentifiers
• Microsoft Learn - View and manage event attendance
• Salesforce Trailhead - Resolve and Prevent Duplicate Data
• Adobe Experience Platform - XDM ExperienceEvent class
• W3C WAI - Forms Tutorial
• Google Ads - About Customer Match