メインコンテンツへスキップ
見出し画像
Photo bylisa500ml

【第593回】Personalization:CloudPages に Web SDK を設置する

    前回の記事では、Salesforce Personalization で利用する Website Connector に Sitemap.js と Schema.json を登録し、Data Stream の作成と Data Mapping を行いました。

    ここまでの検証では、Sitemap Builder の Inject 機能を使用して Web SDK と作成中の Sitemap を一時的に読み込んでいました。

    まだ TrailNest の CloudPages には Web SDK を設置していません。 第1回で保留にしていた Web サイトへの組み込みを、ここで行います。

    今回は CloudPages に Web SDK を設置し、Website Connector に登録した Sitemap で Event を送信できることを確認します。その後、Data 360 の DLO と DMO への取り込みを確認します。


    Personalization 基礎シリーズ

    Sitemap Builder シリーズ

    Data 360 設定シリーズ

    Personalization 設定シリーズ


    今回確認する流れ

    次の順番で確認します。

    1. Website Connector の Web SDK URL を取得する

    2. CloudPages の HTML に Web SDK の読み込みを追加し、公開する

    3. Inject を使用せず、登録済み Sitemap の動作を確認する

    4. TrailNest を操作し、Network で送信内容を確認する

    5. DLO と DMO への取り込みを確認する

    6. 注文と商品明細の関連付けを確認する


    ① CloudPages に Web SDK を設置する

    Website Connector の Script URL を取得する

    Salesforce の設定から Websites & Mobile Apps を開き、以前の記事で作成した TrailNest 用の Website Connector を開きます。

    Integration Guide の Add the Script to your source code に表示される Script URL をコピーします。

    画像

    これは、Sitemap Builder の Web SDK URL に指定した、Website Connector 専用の URL です。

    今回も、Schema と Sitemap を登録した同じ Website Connector の URL を使用します。


    CloudPages の HTML に Script を追加する

    Marketing Cloud Engagement の CloudPages で、公開中の TrailNest のページを開き、HTML のコードを編集します。

    既存コードを控えたうえで、<head> 内に Web SDK の読み込みを 1 つ追加します。公式の導入手順も、Website Connector の CDN URL を <script> タグで <head> 内に追加する方法を案内しています。

    <script src="https://cdn.c360a.salesforce.com/beacon/c360a/YOUR_CONNECTOR_ID/scripts/c360a.min.js"></script>

    今回の TrailNest では、Page Type の判定や商品情報の取得に HTML の要素を使用します。また、購入明細をページ末尾の JavaScript で生成しています。そのため、SDK の読み込みタグに defer を追加し、HTML の解析とこれらの処理が完了してから SDK と Sitemap が実行されるようにします。

    <script defer src="https://cdn.c360a.salesforce.com/beacon/c360a/db4dce08-43c3-406c-b901-1d0fc6a9e009/scripts/c360a.min.js"></script>

    実際のサイトでは、画面の生成方法に合わせて初期化タイミングを調整してください。このような微調整が実環境では必要です。

    今回の TrailNest は、1つの CloudPages のページを Query String で切り替えて表示しています。同じ HTML から各画面を生成する構成なので、その共通の <head> に追加します。</head> の直前で良いです。

    画像

    初期化処理は登録済みの Sitemap を使用する

    今回の Sitemap Builder が生成した sitemap.js には、すでに次の処理が含まれています。

    • SDK の初期化:SI.init(...)

    • Consent の設定

    • Page Type と Listener の定義

    • Sitemap の初期化:SI.initSitemap(sitemapConfig)

    ここでの SI は、生成されたコード内で取得している Salesforce Interactions SDK の参照です。

    Salesforce の Web SDK と Web サイトの Sitemap は CDN で一緒にホストされます。今回は前回 Website Connector に登録した Sitemap を利用します。

    CloudPages には SDK の読み込みを追加し、同じ sitemap.js の本文や、別の init() / initSitemap() を重ねて貼り付けないようにします。

    以前の記事で CloudPages への初期化処理の実装を保留にしたのは、この重複を避けるためでした。


    今回の Consent の設定

    今回の TrailNest は PoC のため、Tracking の同意を常に Opt-In として Web SDK に渡します。 利用者に同意を選択してもらう画面は設けず、この設定で Web 行動の取得を検証します。

    Sitemap Builder で生成し、前回 Website Connector に登録した sitemap.js には、すでに次の初期化設定が含まれています。

    SI.init({
      consents: new Promise(resolve => {
        resolve([{
          provider: "Consent Provider",
          purpose: SI.ConsentPurpose.Tracking,
          status: SI.ConsentStatus.OptIn
        }]);
      }),
      personalization: {
        dataspace: "default"
      }
    })

    ※ 上記は、登録済み sitemap.js の初期化部分の抜粋です。実際のファイルでは、この後の .then(...) 内で Page Type や Listener を定義し、Sitemap を初期化しています。

    この設定では、Promise がすぐに Opt-In を返す ため、同意ボタンの操作を待つことなく SDK に同意状態が渡されます。

    provider: "Consent Provider" は同意の提供元を表す識別名です。同意バナーを表示する設定ではありません。

    このコードを CloudPages に追加する必要はありません。 初期化と Consent の設定は登録済みの Sitemap に任せ、CloudPages には先ほどの Web SDK を読み込む <script src="..."> を追加します。

    今回の「常に Opt-In」は PoC の検証条件です。利用者の選択を取得する Web サイトへ展開する場合は、その選択を SDK に渡す処理へ変更します。


    CloudPages を公開する

    編集内容を保存し、CloudPages を公開します。

    確認には、公開済みの TrailNest の URL を使用します。

    Sitemap Builder の Inject を停止し、公開した TrailNest を再読み込みします。

    画像

    Browser の Developer Tools を開き、Network タブで、追加した Web SDK が読み込まれているかを確認します。Console に JavaScript エラーがないかも確認してください。

    画像

    ページ遷移後も Request を確認できるよう、必要に応じて Keep log を有効にします。

    SDK の読み込みが確認できたら、商品詳細を表示し、Product View に対応する Event Request が送信されるか確認します。

    今回の一連の検証は同じ Browser で行い、途中で Cookie を削除しないようにします。別の Browser を使用したり Cookie を削除したりした場合の動作は、後ほど Identity Resolution を検証する際に確認します。


    ② 検証用の操作を行う

    今回の検証では、あとからデータを探しやすいように、専用の Customer ID と Email Address を使用します。

    例えば、次のような検証用の値を用意します。

    • Customer ID:POC-011-001

    • Email Address:trailnest.poc011@example.com

    次の順番で TrailNest を操作します。

    1. 商品詳細を表示する

    2. Add to Cart をクリックする

    3. 2 つ目の別の商品も Cart に追加する。

    4. Checkout を表示する。2 つ目の商品を数量 2 にする

    5. Customer ID と Email Address を入力する

    6. Confirm Customer をクリックする

    7. Place Order をクリックする

    画像

    8. Order Confirmation を確認する

    画像

    商品ごとの ID・商品名・単価・数量と、購入完了時の Order ID・Total Value を控えておきます。

    商品 1 の詳細
    ID:TN-BP-001
    商品名:Alpine Daypack 18L
    単価:79,000 yen
    数量:1

    商品 2 の詳細
    ID:TN-BP-005
    商品名:Expedition Pack 60L
    単価:229,000 yen
    数量:2

    合計
    Order ID:TN-1790635258855
    Total Value:537,000 yen

    まずはこの通常の購入を 1 回行い、Order Confirmation の再読み込みは避けます。現在の Sitemap では、このページの表示時に Purchase を送信する設定になっているためです。


    ③ Request の識別子を控える

    Order Confirmation の画面の状態で、Network から一番下にある Event Request の Payload を確認します。

    画像

    これは Base64 形式のため、フリーサイトなどでデコードしてください。すると以下のような JSON 形式になります。

    {
      "events": [
        {
          "eventId": "55c761c7-422c-4cb3-905c-de3be2fc9cab",
          "dateTime": "2026-09-28T22:40:59.900Z",
          "sessionId": "557d0d50dc471e3b",
          "deviceId": "557d0d50dc471e3b",
          "interactionName": "Purchase",
          "pageView": 1,
          "sourceUrl": "https://mcxkknz3m0zj3jqsxn4hm3dp3q-4.pub.sfmc-content.com/f0sn3uhu0p0?view=order_confirmation",
          "sourceUrlReferrer": "https://mcxkknz3m0zj3jqsxn4hm3dp3q-4.pub.sfmc-content.com/f0sn3uhu0p0?view=checkout",
          "sourceChannel": "Web",
          "sourcePageType": "Order Confirmation",
          "category": "Engagement",
          "eventType": "order",
          "orderId": "TN-1790635258855",
          "orderTotalValue": 537000
        },
        {
          "eventId": "903ba5f7-697a-4311-8ea2-02241531fa37",
          "category": "Engagement",
          "dateTime": "2026-09-28T22:40:59.900Z",
          "deviceId": "557d0d50dc471e3b",
          "sessionId": "557d0d50dc471e3b",
          "eventType": "orderItem",
          "interactionName": "Purchase",
          "catalogObjectType": "Product",
          "catalogObjectId": "TN-BP-001",
          "price": 79000,
          "quantity": 1,
          "orderEventId": "55c761c7-422c-4cb3-905c-de3be2fc9cab"
        },
        {
          "eventId": "2df4355c-4f39-402b-85a9-f111e06a9b6e",
          "category": "Engagement",
          "dateTime": "2026-09-28T22:40:59.900Z",
          "deviceId": "557d0d50dc471e3b",
          "sessionId": "557d0d50dc471e3b",
          "eventType": "orderItem",
          "interactionName": "Purchase",
          "catalogObjectType": "Product",
          "catalogObjectId": "TN-BP-005",
          "price": 229000,
          "quantity": 2,
          "orderEventId": "55c761c7-422c-4cb3-905c-de3be2fc9cab"
        }
      ]
    }

    例えばオーダーのイベントには、上で控えた商品情報の他に、以下のようなものが格納されています。

    • deviceId(SessionId):今回の Browser を識別する値(匿名 ID)

    • eventId:個々の Event を識別する値

    • eventType:catalog、cart、order などの Event の種類

    • dateTime:Event の日時

    • orderEventId:Order Item が参照する親の Order Event の ID

    このあと Data 360 では、これらの値を使って今回の検証データを探します。


    ④ Data Stream の取り込みを待つ

    Data 360 の Data Streams タブを開き、TrailNest の Data Stream にエラーがないことを確認します。

    Web サイトから送信したデータは、Data Explorer にすぐ表示されるとは限りません。但し、表示が 0 のままであっても、データエクスプローラーなどで DLO / DMO を確認すると、データが入っている場合があります。


    ⑤ 購入データを確認する

    Data 360 のデータエクスプローラーを開きます。

    まず、次の内容を選択します。

    • Object Type:Data Lake Object

    • Object:TrailNest の Behavioral Events に対応する DLO

    Network で控えた orderId(TN-1790635258855)を使い、今回の注文を探します。

    注文が見つかり、orderTotalValue が 537000 になっていれば、送信した注文データが DLO に取り込まれたことを確認できます。

    画像

    続いて、Object Type を Data Model Object に切り替え、Product Order Engagement を開きます。

    Correlation ID に同じ注文 ID(TN-1790635258855)が入っているレコードを探します。

    画像

    これで、Web サイトから送信した注文が、DLO を経由して DMO にマッピングされたことを確認できました。

    最後に、Sales Order Product Engagement を開きます。

    ProductOrderEngagement が、親の Product Order Engagement ID と一致する明細を探します。

    これは親の event ID(55c761c7-422c-4cb3-905c-de3be2fc9cab)を子となる Sales Order Product Engagement の ProductOrderEngagement という親の eventId を参照している項目でしっかり持っているかの確認です。

    画像

    今回の例では、次の2件が確認できればよいです。

    • TN-BP-001:数量1

    • TN-BP-005:数量2

    画像

    ⑥ Email Address / Customer ID を確認する

    続いて、Data Model Object の Contact Point Email を開きます。

    Checkout で入力した Email Address(trailnest.poc011@example.com)を探し、Party に今回の deviceId(557d0d50dc471e3b)が入っていることを確認します。

    画像

    同じように Party Identification を開きます。

    Party に対象の deviceId(557d0d50dc471e3b)が入っていることを確認します。

    また、以下は ID 解決で使用するので 3 点セットで必要なので確認します。

    • Party Identification Type:Customer ID

    • Identification Name:TrailNest Customer ID

    • Identification Number:POC-011-001

    画像

    これで、Email Address と Customer ID が、今回のブラウザに対応する情報として取り込まれたことを確認できました。


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

    今回は、これまで Inject で検証していた Web SDK を TrailNest の CloudPages に設置し、登録した Sitemap の動作と Data 360 の DLO・DMO への取り込みを確認する手順を紹介しました。

    Data Mapping は設定を保存して終わりではありません。送信した値が意図した DMO の項目へ入り、注文と商品明細のような関連付けまで正しくできているかを確認することが重要です。

    次回は ID 解決を設定し、Email Address と TrailNest Customer ID を使用して、Profile がどのように同一人物として関連付けられるのかを確認していきます。

    今回は以上です。


    次の記事はこちら

    前回の記事はこちら

    私の note のトップページはこちら

     
     
    Salesforce Marketing Cloud、Agentforce、Data Cloud、Salesforce 認定資格に関する実践的な情報を発信しています。これらの記事が、皆さまの学習や日々の業務に少しでもお役に立てば幸いです。