Adobe Commerce をトランザクションエンドポイントからリアルタイムのプラットフォームシグナルに昇格させ、コマースデータを Adobe Experience Platform に直接接続することで、調整された ID 駆動型のエクスペリエンスを実現する方法について説明します。

サイロを打破：コマースの未来がプラットフォーム型である理由

歴史的に、ストアフロントは認知から購入までのリニアなジャーニーでの最終目的地、つまり終着点でした。ただし、カスタマージャーニーがデバイス、ソーシャルプラットフォーム、オフラインのタッチポイントへと分散するにつれ、リニアファネルでは対応不可能な状態になっています。

現代のマーチャントにとって、ストアフロントはもはや単なるトランザクションを行う場所ではなく、Adobe Experience Cloud エコシステムでの最も重要なセンサーです。この時代に成功するには、Adobe Commerce を孤立した存在としてではなく、Adobe Experience Platform（AEP）の心臓部として処理する必要があります。

多くのブランドは、遅延パーソナライゼーションに悩まされています。顧客が火曜日に靴を購入すると、その後 2 週間、同じ靴の広告やメールに悩まされることになります。これは、多くの場合、コマースデータがサイロにトラップされ、数時間または数日前のバッチ更新によって同期されるからです。

Adobe Commerce を AEP と統合すると、リアクティブコマース（顧客が行った行動に対応）から予測的オーケストレーション（現在の顧客に応じて対応）に移行します。

コマースパルス

ストアフロントをリアルタイムのシグナルジェネレーターに変えるには、インジェスト、ステッチ、アクティベートという 3 つの柱からなるフレームワークに焦点を当てます。

1. Adobe Client Data Layer（ACDL）を使用することは、AEP に購入イベントを送信するだけではありません。次の購入意向の高いシグナルをストリーミングします。

• 製品の表示と比較

• 買い物かごへの追加／削除

• ストアフロントの検索用語

2. 統合プロファイルのステッチ - 顧客が輸送の遅延についてサポートラインに電話をかけてきたと想像してみてください。このサービスに対するネガティブなシグナルは、即座に顧客のプロファイルにステッチされます。次に Adobe Commerce ストアフロントに訪問した際は、「さらに購入」のヒーローバナーではなく、「ご注文の更新に取り組んでいます」というメッセージが表示されます。これは真のエクスペリエンス管理の一例です。

サイロ化されたストアフロントから統合プロファイルへのトランジションには、ID の正確なオーケストレーションが必要です。

• コマースユーザーをサポートまたはマーケティングペルソナにリンクする「キー」を定義します。AEP では、これは ID サービスを通じて行われます。

  • プライマリ ID：通常はメールアドレスまたは ECID（Experience Cloud ID）。
  • セカンダリ ID：CRM ID（Adobe Commerce から取得）または電話番号（サポートセンターから取得）。
  • ステッチロジック：顧客がストアフロントにログインすると、Adobe Commerce は CRM ID を渡します。同じ顧客がサポートに電話してメールアドレスを伝えると、AEP の ID グラフによってこれら 2 つの異なる ID が 1 つの XID にリンクされます。

• XDM スキーマのアラインメント

  • コマース側：Adobe Commerce イベント（買い物かごに追加、購入）を、コマースの詳細フィールドグループを使用してエクスペリエンスイベントクラスにマッピングします。
  • サポート側：「ケースステータス」属性を含む既存のフィールドグループ（例：カスタマーサービス呼び出しの詳細）を作成または使用します。
  • ブリッジ：両方のスキーマがプロファイルに対して有効になっていることを確認します。これにより、属性がデータレイクに蓄積されるのではなく、リアルタイム顧客プロファイルに直接書き込まれます。

• リアルタイム結合ポリシーの設定 - ユーザーはシステム間で異なる住所や電話番号を持っている可能性があります。統合プロファイルを作成する際に、「勝利」させるデータを決定する結合ポリシーを定義する必要があります。

  • タイムスタンプ順：最新のインタラクション（例：今日の「輸送の遅延」ステータス）が古いデータよりも優先されます。

  • ソースの優先度：AEP に、「ケースステータス」についてはサポートシステム（Service Cloud）を、「輸送先住所」については Adobe Commerce を信頼するように指示します。

• ネガティブシグナルをアクティベートしてコマースに戻る

  • セグメント作成：AEP で オープンサポートケースを持つ顧客 というストリーミングセグメントを作成します。

  • Edge Delivery：顧客が Adobe Commerce ストアフロントにアクセスすると、AEP Web SDK がプロファイルをリクエストします。

  • オファー決定支援：ユーザーは「オープンサポートケース」セグメントのメンバーになったので、オファー決定支援サービス（ODS）または Adobe Target がヒーローバナーリクエストをインターセプトし、プロモーションコンポーネントではなく「注文の更新」コンポーネントを提供します。

3. ループを閉じる - アクティベーションはメールだけではありません。AEP を使用すると、Adobe Commerce のデータを Target または Adobe Journey Optimizer（AJO）経由でストアフロントにアクティベートして戻すことができます。

• 動的な価格設定とオファー：AEP プロファイルでオフラインまたはアプリ経由で購入したことがないことが確認された顧客にのみ「初回購入者」ディスカウントを表示します。

• 一貫性のあるクロスチャネルストーリーテリング：ユーザーがマーケティングメール内の「サステナビリティ」リンクをクリックすると、Commerce ホームページでは環境に配慮した製品コレクションが自動的に優先表示されます。

• 放棄された購入意思の復元：ユーザーがモバイルデバイスで高額品目を買い物かごに追加したが、チェックアウトしなかった場合、ストアフロントはユーザーがデスクトップ経由で戻った瞬間に反応することがあります。一般的なウェルカムメッセージの代わりに、その品目に固有の CTA を備えた「中断した場所をすぐに再開」モジュールをホームページに表示することで、デバイス間でフリクションなく維持されるコマースジャーニーが確保されます。

回避すべき落とし穴

統合されたプラットフォーム型のコマースモデルへの移行は大きなメリットをもたらしますが、同時に複雑さも伴い、慎重に管理しないとエクスペリエンスが損なわれる場合があります。ここでは、AEP と Adobe Commerce の統合時に見うけられる、最も一般的な 4 つの落とし穴について説明します。

共有デバイス ID による落とし穴

多くの家庭では、複数の人物が同じタブレットやラップトップを使用してストアを閲覧しています。ID グラフの設定が強すぎる場合（例：すべての ECID を最後にログインしたメールアドレスにステッチ）、2 人の異なる人物のプロファイルが結合されてしまうリスクがあります。

• 結果：夫が妻の誕生日プレゼントのお勧めを見てしまったり、さらに、夫と妻のサポートチケットや個人の好みが 1 つのフランケンシュタインプロファイルに統合される場合があります。

• 修正：プライベートグラフを使用し、確率的マッチングは保守的に行います。高価値なステッチ（デバイスとユーザーをリンク）は、ログインやチェックアウトなど、認証済みイベント中にのみ行われるようにします。

過剰な取り込み

Adobe Commerce から 1 回のクリックやポインタを合わせるなど、マイクロインタラクションをすべて AEP に送りたくなる衝動に駆られます。

• 結果：これにより、「ノイズ」が発生し、セグメント計算を遅らせ、AEP のストレージコストを増大させます。さらに重要なのは、XDM スキーマが管理不能になることです。

• 修正：「シグナルからアクションへ」ルールに従います。データの一部が 30 日以内に特定のセグメント変更やパーソナライズされたエクスペリエンスをトリガーしない場合は、リアルタイムプロファイルではなく、分析レイヤー（Adobe Analytics）に保持します。

結合ポリシーのパラドックス

結合ポリシーで明確な信頼できる情報源が定義されていません。

• 結果：Adobe Commerce では顧客がレベル：ゴールドと表示されているのに、レガシー CRM からアップロードされた古い CSV ではレベル：シルバーと表示されている場合、AEP は最後に更新されたレコードに応じてユーザーのステータスを反転させる可能性があります。

• 修正：ソース優先度結合ポリシーを実装します。トランザクションデータについては Adobe Commerce が権限を持ち、コミュニケーション環境設定については ESP またはプライバシーツールが権限を持つことを AEP に明示的に伝えます。

「Edge」の待ち時間の無視

ページ読み込みの瞬間に「重労働」（複雑な計算）を実行しようとします。

• 結果：ストアフロントがヒーローバナーをレンダリングする前に、AEP への複雑でマルチステップの API 呼び出しを待たなければならない場合、コア web バイタルが急落し、SEO とユーザーエクスペリエンスに悪影響を与えることがあります。

• 修正：Adobe Experience Platform Web SDK と Edge セグメントを活用します。セグメント化ロジックを Adobe Edge Network（ユーザーに近い場所）に移動することで、ページのレンダリングをブロックすることなく、100ミリ秒未満でパーソナライゼーションを実現できます。

AEP と Commerce の目標は、単にデータを収集するだけでなく、大規模な関連性を作成することです。これらの一般的な落とし穴を回避し、クリーンな ID ステッチに焦点を当てることで、ストアフロントを静的なカタログから、カスタマージャーニーを生き生きと拡張する存在へと変革します。

その他の学習リソース

• Adobe Experience Platform と顧客プロファイルについて詳しくは、リアルタイム顧客プロファイルの概要およびリアルタイム顧客データプラットフォームの ID を参照してください。

• Commerce データの接続について詳しくは、Adobe Experience Platform への Commerce データの接続および Adobe Commerce のソースコネクタガイドを参照してください。

• ジャーニーの最適化とパーソナライゼーションについて詳しくは、パーソナライゼーションのユースケース：注文ステータス通知を参照してください。

• Adobe Commerce と Adobe Journey Optimizer の接続について詳しくは、Adobe Commerce と Adobe Journey Optimizer の統合を参照してください。