【第592回】Personalization：Website Connector と Data Mapping の設定
前回の記事では、Sitemap Builder の Review & Download から、
Sitemap.js
Schema.json
を取得しました。
ここまでで、Web サイト側からどのような Event を送信するのかは完成しています。
今回は Salesforce 側へ戻り、
Website Connector
↓
Schema
↓
Sitemap
↓
Data Stream
↓
Data Mapping
を設定します。
この中で特に重要なのが Data Mapping です。
Sitemap や Schema をアップロードしただけでは、取得した Web 行動データを Data 360 のどの Data Model Object（DMO）として利用するのかは決まりません。
今回は、TrailNest で作成した 10 種類の Schema を実際の DMO に Mapping していきます。
Personalization 基礎シリーズ
Sitemap Builder シリーズ
Data 360 設定シリーズ
Personalization 設定シリーズ
Website Connector を確認する
最初の記事で、Sitemap Builder を利用するために Website Connector を作成しています。Website Connector は、Web サイト上の Interaction を Salesforce へ送信するための接続設定です。
今回は、最初に作成した TrailNest 用の Website Connector を開きます。
Schema.json をアップロード
Website Connector に、前回 Sitemap Builder から取得した Schema.json を設定します。
Schema.json には、今回 TrailNest で使用する次の 10 種類が含まれています。
Catalog
Cart
Cart Item
Order
Order Item
Consent Log
userEngagement
Contact Point Email
Party Identification
Identity
Web Connector では、この Schema に従って Web SDK から送信される Event を Data 360 側で受け取ります。
Sitemap.js をアップロード
続いて、前回取得した Sitemap.js を Website Connector に設定します。
Sitemap.js には、
Page Type の判定
Resolver
Product View
Add to Cart
Customer Confirm Email
Customer Identification
Purchase
Listener
など、Sitemap Builder で設定した内容が JavaScript として含まれています。
Sitemap は Website Connector 上で動作し、Salesforce Interactions SDK が Web サイト上の Interaction を取得するためのルール として利用します。
Data Stream を作成する
Website Connector と Schema の設定ができたら、次に Data Stream を作成します。
Web / Mobile Connector では、Data Stream を作成することで、Web サイトから取得したデータを Data 360 へ取り込めるようになります。
Salesforce の公式ドキュメントでは、Web から取得したデータについて、Engagement Data は約 15 分ごと、Profile Data は約 1 時間ごとに取り込まれると説明されています。
ただし、この更新間隔は、通常の Data Stream を通じて標準データレイヤーへ取り込む際の更新周期です。
Salesforce Personalization で利用するリアルタイムプロファイルデータグラフはこれとは別の仕組みで、Web SDK から送信されたデータは、標準データレイヤーだけでなくリアルタイムレイヤーにも取り込まれます。
そのため、Personalization のリアルタイム判定において、Engagement Data の 15 分や Profile Data の 1 時間を待つ必要があるわけではありません。
Personalization で使用する Profile Data Graph は、ユーザーの操作に素早く反応できるよう、Real-Time Data Graph として構成する必要があります。
また、Salesforce のリアルタイム取り込みでは、対応する Web SDK、Mobile SDK、Server-to-Server のストリーミングデータがリアルタイムレイヤーで利用できるようになり、典型的な本番環境では、95% のイベントが取得からリアルタイムレイヤーで利用可能になるまで約 500 ミリ秒以内とされています。
ただし、実際の反映時間は、構成や処理内容、環境負荷などによって変わる可能性があります。
1. データストリームタブを開き、新規をクリックします。
2. Website を選択します。
3. 該当の Website コネクタを選択して、すべてにチェックを入れて先に進みます。
4. 次はレビュー画面なので、そのまま先に進めます。
5. 次の画面は、リフレッシュモードの選択になり、「プロファイル」だけは選択はできるのですが、Partial（デフォルト）でデプロイしてください。
この 2 つの違いは、同じ Profile の一部の項目だけが新しく送信された場合の扱いです。
Partial では、新しく受信した項目だけを更新し、今回送信されなかった既存項目の値はそのまま保持されます。
一方、Incremental では、新しく受信した項目でレコードを更新しますが、今回送信されなかった項目は空白で更新される可能性があります。
例えば、すでに Profile に、
Customer ID：BOR501
Email Address：abc@gmail.com
First Name：Nobuyuki
が存在している状態で、次の Event では Email Address だけが送信されたとします。
Partial の場合は、
Customer ID：BOR501
Email Address：新しいメールアドレス
First Name：Nobuyuki
のように、送信されなかった既存項目を維持したまま更新できます。
そのため Salesforce も、Web サイトから取得する Profile Event では Partial の利用を推奨しています。
6. デプロイが開始されると、データストリームの作成が始まります。
ここで頭に付いている「nes-」とは、Website コネクタを作成したときに設定したエイリアスです。
エンゲージメントデータはすべて、Behavioral Events データストリームに格納されます。これは仕様です。
さて、ここからが今回の記事の本題です。
データマッピング
Data Stream を作成すると、Web Connector の Schema から Data Lake Object（DLO）が作成されます。
しかし、DLO にデータが入っただけでは、Marketing Cloud Next や Personalization から使いやすい Data 360 の標準データモデルにはまだなっていません。
そこで、DLO の各項目を Data Model Object（DMO）へ Mapping します。
Salesforce は Web SDK Connector 向けに推奨 Mapping を公開しています。今回の TrailNest でも、基本的にこの Mapping に合わせます。
① Identity → Individual DMO
まず、匿名ユーザーも含めた Web 訪問者の基本となる Identity です。
今回の Identity Schema では、deviceId がブラウザ単位の識別子として使用されています。
作成された identity DLO を開きます。
マッピングは次のようにします。すべて Individual DMO にマッピングです。
Engagement Date Time → Created Date
Individual ID → Individual ID（※自動的にマッピング）
First Name → First Name（※自動的にマッピング）
Last Name → Last Name（※自動的にマッピング）
Is Anonymous → Is Anonymous（※自動的にマッピング）
Salesforce の Web SDK Connector Mapping でも deviceId（Individual ID）を Individual の Primary Key として Mapping することが推奨されています。
deviceId は、そのブラウザを匿名ユーザーとして識別するための IDです。
Salesforce Interactions SDK は、ブラウザの first-party cookie に匿名識別子である anonymousId を保存し、Event を送信する際にはこの値を deviceId として使用します。
そのため、同じブラウザで Cookie が維持されている間は、Product View や Add to Cart などの行動を同じ匿名ユーザーの行動として関連付けることができます。
一方で、
Cookie を削除した場合
別のブラウザを利用した場合
別の端末を利用した場合
などは、新しい匿名 ID が発行されるため、deviceId も変わります。
つまり deviceId は、人そのものを永続的に識別する ID ではなく、「このブラウザ上の匿名ユーザー」を識別するための IDと考えると分かりやすいです。
その後、Email Address や Customer ID などの既知の識別子を取得し、Data 360 の Identity Resolution を利用することで、複数の匿名行動を同じ顧客 Profile に関連付けることができます。
deviceId が変わると、Data 360 では基本的に別の匿名 Profile として扱われます。古い deviceId の Profile に自動的に「使用終了」のマークが付くわけではありません。後から Email Address や Customer ID が取得されれば Identity Resolution によって既知 Profile と統合できますが、識別されないままの匿名 Profile は匿名 Profile として残ります。
そのため、Cookie 削除やブラウザ変更などによって匿名 Profile は増える可能性があります。
この時、ID 解決などを懸念するかもしれませんが、初回以降は基本的に新規・変更されたプロファイルが処理対象で、毎回すべてを再処理するわけではありません。もちろん、ルール変更などではフル再処理が発生する場合がありますが。
注意点としては、Data 360 Profiles ライセンスでは、anonymous unified profile も課金計算に関係します。現在の公式説明では、Identity Resolution を使う場合、known unified profiles に加えて anonymous unified profiles の 4% が billable profile 数に算入されます。
なお、Web SDK では deviceId という項目名で送信されますが、Salesforce が生成する Web Connector Schema では、この項目の表示ラベル（masterLabel）が Individual ID と定義されています。そのため Data Mapping の画面では deviceId ではなく Individual ID と表示されます。内部的な developerName は deviceId のままです。
② Contact Point Email →
Contact Point Email DMO
次に、Checkout で取得した Email Address を Mapping します。
作成された contactPointEmail の DLO を開きます。
Customer Confirm Email から送信した contactPointEmail は、Contact Point Email DMO にマッピングします。
Engagement Date Time → Created Date
Party → Contact Point Email ID
Party → Party（※自動的にマッピング）
Email Address → Email Address（※自動的にマッピング）
ここで重要なのは、Email Address そのものを Primary Key にしているわけではない点です。
Web SDK ではまず deviceId を軸として Profile Data を取得し、その後 Identity Resolution によって既存 Profile との統合を行います。
③ Party Identification →
Party Identification DMO
今回 TrailNest に Customer ID を追加した理由が、ここで効いてきます。
作成された partyIdentification DLO を開きます。
Customer Identification から送信した、
IDName
IDType
userId
を Party Identification DMO に Mapping します。
今回の Mapping は、以下の通りです。
Individual → Party Identification ID
Individual → Party
Engagement Date Time → Created Date
Identification Name → Identification Name（※自動的にマッピング）
Party Identification Type → Party Identification Type（※自動的にマッピング）
Identification Number → Identification Number（※自動的にマッピング）
注意点として、SDK Event では IDName ですが、今回生成された Schema / DLO の Developer Name は IDNameWeb です。
ただし、この時点で自動的に Profile が統合されるわけではありません。
実際に同一人物として統合するかどうかは、このあと設定する Identity Resolution の Match Rules によって決まります。
Behavioral Events の Mapping
続いて、Web サイト上の行動を Data 360 の DMO に Mapping します。
今回の TrailNest では、Behavioral Events の DLO から、次の 6 つの DMO を利用します。
まずは、Mapping 画面に、以下の 6 つの DMO を一度に追加してください。
Privacy Consent Log
Product Browse Engagement
Product Order Engagement
Sales Order Product Engagement
Shopping Cart Engagement
Shopping Cart Product Engagement
厄介な自動マッピングを整理する
DMO を追加すると、項目名などをもとに自動マッピングが適用されます。
ただし、Behavioral Events には Catalog、Cart、Cart Item、Order など複数種類の Event が含まれています。自動的につながった線をそのまま採用するのではなく、今回の TrailNest で使用する最終的な Mapping に整理します。
自動 Mapping は主に「DLO の Field Label と同じ名前のフィールドを自動でつなぐ補助的な提案機能」であって、Event セクションごとの意味まで完全に理解して正しい DMO だけへ Mapping しているわけではありません。また、名前が完全に一致していても、すべてが対象になるわけではありません。この紐づき方は、内部ロジックで制御されており公開されていません。
ここでは、All Event Data にある次の 3 種類の項目だけをまず接続します。
eventId → 各 DMO のプライマリーキーの項目
dateTime → 各 DMO の Engagement Date と Created Date の両方
※ Privacy Consent Log には Engagement Date がありませんdeviceId → 各 DMO の Individual（※ 自動マッピング済み）
なぜこの項目を接続するかと言えば、各 DMO 共通であることと、これらが紐づていれば、マッピング画面を「保存」できるからです。
それ以外の自動マッピングは、手動でコツコツと解除するわけですが、おそらく 10 分もあれば解除できると思います。解除のコツは一度でも保存をしてしまうと、1 つずつのマッピングを解除するのが重いので、保存前に全体削除してしまうことです。💡
ちなみに、最初から自動マッピングをさせない方法は存在しない認識ですが、どなたか知っているならコメントで教えて欲しいです。
ここで、一度「保存」をすることをオススメします。
さて、ここからは、Event の種類ごとに必要な項目を追加します。
④ Cart Event →
Shopping Cart Engagement DMO
まず、Cart セクションを設定します。ここでは、親となる Cart Event を Shopping Cart Engagement DMO に Mapping します。
※ 商品明細である Cart Item は、次の手順で別途設定します。
Cart セクションの項目を、次のように接続してください。
cart.interactionName → Shopping Cart Event Type
cart.pageView → マッピングしない
cart.sourceChannel → Engagement Channel
cart.sourceLocale → Device Locale
cart.sourcePageType → Webpage Type
cart.sourceUrl → Link URL
cart.sourceUrlReferrer → Referrer URL
eventType → Engagement Type
いずれも、接続先は Shopping Cart Engagement です。
特に eventType は、All Event Data にある共通項目ではなく、Cart セクションの eventType を選びます。
これで、Cart Event の基本的な Mapping ができました。
ここからは一つのイベントごとに「保存」していくことをオススメします。
⑤ Cart Item Event →
Shopping Cart Product Engagement DMO
続いて、Cart Item セクションを設定します。
Cart が「カートに追加した」という操作全体を表すのに対し、Cart Item は「どの商品を、いくつ追加したか」を表します。
Cart Item の項目を、Shopping Cart Product Engagement DMO に Mapping します。
cartItem.cartEventId → Shopping Cart Engagement
cartItem.catalogObjectId → Product
cartItem.catalogObjectType → マッピングしない
cartItem.currency → マッピングしない
cartItem.interactionName → マッピングしない
cartItem.pageView → マッピングしない
cartItem.price → Product Price
cartItem.quantity → Product Quantity
cartItem.sourceChannel → マッピングしない
cartItem.sourceLocale → マッピングしない
cartItem.sourcePageType → マッピングしない
cartItem.sourceUrl → マッピングしない
cartItem.sourceUrlReferrer → マッピングしない
eventType → Engagement Type
cartEventId には、親となる Cart Event の eventId が入ります。これにより、カート操作と商品明細を関連付けます。
今回の TrailNest では、商品 ID、数量、価格を Add to Cart の Line Item から取得しています。
また、catalogObjectType の値は TrailNest では Product です。これは Backpacks や Tents といった商品カテゴリ名ではありません。
これで、Cart と Cart Item を親子として扱うための Mapping ができました。
⑥ Catalog Event →
Product Browse Engagement DMO
次に、Catalog セクションを設定します。
TrailNest では Product Detail を表示すると Product View Event を送信します。Catalog セクションには、閲覧した商品の ID と、商品ページに関する情報が含まれます。
以下を Product Browse Engagement DMO に Mapping します。
catalog.attributeName → マッピングしない
catalog.attributePrice → Product Price
catalog.id → Product
catalog.interactionName → Engagement Channel Action
catalog.pageView → マッピングしない
catalog.sourceChannel → Engagement Channel
catalog.sourceLocale → Device Locale
catalog.sourcePageType → Webpage Type
catalog.sourceUrl → Product View URL
catalog.sourceUrlReferrer → Referrer URL
catalog.type → マッピングしない
eventType → Engagement Type
id には TrailNest の商品 ID が入ります。後ほど Goods Product の商品データを用意する際には、Web 行動側の Product と商品マスタ側の ID が対応するようにします。
また、attributePrice は、Sitemap Builder で Product View に追加した Price に対応する項目です。Product Browse Engagement DMO には数値型の Product Price が用意されています。
⑦ Consent Log Event →
Privacy Consent Log DMO
続いて、Consent Log セクションを設定します。
TrailNest の sitemap.js では Tracking に対する Opt-In の同意を設定しています。Consent Log には、その同意に関する情報が記録されます。
まず、次の項目を Privacy Consent Log DMO に Mapping します。
consentLog.interactionName → マッピングしない
consentLog.pageView → マッピングしない
consentLog.provider → マッピングしない
consentLog.purpose → Privacy Consent Log Category
consentLog.sourceChannel → マッピングしない
consentLog.sourceLocale → マッピングしない
consentLog.sourcePageType → マッピングしない
consentLog.sourceUrl → マッピングしない
consentLog.sourceUrlReferrer → マッピングしない
consentLog.status → Privacy Consent Status
eventType → Engagement Channel Type
Privacy Consent Log へのマッピングは同意情報を Data 360 に記録するための設定であり、Web SDK の送信可否を制御する設定ではありません。記録用です。purpose は何に対する同意か、status は Opt-In／Opt-Out の状態を表します。
⑧ Order Event →
Product Order Engagement DMO
次に、購入全体を表す Order セクションを設定します。
TrailNest では Order Confirmation の Page Load で Purchase Event を送信します。ここでは、注文 ID と注文全体の金額を Product Order Engagement DMO に Mapping します。
eventType → Engagement Type
order.interactionName → Product Order Event Type
order.orderCurrency → マッピングしない
order.orderId → Correlation ID
order.orderTotalValue → Total Product Amount
order.pageView → マッピングしない
order.sourceChannel → Engagement Channel
order.sourceLocale → Device Locale
order.sourcePageType → Webpage Type
order.sourceUrl → Link URL
order.sourceUrlReferrer → Referrer URL
orderId には TrailNest の注文 ID が入ります。今回は、注文 ID を後で照合できるよう、Salesforce Personalization の SDK 統合ガイドに掲載された Correlation ID への Mapping を採用します。
sourcePageType は、今回の Purchase Event が発生する Order Confirmation の Page Type を表します。
⑨ Order Item Event →
Sales Order Product Engagement DMO
最後に、購入商品の明細である Order Item セクションを設定します。
Order が注文全体、Order Item がその注文に含まれる個々の商品です。Order Item を Sales Order Product Engagement DMO に Mapping します。
eventType → Engagement Type
orderItem.catalogObjectId → Product
orderItem.catalogObjectType → マッピングしない
orderItem.currency → マッピングしない
orderItem.interactionName → マッピングしない
orderItem.orderEventId → ProductOrderEngagement（スペースなし）
orderItem.pageView → マッピングしない
orderItem.price → Unit Price Amount
orderItem.quantity → Ordered Quantity
orderItem.sourceChannel → マッピングしない
orderItem.sourceLocale → マッピングしない
orderItem.sourcePageType → マッピングしない
orderItem.sourceUrl → マッピングしない
orderItem.sourceUrlReferrer → マッピングしない
orderItem.totalPrice → Total Line Amount
orderEventId には親の Order Event の eventId が設定されます。そのため、複数の Order Item がどの Order に属するかを関連付けられます。
価格については注意が必要です。TrailNest の Line Item に渡している price は商品の単価です。また、生成済み Schema には price と totalPrice の両方が存在します。そのため、単価を Unit Price Amount、明細全体の金額を Total Line Amount として区別する構成にします。DMO の項目定義でも、Unit Price Amount は単価、Total Line Amount は明細金額として説明されています。
⑩ userEngagement Event →
Website Engagement DMO
最後に、userEngagement セクションを設定します。
TrailNest の Confirm Customer ボタンには、次の 2 つの Interaction を設定しました。
Customer Confirm Email
Customer Identification
ボタンをクリックすると、Email Address や Customer ID の Profile Data とともに、それぞれの Interaction を表す userEngagement Event も送信されます。
Profile Data は、先ほど設定した Contact Point Email と Party Identification に取り込みます。ここでは、ボタンをクリックしたという行動を Website Engagement DMO に Mapping します。
まず、Website Engagement DMO を Mapping 画面に追加します。
All Event Data の共通項目を追加
これまでの 6 つの DMO と同様に、Website Engagement にも All Event Data の共通項目を設定します。
eventId → Website Engagement ID
dateTime → Engagement Date Time
deviceId → Individual
eventId が主キー、dateTime が Event の日時、deviceId が訪問者との関連付けに使用されます。Website Engagement DMO にはこれらの接続先が用意されています。
userEngagement の項目を設定
続いて、userEngagement セクションの項目を、Website Engagement DMO に Mapping します。
eventType → Engagement Type
userEngagement.interactionName → Engagement Channel Action
userEngagement.pageView → マッピングしない
userEngagement.sourceChannel → Engagement Channel
userEngagement.sourceLocale → Device Locale
userEngagement.sourcePageType → Webpage Type
userEngagement.sourceUrl → Page URL
userEngagement.sourceUrlReferrer → Referrer URL
ここでも、eventType は All Event Data ではなく、userEngagement セクションにある項目を選びます。
残した共通項目について
ここまでで、最初に残した eventId、dateTime、deviceId に、各 Event セクションの項目を追加しました。
最後に、All Event Data の sessionId もマッピングしておきましょう。
All Event Data の sessionId は、自動マッピングの整理時にいったん解除しました。セッション単位で行動を確認したい場合は、ここで必要な DMO に接続し直します。
sessionId → Product Browse Engagement DMO の Session
sessionId → Product Order Engagement DMO の Session
sessionId → Sales Order Product Engagement DMO の Web Session
sessionId → Shopping Cart Engagement DMO の Session
sessionId → Shopping Cart Product Engagement DMO の Web Session
sessionId → Website Engagement DMO の Session
※ Privacy Consent Log DMOに対してはマッピング不要です。
※ このマッピングは、Web SDK Connector Mappings の例を参考にしており、なぜ Session / Web Session を使い分けているかは詳細がありません。
いかがでしたでしょうか。
今回は、Sitemap Builder で取得した Sitemap.js と Schema.json を Website Connector に登録し、Data Stream の作成と Data Mapping を行いました。
Web サイトから送信されたデータを Personalization で利用するには、各 Event の情報を、目的に合った DMO の項目へ正しく Mapping することが重要です。
自動 Mapping が設定されていても、そのままでよいとは限りません。今回のように、Event ごとの項目と All Event Data の共通項目を確認し、必要な接続を整理してください。
また、Salesforce の資料と実際の画面で項目名の表記が異なる場合もあります。名前だけで判断せず、その項目が何を表しているのかを確認しながら進めることが大切です。
ここまでで、TrailNest の Web 行動や Profile Data を、Data 360 のデータモデルへつなぐ設定ができました。
次回は、実際に TrailNest を操作して、DLO と DMO に想定したデータが取り込まれているかを確認していきます。
今回は以上です。
