【第590回】Personalization：Sitemap Builder で Debug を確認する
前回の記事では、Salesforce Personalization の Sitemap Builder で Schema を確認しました。
現在の Sitemap Builder には、作成した Sitemap を実際の Web サイトへ Deploy する前に動作確認できる Debug も用意されています。
設定内容が正しく見えていても、実際に Web サイトを操作したときに Event が送信されているかは確認する必要があります。
そこで今回は、Sitemap Builder の Debug を使用して、TrailNest から送信される Event を確認します。
Personalization 基礎シリーズ
Sitemap Builder シリーズ
Data 360 設定シリーズ
Personalization 設定シリーズ
Debug を開く
Sitemap Builder 上部の Debug をクリックします。
Debug には、
Event Monitor
Decision Monitor
の 2 つがあります。
今回は、Event Monitor を使用します。
Event Monitor
Event Monitor は、Web サイトから Salesforce に送信される Event Request を確認するための機能 です。
今回の TrailNest では、
Product View
Add to Cart
Customer Confirm Email
Customer Identification
Purchase
が想定どおり送信されているか確認します。
Sitemap は Web サイト上のページ表示やユーザー操作を検知し、Salesforce Interactions SDK から Event Request を送信します。
Monitoring を開始
Start Monitoring をクリックします。
Status が、「Monitoring Active」になっていれば準備完了です。
もし一切のログが表示されない場合は、同意が Opt-Out している可能性があります。F12 でコンソールを開き SalesforceInteractions.getConsents() を入力してください。ここで Opt-Out している場合は、一度インジェクションを停止して、再設定してください。再設定直後、コンソールで Opt-In になることを確認してください。
また Resolver における Custom JavaScript を見直してください。こちらもコンソールからエラー情報を取得してください。
① Product View を確認
まず TrailNest の Product Detail を表示します。
今回 Product Detail には、
On Page Load Interaction：Product View
を設定しています。
そのため、
Product Detail を表示したときに
↓
Product View Event を送信
となることを確認します。
Product View では、
Product ID
Product Name
Product Price
を取得するように設定しました。
Request Log から、Product View に対応する Event Request が送信されていることを確認します。
② Add to Cart を確認
続いて、Product Detail の Add to Cart をクリックします。
今回の Sitemap では、
listener("click", "#add-to-cart", () => {
sendEvent(...)
})を設定しています。
そのため、
Add to Cart をクリックしたときに
↓
Add to Cart Event を送信
となります。
Request Log に新しい Request が追加されることを確認します。
今回の Add to Cart には、
Product ID
Quantity
Price
が Line Item として含まれます。
③ Customer Confirm Email / Customer Identification を確認
続いて Checkout を表示します。
今回の Checkout では、
Customer ID
Email Address
を入力したあと、Confirm Customer ボタンをクリックして内容を確定する流れにしています。
Sitemap Builder では、この Confirm Customer ボタンに対して 2 つの Listener を設定しています。
1 つ目は、
Confirm Customer
→ Customer Confirm Email
です。
Customer Confirm Email では、
Interaction：Customer Confirm Email
Profile Data：Contact Point Email
を送信します。
2 つ目は、
Confirm Customer
→ Customer Identification
です。
Customer Identification では、
Interaction：Customer Identification
Profile Data：Party Identification
を送信します。
Checkout に検証用の Customer ID と Email Address を入力して、Confirm Customer をクリックします。
Request Log を確認すると、1 回の Confirm Customer のクリックから、2 つの Listener が実行され、それぞれの Event Request が送信されていることを確認できます。
Customer Confirm Email を確認
Customer Confirm Email の Request では、Profile Event として、
eventType：contactPointEmail
email：入力した Email Address
category：Profile
が送信されていることを確認します。
また、同じ Request には Engagement Event として、
interactionName：Customer Confirm Email
eventType：userEngagement
category：Engagement
も含まれます。
Salesforce Interactions SDK では、1 回の Event に Interaction と User Data の両方を含めることができ、Data 360 側ではそれぞれ対応する Event として処理されます。
Customer Identification を確認
続いて Customer Identification の Request を確認します。
Profile Event では、
eventType：partyIdentification
IDName：TrailNest Customer ID
IDType：Customer ID
userId：入力した Customer ID
category：Profile
が送信されていることを確認します。
partyIdentification では、user.attributes.eventType に partyIdentification を指定することで、Party Identification 用の Profile Event として送信されます。
後ほど Data 360 では、
IDName → Identification Name
IDType → Party Identification Type
userId → Identification Number
として Mapping します。
今回取得しているのは Confirm Customer のクリック
ここで注意しておきますと、今回 Listener で監視しているのは、Confirm Customer ボタンがクリックされたこと です。
TrailNest 側では、Customer ID が空欄の場合や、Email Address が正しい形式でない場合には Confirm Customer を実行できないようにしています。
また、Confirm Customer 後に Customer ID または Email Address を変更した場合は確認状態を解除し、再度 Confirm Customer を実行する必要があります。
今回の TrailNest では、
Customer ID / Email Address を入力
↓
Confirm Customer
↓
Customer Confirm Email / Customer Identification
↓
Place Order
↓
Order Confirmation / Purchase
という流れにしています。
なお、Confirm Customer は入力された Customer ID や Email Address が実際にそのユーザー本人のものであることを認証する機能ではありません。
実案件では、ログイン情報、CRM や Commerce が管理する Customer ID、Email Verification など、Web サイト側の Identity 設計に合わせて Profile Data を取得するタイミングや識別子を設計する必要があります。
④ Purchase を確認
Place Order の処理が完了すると、TrailNest は Order Confirmation を表示します。
Order Confirmation には、
On Page Load Interaction：Purchase
を設定しています。
そのため、
Order Confirmation を表示したときに
↓
Purchase Event を送信
となります。
今回の Purchase では、
Order ID
Total Value
Line Items
を取得しています。
Request Log に Purchase の Request が追加され、想定した Order ID や Total Value が送信されていることを確認します。
さらに Line Items では、購入した商品ごとに、
catalogObjectId
price
quantity
が含まれていることを確認します。
すると、Line Items では、購入した商品ごとに Order Item Event が生成されていることが確認できます。
今回の例では、
TN-BP-001
price：79000
quantity：1
TN-BP-002
price：109000
quantity：1
という 2 件の Order Item Event が生成されています。
それぞれの Event には、
eventType：orderItem
catalogObjectType：Product
catalogObjectId
price
quantity
orderEventId
が含まれています。
また、2 件の Order Item Event には同じ orderEventId が設定されています。
この orderEventId によって、それぞれの商品明細がどの Order Event（親）に属しているのかを関連付けることができます。
再読み込みによる Purchase の重複にも注意
今回の TrailNest では、Order Confirmation の Page Load を Purchase の発火条件にしています。
そのため Order Confirmation を F5 などで再読み込みすると、Purchase がもう一度送信されます。
今回の検証では Sitemap Builder の動作を確認するため、この構成を使用していますが、実案件では同じ Order を重複して送信しないよう、Application Event や Data Layer、Order ID を利用した重複防止などを検討する必要があります。
Decision Monitor とは
Debug にはもう 1 つ、Decision Monitor があります。
Decision Monitor は、Personalization の Decision API に送信される Request を確認するための機能です。
例えば今後、
Personalized Content
Recommendation
Personalization Point
などを Web サイトへ表示する際には、ユーザーに何を表示するかを Salesforce に問い合わせる Request が発生します。
Salesforce Interactions SDK では、Personalization Point を指定して Decision API に Personalization を Request できます。
今回の TrailNest では、まだ Personalization の表示処理は設定していないので、今回は Decision Monitor は使用しません。
今後 Recommendation や Web Personalization を設定する際に確認します。
Sitemap Builder だけで検証を終わらせない
Debug は Sitemap の設定中には非常に便利ですが、実装後には実際の Web サイトでも Event が正しく送信されることを確認することが重要です。
Salesforce も、Sitemap Editor は Web ページが読み込まれた後に Sitemap を初期化するため、本番と同じ Page Load Timing を完全には再現できないと説明しています。
そのため実案件では、
Browser の Developer Tools
Network Request
Personalization の Event Stream
なども利用して、実際に Deploy された環境で Event を確認してください。
今回は Sitemap Builder の設定段階なので、まず Debug の Event Monitor を利用して動作を確認します。
いかがでしたでしょうか。
今回の Debug では、Engagement Event だけでなく、
Contact Point Email
Party Identification
Order Item
といった Profile Data や商品明細についても、想定した内容が送信されていることを確認しました。
Sitemap Builder では設定画面上で正しく見えているだけでなく、実際の操作によって想定した Event が送信されることまで確認することが重要です。
次回は Review & Download を使用して、ここまで作成した Sitemap と Schema を確認し、実際に利用するためのファイルを取得していきます。
今回は以上です。
