【第594回】Personalization：顧客 ID で CRM と Web の Profile を統合する

2026年10月3日 21:40

前回の記事では、TrailNest の CloudPages に Web SDK を設置し、購入情報と商品明細、Email Address、Customer ID が Data 360 の DLO・DMO に取り込まれたことを確認しました。

今回は ID 解決 を設定し、Web サイトから取得した匿名の Profile を、CRM が管理している既知の顧客 Profile と関連付けます。

Web 由来の元レコードは匿名として保持し、CRM の既知 Profile と統合された Unified Individual（統合個人）を既知として扱う構成にします。Web の元レコードを既知に書き換える処理は追加しません。

ID 解決に使用するのは、TrailNest の Customer ID です。Email Address は連絡先情報として保持し、照合条件には使用しません。

今回は CRM の Contact（取引先責任者） を顧客情報の例として使用します。

Personalization 基礎シリーズ

Sitemap Builder シリーズ

Data 360 設定シリーズ

Personalization 設定シリーズ

① CRM と Web を何で関連付けるのか

前回、Web サイトから取得した情報は、次の内容でした。

deviceId：557d0d50dc471e3b
Customer ID：POC-011-001
Email Address：trailnest.poc011@example.com

今回の Mapping では、deviceId を Individual DMO の Individual ID に設定しています。

一方、CRM の Contact を取り込む場合は、通常、Contact ID に対応する Individual が作られます。

つまり、Data 360 には次の2つの Individual が存在する構成です。

Web 由来の Individual：ブラウザの deviceId で識別
CRM 由来の Individual：CRM の Contact ID で識別

この 2 つの ID は、同じ人物でも一致しません。そこで、両方に共通する Customer ID を使用します。

匿名・既知と ID 解決は、別の判定

今回の Web SDK は、初回アクセス時に次の Identity を送信しています。

{
  "eventType": "identity",
  "isAnonymous": 1
}

Data 360 では、取り込み元の Individual の Is Anonymous によって、その Profile を匿名・既知に区分します。

Checkout で Email Address と Customer ID を取得したことと、匿名・既知の区分を変更することは別です。今回の Sitemap では、これらの情報を取得した後も、Web の Identity を既知に変更する処理は設定していません。

したがって、前回までにできたのは、匿名の Web Profile に、照合に使う Customer ID と連絡先の Email Address が関連付いた状態です。

今回は、この Customer ID を使って CRM の既知 Profile と統合します。統合元に既知 Profile が含まれると、統合 Profile は既知として扱われます。匿名の Profile 同士を統合しただけでは、ID 解決が完了しても匿名のままです。

Is Anonymous は Profile の単なる区分を表します。この値を変更するだけで CRM と照合されたり、本人認証が完了したりするわけではありません。

CRM に 3 つの項目が必要なのか

Party Identification では、次の 3 つの値を使って照合します。

Identification Name：TrailNest Customer ID
Party Identification Type：Customer ID
Identification Number：POC-011-001

これらをすべて CRM のカスタム項目として作成しても良いのですが、Name と Type に関しては Data 360 の数式項目で固定値を付与できます。

重要なのは、Data 360 に取り込まれた後の Party Identification に、Web 側と同じ 3 つの値が入ることです。

② CRM に検証用の顧客を用意する

CRM の Contact に、検証用の顧客を1件用意します。

今回の例では、次の情報を使用します。

First Name：TrailNest
Last Name：POC Customer
顧客番号：POC-011-001
Email：送信可能な自分のメールアドレスなど

CRM の Email は、Web から取得したものと意図的に異なる値にしています。今回、同一人物として判断するのは Email ではなく、Customer ID だからです。

③ CRM の Contact を Data 360 に取り込む

Data Streams で、CRM の Contact を取り込んでいる Data Stream を確認します。

すでに Salesforce CRM Connector から Contact を取り込んでいる場合は、その Data Stream を使用します。同じ Contact を取り込む Data Stream を重複して作成する必要はありません。

まだ取り込んでいない場合は、Salesforce CRM Connector を使用して Contact の Data Stream を作成します。Web 側と同じ default Data Space で利用できる構成にします。

Individual の通常のマッピング

Marketing Cloud Next が導入済みであれば、Contact は標準の Mapping がすでに設定されているはずなので、作り直す必要はありません。

④ Party Identification を Mapping する

CRM 由来の Individual にも、TrailNest の顧客番号を関連付けます。

Name と Type の固定値を用意する

Contact の Data Stream の数式項目を使用し、次の2つの Text 項目を用意します。Data Stream の作成時、または編集時の New Formula Field から追加します。

表示名：TrailNest Identification Name

戻り値の型：Text
返す固定値：'TrailNest Customer ID'

表示名：TrailNest Identification Type

戻り値の型：Text
返す固定値：'Customer ID'

ここで重要なのは、項目の表示名ではなく、項目に入る値です。Web 側と表記を揃えます。

Party Identification DMO への Mapping

CRM の Contact に対する今回の Mapping は、次のとおりです。

Contact ID → Party Identification ID
Contact ID → Party
Customer Id → Identification Number
TrailNest Identification Name → Identification Name
TrailNest Identification Type → Party Identification Type
Created Date → Created Date（※自動マッピング）
Last Modified Date → Last Modified Date（※自動マッピング）

⑤ Customer ID の ID 解決ルールを作成する

Data 360 の ID 解決 を開き、TrailNest 用のルールセットを作成します。

これは既存のものに載せるか、新しく作成するかは運用次第ですが、今回は Marketing Cloud Next で使用中の既存のものに載せます。

こちらはまだ ID 解決が 1 件もない状態です。

ID 解決ルールセットを複数作るとコストが上昇する可能性がありますので、この辺りの設計は注意が必要です。今回のルールセットはリアルタイムデータグラフを作成するとリアルタイム ID 解決を受け入れるルールセットに変更されますが、引き続きバッチ更新も行うことは可能です。

Match Rule の設定

既存のマッチルールはすべて削除します。

その後、Match Rules → Configure（または Edit）→ Add Match Rule → Custom Rule から設定します。

以下を入力します。

Match Rule Name：TrailNest Customer ID Match
Data Model Object：Party Identification
Field：Identification Number
Match Method：Exact

続いて、Configure をクリックして、以下を入力したら保存します。

Party Identification Type：Customer ID
Party Identification Name：TrailNest Customer ID

※ 次の画面では、「Match Rule Name」がクリアされますので、再度「TrailNest Customer ID Match」を入力してから保存してください。

設定後、TrailNest Customer ID Match にアラートが立ちますが、これは無視してください。Party Identification では必ず立ちます。

この構成では、Customer ID が同じであれば、Email が異なっていても統合対象になります。逆に、Customer ID が異なる顧客を、Email の一致だけで統合することはありません。

※この画面の下にある「Case Sensitive」のオプションは、例えば「オフ」の設定であれば、POC-011-001 と poc-011-001 を区別しません。「オフ」がデフォルトなので、このまま進めます。

Reconciliation Rules の設定

Reconciliation Rules は、統合対象のデータで項目の値が異なるときに、Unified Profile に採用する値を決める設定です。

今回は Individual のデフォルトルールを Source Priority（Contact を最優先）として保存します。

⑥ ID 解決を実行する

CRM と Web の両方のデータが DMO に入ってから、ルールセットを実行します。

自動実行を使用している場合は、今回の取り込みを反映した処理が完了していることを確認します。検証のために手動実行する場合は、自動実行を無効にしたうえで Run Ruleset を使用します。画面構成によっては Processing History から実行します。

今回の検証が終わった後も Profile を継続的に更新するため、運用時は自動実行の設定を確認します。後ほどリアルタイム ID 解決を使う場合も、通常の ID 解決の実行は必要です。

処理が完了したら、Resolution Summary を確認します。

⑦ CRM と Web の統合結果を確認する

統合率や Profile の総数だけでは、今回の CRM と Web が関連付いたかは判断できません。次の手順で対象レコードを直接確認します。

Query Editor で、以下のクエリを実行します。

SELECT UnifiedId, Id, FirstName, LastName, Email, DataSource, IRUpdatedDate
FROM (
    SELECT
        b.UnifiedRecordId__c AS UnifiedId,
        b.SourceRecordId__c AS Id,
        d.ssot__FirstName__c AS FirstName,
        d.ssot__LastName__c AS LastName,
        c.ssot__EmailAddress__c AS Email,
        b.ssot__DataSourceObjectId__c AS DataSource,
        b.CreatedDate__c + interval '9 hour' AS IRUpdatedDate,
        ROW_NUMBER() OVER (
            PARTITION BY b.SourceRecordId__c, c.ssot__EmailAddress__c
            ORDER BY c.ssot__LastModifiedDate__c DESC
        ) AS rn
    FROM
        IndividualIdentityLink__dlm a /* ← 自分の Unified Link Individual DMO の API 名に変更する */
    LEFT OUTER JOIN IndividualIdentityLink__dlm b /* ← 自分の Unified Link Individual DMO の API 名に変更する */
        ON a.UnifiedRecordId__c = b.UnifiedRecordId__c
    LEFT OUTER JOIN ssot__ContactPointEmail__dlm c 
        ON b.SourceRecordId__c = c.ssot__PartyId__c
    LEFT OUTER JOIN UnifiedIndividual__dlm d /* ← 自分の Unified Individual DMO の API 名に変更する */
        ON a.UnifiedRecordId__c = d.ssot__Id__c
    WHERE a.SourceRecordId__c = '***' /*Individual Id Filter*/
    -- WHERE c.ssot__EmailAddress__c = '***' /*Email Address Filter*/
) t
WHERE rn = 1
ORDER BY Id
LIMIT 10

この時、Individual Id Filter に今回の CRM の 18 桁の ID を入力してください。今回、Contact を優先にしているので、Source Record Id に CRM の Contact ID が入っています。

すると、今回の統合対象の 2 レコードが表示されます。成功です。

⑧ Real-Time Data Graph を作ると、リアルタイム ID 解決になるのか

ここまで確認したのは、取り込み済みのデータに対して実行した ID 解決です。

では、Personalization で利用する Real-Time Data Graph を作成すると、何が変わるのでしょうか。

初回の ID 解決が完了したルールセットの Unified Individual を、Real-Time Data Graph の Primary Data Model Object に指定すると、そのルールセットをリアルタイム ID 解決にも使用できるようになります。

通常の ID 解決とリアルタイム ID 解決は併用する

このことは、通常の ID 解決がなくなり、すべての処理がリアルタイムへ置き換わるわけではありません。

通常の ID 解決では、取り込まれたデータを照合し、Unified Individual などの統合結果を生成・更新します。

リアルタイム ID 解決では、アクセス中の利用者の識別情報を、関連する Real-Time Data Graph 内の統合 Profile と照合し、Personalization で利用する Profile を特定します。

今回の POC で目指す動作は、次の流れです。

CRM の顧客を Data 360 に取り込む
ID 解決によって、その顧客の Unified Profile を用意する（ここまで済み）
そのルールセットの Unified Individual を起点に Real-Time Data Graph を作成する
Web から共通の Customer ID を送信する
CRM に由来する既存の既知 Profile とリアルタイムで照合する
CRM の属性と Web 行動を Personalization に利用する

リアルタイム検証では新しいシークレットブラウザを使用する

今回の検証に使った Web の Individual は、すでに通常の ID 解決で CRM と統合されます。

次のリアルタイム検証では、新しいシークレットブラウザや別のブラウザなどで新しい deviceId を用意する必要があります。

そのブラウザが Customer ID を送信したときに、通常の ID 解決の次回実行を待たず、既存の CRM 顧客の Profile を利用できるかを確認してみましょう。

いかがでしたでしょうか。

今回は、TrailNest の Customer ID を共通の識別子として、CRM の顧客と Web の訪問者を同じ Unified Individual に関連付ける手順を紹介しました。

そして、今回のルールセットが生成した Unified Individual を起点に Real-Time Data Graph を作成すると、同じ照合ルールをリアルタイム ID 解決にも使用できます。通常の統合処理と、その場での照合の両方を組み合わせて、Personalization につなげていきます。

次回は Real-Time Data Graph を設定し、今回統合した CRM の顧客情報と Web 行動を、Personalization で利用するための構成を確認します。

今回は以上です。