イベントトリガーメッセージ
このガイドでは、Adobe Journey Optimizer （AJO）、Real-Time Customer Data Platform （RT-CDP）、Adobe Experience Platform （AEP）を使用したイベントトリガーメッセージの包括的な実装の設計図を提供します。 これは、行動イベントやシステムイベントに応じて、コンテキストに即したリアルタイムのメッセージを配信する必要があるソリューションアーキテクト、マーケティングテクノロジスト、実装エンジニア向けに設計されています。
このガイドでは、設定すべき内容、実装の選択肢の場所、それぞれの決定を左右するトレードオフについて説明します。
このガイドでは、イベントの取り込みから、メッセージ配信とパフォーマンスレポートによるジャーニー作成までのライフサイクル全体をカバーし、3つの実装オプションに関する詳細な意思決定ガイダンスを提供します。
ユースケースの概要
イベントトリガーメッセージは、リアルタイムの行動イベントやシステムイベントに応じて、コンテクストに即したメッセージを配信します。 バッチ方式のアウトバウンドメッセージのアクティベーションでは、事前に評価されたオーディエンスにスケジュールどおりに送信しますが、このパターンでは、カート放棄、閲覧セッション、フォーム送信、システムステータスの変更など、条件が適用されるイベントをリッスンして、条件を評価してメッセージを配信するジャーニーにすぐにトリガープロファイルを入力します。
このパターンは、AEPへのリアルタイムのイベントストリーミング（Web SDK、モバイルSDK、サーバーサイド API経由）、AJOの単一イベントエントリを含むジャーニー、送信するかどうか、何を送信するかを決定する条件評価ロジックに依存しています。 メッセージは通常、トリガーイベントから数分以内に送信されるため、このパターンは、時間的制約があり、コンテキストに関連性の高いコミュニケーションに最適です。
企業はこのパターンを利用して、顧客の行動にリアルタイムで対応できるため、スケジュール型のバッチコミュニケーションと比較して、関連性が高まり、エンゲージメントとコンバージョン率が向上します。 一般的なシナリオには、カート放棄からの復旧、購入後のフォローアップ、登録後のウェルカムメッセージ、支払い失敗や価格低下のアラートなどの時間的制約を受ける通知などがあります。
主なビジネス目標
このユースケースパターンでは、次のビジネス目標をサポートしています。
タイムリーでパーソナライズされたフォローアップにより、購入、申し込み、登録のフローの途中で離脱したユーザーをリエンゲージできます。
購入、サインアップ、フォーム送信など、望ましいアクションを実行した訪問者と見込み顧客の割合を向上させます。
個人の好み、行動、ライフサイクルのステージに合わせて、コンテンツ、オファー、メッセージを調整。
合理化され、パーソナライズされたウェルカムエクスペリエンスとアクティベーションジャーニーにより、新規顧客の価値創出までの時間を短縮できます。
戦術的なユースケース
次のシナリオは、イベントトリガーメッセージを様々なビジネスコンテキストに適用する方法を示しています。
- カート放棄メールまたはSMS – 顧客がカートに商品を追加したものの、定義された時間枠内に購入を完了しなかった場合にリマインダーメッセージを送信する
- 放棄のフォローアップを参照 – 製品またはコンテンツを閲覧したものの、コンバージョンのアクションを起こさなかった訪問者をリエンゲージします
- 購入後のお礼またはクロスセル – 購入イベントの直後に、確認とクロスセルのレコメンデーションを配信します
- 体験版の有効期限に関するリマインダー – 更新またはコンバージョンメッセージを使用して、無料体験版の終了を迫っているユーザーに通知します
- 登録後のウェルカムメッセージ – 新しいユーザーがアカウントを登録または作成すると、すぐにオンボーディングメッセージを送信します
- フォーム送信確認 — コンテキスト確認を使用して、フォーム送信（問い合わせリクエスト、アプリケーション、登録）を確認します
- 支払い失敗の通知 – 定期的な支払いが失敗したときに顧客に通知し、支払い情報を更新するよう促します
- App uninstall win-back push notification — ユーザーがモバイルアプリケーションをアンインストールすると、win-back メッセージがトリガーされる
- 予約または予約の確認 – 予約、予約、または予約がスケジュールされた後、すぐに確認を送信します
- ウィッシュリストに登録された商品の値下げアラート – ウィッシュリストに登録されている商品の値下げを顧客に通知します
主要業績評価指標
次のKPIは、イベントをトリガーとしたメッセージ実装の効果を測定するのに役立ちます。
ユースケースパターン
この節では、イベントトリガーメッセージを駆動するコアパターンとファンクションチェーンについて説明します。
イベントトリガーメッセージ
リアルタイムの行動イベントやシステムイベントをリッスンし、トリガープロファイルにコンテクストに即したメッセージを配信します。
関数チェーン： イベント取り込み> ジャーニーエントリ >条件評価> メッセージ配信> レポート
アプリケーション
このユースケースパターンでは、次のAdobe アプリケーションを使用します。
- Adobe Journey Optimizer（AJO） – 単一イベント入力、条件評価、待機手順、メッセージのオーサリング、チャネル設定、頻度ガバナンス、配信レポートを使用したジャーニーオーケストレーション
- Adobe Real-Time Customer Data Platform（RT-CDP） — ジャーニー内の条件ベースのフィルタリング、同意とガバナンスの適用、プロファイルの強化のオーディエンス評価
- Adobe Experience Platform（AEP） — Web SDK、モバイル SDK、またはサーバーサイド APIを介したリアルタイムのイベント取り込み、データモデリング、ID解決、Edge Network
基本関数
このユースケースパターンでは、次の基本機能を使用する必要があります。 各機能について、ステータスは、通常それが必要か、事前設定が想定されているか、適用できないかを示します。
commerce.productListAdds）を含むトリガーイベントを取得する必要があります。 リアルタイム顧客プロファイルのスキーマを有効にする必要があります。 対応するデータセットを作成し、プロファイルを有効にする必要があります。サポート機能
次の機能は、このユースケースパターンを強化しますが、コア実行には必要ありません。
アプリケーション関数
この計画では、アプリケーション機能カタログから次の機能を実行します。 関数は、番号付きのステップではなく実装フェーズにマッピングされます。
Journey Optimizer （AJO）
Real-Time CDP （RT-CDP）
前提条件
実装を開始する前に、以下を完了してください。
- [ ジャーニーの作成と公開の権限を持つ]個のAJO サンドボックスがプロビジョニングされました（F1）
- [ コンテキスト フィールドを使用してトリガーイベントをキャプチャする] XDM ExperienceEvent スキーマ。リアルタイム顧客プロファイル（F2）で有効
- [ ] Web SDK、モバイルSDK、またはEdge Network Server APIを介して、データストリームのルーティングイベントを正しいAEP データセット（F3）に設定したリアルタイムイベントストリーミング
- [ トリガーイベントの識別子に設定された]個のID名前空間。ID リンク ルールが設定されています（F4）
- [ ] チャネル サーフェス （電子メール、SMS、またはプッシュ）が設定され、テスト送信が成功しました
- [ ] サンプルプロファイルを使用して作成、レビュー、テストされたメッセージコンテンツ
- [ ターゲットチャネルのプロファイルに]の同意フィールドが入力されました（例：
consents.marketing.email.val） - [ ]条件ベースのオーディエンスフィルタリング（オプション B/C）を使用する場合、ストリーミング評価されたオーディエンスセグメントが定義され、アクティブに評価されます
実装オプション
この節では、イベントトリガーメッセージの3つの実装オプションについて説明します。 各オプションは、前のオプションに基づいて構築され、追加の機能が追加されます。
オプション A：シンプルなイベントトリガーメッセージ
遅延や条件付きロジックが必要ない、即時の単一メッセージの応答（注文確認、ウェルカムメール、フォーム送信の確認、予約確認）に最適です。
仕組み：
ジャーニーは、単一イベントエントリノードを介して対象イベントをリッスンします。 イベントが受信されると、プロファイルはジャーニーに入り、最小限の条件評価（同意チェック、プロファイル存在検証）を通過し、設定されたチャネルアクションノードを介して直ちに1つのメッセージを受信します。
最もシンプルな実装バリエーションです。 ジャーニーキャンバスには、イベントエントリノード、基本的な適格性チェック用のオプションの条件ノード、単一メッセージアクションノード、終了ノードが含まれます。 待機ステップも、複雑な分岐も、コンバージョンチェックもありません。 メッセージは通常、トリガーイベントから数秒から数分以内に配信されます。
トリガーイベントのイベントデータ（製品名、注文合計、フォームの詳細）は、パーソナライゼーションエディターのコンテキスト属性を介してメッセージのパーソナライゼーションに使用できます。 このアプローチにより、配信速度が最大化され、ジャーニーの複雑さが最小限に抑えられます。
重要な考慮事項：
- イベント後に顧客が自己コンバージョンしたかどうかに関係なく、メッセージが送信されます（コンバージョンチェックなし）
- 即時応答（確認、確認）が本質的に必要なイベントに最適です
- 再入力ルールは慎重に設定する必要があります。確認形式のメッセージの場合は、再入力を許可して、各イベントがメッセージを生成するようにします。ウェルカムスタイルのメッセージの場合は、再入力を防ぎます
利点：
- 最速の配信時間（イベント後数秒～数分）
- 最小限の可動部分で最もシンプルなジャーニー設定を実現
- ジャーニーの失敗やプロファイルの停滞のリスクが最も低い
- テストと保守が容易
制限：
- 送信前に顧客がセルフコンバージョンしたかどうかを確認できない
- 時間遅れの条件付きロジックを組み込めません
- 頻度ガバナンスなしでイベントが頻繁に発生する場合、不要なメッセージが生成される可能性があります
Experience League:
オプション B：待機付き条件付きイベントトリガーメッセージ
最適な用途：遅延した条件付き応答。顧客は、メッセージを受信する前に自己変換する時間が必要です。買い物かごの放棄（1 ～ 4時間待ってから、買い物かごがまだ放棄されているかどうかを確認）、放棄を参照（24時間待って、購入が行われたかどうかを確認）、体験版の有効期限（有効期限が近づくまで待つ）
仕組み：
ジャーニーは適格なイベントをリッスンし、プロファイルを入力し、条件を評価する前に待機期間を導入します。 待機後、条件ノードは、顧客が自己変換したか（購入を完了したか、サブスクリプションを更新したなど）、元のコンテキストがまだ有効かどうかを確認します。 条件が満たされた場合（カートが放棄されたなど）のみ、ジャーニーはメッセージ配信に進みます。
ジャーニーキャンバスには、イベントエントリノード、待機ノード（設定可能な期間または特定の日時）、コンバージョンイベントまたはプロファイル状態の変更をチェックする条件ノード、分岐パス（送信メッセージ対送信せずに終了）、適格パス上のメッセージアクションノード、および各ブランチ上の終了ノードが含まれます。 待機期間中にコンバージョンイベントが発生した場合に、ジャーニーからプロファイルを自動的に削除するように終了条件を設定できるため、明示的な条件チェックが不要になります。
このアプローチは、顧客がセルフコンバージョンする時間を確保し、顧客体験を向上させ、送信されるメッセージの関連性を高めることで、不要なメッセージを削減します。
重要な考慮事項：
- 待ち時間がコンバージョン率に大きな影響を与えます。待ち時間が短い（1～2時間）場合、緊急性は高まりますが、送信が不要になります。待ち時間が長い（24～48時間）場合、配信数は減りますが、関連性の高い時間枠を逃す可能性があります
- 条件評価では、コンバージョンイベントをAEPでキャプチャし、同じプロファイル IDに関連付ける必要があります
- 出口基準は、コンバージョンチェック用の明示的な条件ノードに代わる、よりクリーンな代替手段を提供します
- 再入力ルールでは、待機期間を考慮する必要があります。プロファイルは、待機中にジャーニーに再入力してはなりません
利点：
- セルフコンバージョンを確認し、不要なメッセージを削減
- より質の高い、関連性の高いコミュニケーションを実現したい
- 設定可能な遅延ウィンドウで、時間制限のあるユースケースをサポート
- 出口基準は、コンバージョン時の自動ジャーニー削除を有効にします
制限：
- 待機ノードと条件ノードを使用したジャーニーの複雑さの増加
- プロファイルは、待機期間中にジャーニーのスロットを占有します（ジャーニータイムアウトは91日の場合があります）
- 正確な条件評価のために、待機ウィンドウ内でコンバージョンイベントをAEPに取り込む必要があります
- オプション Aと比較して、配信時間が長い
Experience League:
オプション C：頻度ガバナンスによるイベントトリガー
メッセージの疲労が懸念される高頻度のイベントソース（ ページ表示、製品ビュー、検索クエリ、リピートカート追加）に最適です。 オプション Aまたはオプション Bの上にオーバーレイとして適用できます。
仕組み：
このオプションを選択すると、オプション Aまたはオプション Bに頻度ガバナンスが追加され、メッセージの過剰を防ぐことができます。 商品ビューや繰り返しカート追加など、頻度の高い行動イベントは、短期間でジャーニーを複数回トリガーにすることができます。 頻度ガバナンスがなければ、プロファイルは重複したメッセージや過剰なメッセージを受け取る可能性があります。
頻度ガバナンスは、プロファイルが1 チャンネルあたり受け取るメッセージ数を制限するAJOビジネスルール（頻度キャップ）と、プロファイルが同じジャーニーに再エントリする前にクールダウン期間を定義するジャーニーレベルの再エントリールールの2つの補完的なメカニズムを通じて実装されます。 ビジネスルールは組織レベルで運用され、あらゆるキャンペーンとジャーニーをまたいで上限を適用します（例：週に最大3通のメール）。一方、再入力クールダウンは個々のジャーニーレベルで運用されます（例：プロファイルは、最終入力から72時間以内にこの特定のジャーニーに再入力できません）。
さらに、競合と優先順位管理を設定して、トリガージャーニーに優先順位スコアを割り当てることができ、複数のジャーニーやキャンペーンが同じプロファイルを競合する場合に、最も優先順位の高いコミュニケーションが勝者となります。
重要な考慮事項：
- 頻度上限は、疲労の防止と、重要なトリガーメッセージの確実な配信とのバランスを取る必要があります
- チャネル別の上限を設定することをお勧めします。メール、SMS、プッシュ通知の疲労しきい値は異なります
- ジャーニー再入場クールダウンと組織レベルの頻度の上限が連携して機能します。両方とも設定する必要があります
- 優先スコアは、上限に達したときに勝者となるコミュニケーションを決定します。優先度の高いジャーニーには、より高いスコアを割り当てる必要があります
利点：
- 使用頻度の高いイベントソースによるメッセージの疲労を防止します
- ブランドの評判と加入者の満足度を維持
- 組織レベルの上限は、あらゆるキャンペーンとジャーニーをまたいでセーフティネットを提供します
- 優先順位のスコアリングにより、最も重要なメッセージが上限に達したときに配信
制限：
- 一部の適格なプロファイルは抑制され、関連するメッセージが欠落する可能性があります
- フリークエンシーキャップの設定は管理の複雑さを増します
- キャップは、同じチャネルを共有する他のアクティブなキャンペーンやジャーニーと予期せずインタラクションする可能性があります
- メッセージングポートフォリオの変更に伴い、継続的な監視と調整が必要
Experience League:
オプションの比較
次の表は、3つの実装オプションを主要な基準と比較したものです。
適切なオプションの選択
次の意思決定ガイダンスに従って、適切な導入オプションを選択してください。
-
メッセージをすぐに送信する必要がありますか？ はい場合は、オプション Aから開始します。確認メッセージ、ウェルカムメール、謝辞は、通常、待機期間は必要ありません。
-
お客様は、メッセージを受信する前に自己変換する時間が必要ですか？ はい場合は、オプション Bを選択します。カートの放棄、閲覧の放棄、試用期間の有効期限のユースケースは、顧客が自分でアクションを完了できる待機期間のメリットを受けます。
-
トリガーイベントの頻度は高いですか（同じプロファイルに対してセッションごとに、または1日ごとに複数回発生します）? はい場合は、オプション AまたはBの上に オプション C をオーバーレイとして追加します。製品ビュー、ページビュー、検索イベントでは、頻度保護が必要な大量のトリガーを生成できます。
-
複数のトリガーされたジャーニーおよびキャンペーンがサンドボックスでアクティブですか？ はい場合は、イベント頻度に関係なく オプション C を追加して、クロスジャーニーのコミュニケーション負荷を管理し、チャネルの疲労を防ぎます。
実際には、ほとんどの実稼動実装では、放棄スタイルのユースケースにはオプション B + C （頻度ガバナンス付きの条件付き待機）を、確認スタイルのユースケースにはオプション A + C （頻度ガバナンス付きの即時送信）をセーフティネットとして使用します。
実装フェーズ
次のフェーズでは、イベントトリガーメッセージのエンドツーエンドの実装を順を追って説明します。
フェーズ 1: イベント スキーマとデータ収集の設定
Application Function: AEP: Data Modeling （F2）、AEP: Data Sources & Collection （F3）
設定する内容： トリガーイベントをキャプチャするXDM ExperienceEvent スキーマ、これらのイベントを保存するデータセット、およびイベントをAEPにストリーミングするリアルタイム データ収集パイプライン（Web SDK、モバイル SDK、またはServer API）です。 この段階では、ジャーニーが顧客の声に耳を傾けるデータ基盤を構築します。
このフェーズの決定ポイント：
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 5-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| Commerceイベント（カート追加、購入、チェックアウト） | コマースのユースケース：カート放棄、購入後 | productListItems、cart、order フィールドを持つCommerce フィールドグループが必要です |
| web インタラクションイベント（ページビュー、製品ビュー） | 放棄の参照，コンテンツのエンゲージメントのトリガー | webPageDetails、webInteraction フィールドを含むWeb詳細フィールドグループが必要です |
| アプリケーションイベント（アプリインストール、アンインストール、アプリ内アクション） | モバイルエンゲージメントのトリガー | Mobile SDKの実装とアプリケーションフィールドグループが必要 |
| システムイベント（支払い失敗、サブスクリプション変更、ステータス更新） | 運用通知 | システムイベントを取り込むには、サーバーサイド APIまたはソースコネクタが必要です |
| フォーム送信イベント | リードジェネレーション、登録確認 | フォームデータフィールドをキャプチャするカスタムフィールドグループが必要です |
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| Web SDK | web ベースの行動イベント（カート追加、ページビュー、フォーム送信） | Web サイトにWeb SDKをインストールする必要があります。イベントはEdge Networkを介してリアルタイムでストリーミングされます |
| Mobile SDK | モバイルアプリイベント（アプリが開く、アプリ内アクション、プッシュトークン登録） | ネイティブアプリまたはReact Native ラッパーでのMobile SDK統合が必要です |
| Edge Network Server API | サーバーサイドのシステムイベント（決済処理、サブスクリプション管理、バックエンドトリガー） | クライアントサイドの依存関係はありません。組織のバックエンドシステムから送信されるイベント |
| Source コネクタ | 外部システム（CRM、マーケティングオートメーション、レガシープラットフォーム）からのイベント | 通常はバッチベース。ストリーミング可能でない限り、リアルタイムのトリガーをサポートしない場合があります。 |
UI ナビゲーション： データ収集/データストリーム/新しいデータストリーム（データストリームのセットアップ用）、スキーマ/スキーマの作成（イベントスキーマ用）、データセット/スキーマからのデータセットの作成（データセットの作成用）
キー設定の詳細：
- イベントスキーマには、ジャーニー条件の評価とメッセージのパーソナライゼーションに必要なすべてのフィールドを含める必要があります
- データストリームでは、Adobe Experience PlatformとAdobe Journey Optimizer サービスの両方を有効にする必要があります
- イベントが統合プロファイルに関連付けられるように、データセットをリアルタイム顧客プロファイルに対して有効にする必要があります
- イベントデータには、既知のプロファイルに解決できるID フィールド（電子メール、CRM ID、ECID）を含める必要があります
Experience League ドキュメント：
フェーズ 2:IDとプロファイルの設定
Application Function: AEP: Identity & Profile Configuration （F4）
設定するもの： トリガーイベントのIDのID名前空間、イベントスキーマのプライマリ ID指定、クロスデバイス解決のID リンク ルール、プロファイル統合の結合ポリシー。 これにより、トリガーイベントが統合された顧客プロファイルに関連付けられるようになり、ジャーニーは連絡先情報を解決してメッセージを配信できます。
このフェーズの決定ポイント：
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| メールアドレス | 認証されたweb セッションや、メールがキャプチャされたフォームからのイベント | 連絡可能なIDへの直接解決。メール配信の最も簡単な方法 |
| CRM ID | CRM IDがプライマリ識別子となる、認証済みシステムからのイベント | CRM ID名前空間の作成が必要です。メッセージを配信するには、プロファイルにリンクされたメールまたは電話が必要です |
| ECID （Experience Cloud ID） | 認証されたIDが利用できない匿名のweb イベントまたはアプリイベント | ECIDを既知のIDにリンクするには、IDのステッチが必要です。メッセージはECIDだけに送信できません |
| 電話番号 | モバイルやコールセンターとのやり取りからのイベント | SMS配信をサポートしています。電話名前空間が必要です |
UI ナビゲーション： ID > ID名前空間の作成；スキーマ > スキーマを選択> フィールドを選択> ID > プライマリ IDとして設定；プロファイル > ポリシーの結合
キー設定の詳細：
- 匿名イベント（ECIDのみ）は、ECIDがID グラフを介して既知の連絡先ID （電子メール、電話）にリンクされるまで、メッセージ配信をトリガーできません
- AJOで使用される結合ポリシーは、オーディエンス評価に使用されるポリシーと一致している必要があります
- web ベースのトリガーメッセージの場合、ID グラフでログインイベントを通じてECIDが認証済みIDにリンクされていることを確認します
Experience League ドキュメント：
フェーズ 3: チャネルサーフェスの設定
Application Function: AJO: Channel Configuration
設定するもの： トリガーされるメッセージの送信インフラストラクチャを定義するチャネルサーフェス（プリセット）。サブドメインのデリゲーション、IP プール、送信者ID、返信先アドレス、登録解除処理、チャネル固有の資格情報（SMS プロバイダー、プッシュ証明書）。 メッセージコンテンツを作成したり、ジャーニーを公開したりするには、有効なチャネルサーフェスが存在する必要があります。
このフェーズの決定ポイント：
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| 電子メール | 最もトリガーされたメッセージのユースケース：放棄の回復、確認、オンボーディング | サブドメインのデリゲーション、IP プール、送信者の設定が必要。リッチ HTML コンテンツとパーソナライゼーションをサポート |
| SMS | 時間的制約のある通知、簡潔なアラート、SMS エンゲージメントの高いオーディエンス | SMS プロバイダーの統合（Sinch、Twilio、Infobip）が必要です。文字数の制限と厳格な同意要件に従う必要があります |
| プッシュ通知 | モバイルアプリのエンゲージメント、アプリユーザーのリエンゲージメント | プッシュ資格情報の設定（iOSのAPN、AndroidのFCM）が必要です。プッシュが有効になっているアプリがインストールされている必要があります |
| 複数チャンネル | チャネルの嗜好またはフォールバックロジックを活用した包括的なエンゲージメント戦略 | 複数のチャネルサーフェスが必要です。チャネル選択は、ジャーニー条件ノードを介して管理できます |
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| 完全委任 | Adobeは、送信サブドメインのすべてのDNS レコードを管理する必要があります | 最も簡単な設定。AdobeはSPF、DKIM、DMARCレコードを自動的に管理します |
| CNAME委任 | Adobe インフラストラクチャを指定しながらDNS制御を維持したい | 手動でのDNS レコード管理が必要です。DNSに対してより多くの組織的制御を提供します |
UI ナビゲーション：管理/チャネル/サブドメイン（サブドメインのセットアップ用）、管理/チャネル/IP プール（IP プールの設定用）、管理/チャネル/チャネルサーフェス/サーフェスの作成（サーフェスの作成用）
キー設定の詳細：
- サブドメインの検証とDNS伝搬には、最大で48時間かかる場合があります
- 新しいIP プールにはウォームアッププランが必要（2～4週間の段階的なボリューム増加）
- ワンクリックでリスト登録解除できるヘッダーを設定して、電子メールのコンプライアンスを確保
- SMSの場合は、SMS チャネルサーフェスを作成する前にプロバイダーの資格情報を設定します
- プッシュの場合は、プッシュチャネルサーフェスを作成する前にAPNとFCM資格情報を設定します
Experience League ドキュメント：
フェーズ 4：メッセージコンテンツの制作
アプリケーション関数： AJO: メッセージ オーサリング
設定するもの： レイアウトデザイン、プロファイルとイベント属性を使用したパーソナライゼーショントークン、条件付きコンテンツブロック、再利用可能なフラグメント（ヘッダー、フッター、免責条項）、コンテンツのプレビューとテストなど、ジャーニーによって配信されるメッセージコンテンツ。
このフェーズの決定ポイント：
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| 既存のテンプレートから開始 | 組織テンプレートが存在し、ブランドの一貫性が必要 | コンテンツ制作の最速パス、ブランドコンプライアンスの確保、テンプレートの変更を新しいメッセージに反映 |
| Email Designerでゼロからデザイン | この特定のトリガーメッセージに必要なカスタムレイアウト | 完全なクリエイティブ制御、ドラッグ&ドロップ操作のビジュアルエディター、遅くても柔軟な操作 |
| HTMLの読み込み | コンテンツは、外部のチームまたは代理店によって設計され、HTMLとして提供されます | HTML コーディングの専門知識が必要です。メール Designerのすべての機能を完全にサポートしているとは限りません |
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| イベントコンテキスト属性 | メッセージには、トリガーイベントの詳細（製品名、カート値、フォームフィールド）を含める必要があります | パーソナライゼーションエディターでコンテキストイベント属性を使用します。データはトリガーイベントペイロードから取得されます |
| プロファイル属性 | メッセージには、プロファイルレベルのデータ（名、ロイヤルティ層、場所）を含める必要があります | XDM パス経由でプロファイル属性を使用（例：profile.person.name.firstName）。データは統合プロファイルから取得されます。 |
| イベント属性とプロファイル属性の両方 | メッセージでは、イベントコンテキストとプロファイルパーソナライゼーションを組み合わせる必要があります | トリガーされたメッセージに対する最も一般的なアプローチ。関連性（イベント）とパーソナライゼーション（プロファイル）の両方を確保 |
UI ナビゲーション： Content Management > Content Templates > Browse （テンプレート選択用）、Campaignまたはジャーニーのアクション > Edit content > Email Designer （コンテンツデザイン用）、テキストコンポーネント / Personalization アイコン （パーソナライゼーションの追加用）を選択
キー設定の詳細：
- コンテキスト属性を使用して、トリガーイベントからのデータ（製品名、カート値など）でパーソナライズします
- 名前、好み、ロイヤルティデータにプロファイル属性を使用
- 条件付きコンテンツブロックを設定して、プロファイルセグメントや属性ごとにコンテンツを変更します（ロイヤルティメンバー向けに異なるCTAなど）。
- トリガーされたメッセージ間で共有されるヘッダー、フッター、免責条項に対して、再利用可能なフラグメントを作成します
- 複数のテストプロファイルを使用してプレビューし、パーソナライゼーションが正しくレンダリングされていることを確認します
- ジャーニーを公開する前に、社内の関係者にプルーフを送信する
Experience League ドキュメント：
フェーズ 5: ジャーニーの作成と設定
アプリケーション関数： AJO: Journey Orchestration、AJO：頻度とビジネス ルール （オプション C）、AJO：競合と優先度の管理
設定する内容： トリガーイベントをリッスンし、メッセージ配信を調整するジャーニー。 これは、ジャーニーキャンバスがイベント入力ノード、条件ノード、待機ステップ（オプション Bの場合）、メッセージアクションノード、および終了条件を使用して設計されるコア実装フェーズです。 このフェーズでは、頻度ガバナンス（オプション C）と競合/優先度の設定もカバーします。
このフェーズの決定ポイント：
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| 再入力を許可（クールダウン付き） | イベントは合法的に繰り返すことができ、各オカレンスはメッセージを保証します（例えば、各カート放棄はリカバリーメッセージをトリガーする必要があります） | 重複イベントからの迅速な再エントリを防ぐためにクールダウン期間（最小5分）を設定します。一般的なクールダウンの範囲は1時間から72時間です |
| 再入力なし | メッセージは、イベントの繰り返し（初回登録後のウェルカムメッセージなど）にかかわらず、プロファイルごとに1回だけ送信する必要があります | プロファイルは、最初のジャーニー完了後に完全に除外されます。1回限りのライフサイクルメッセージに適しています |
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| 短い待ち時間（1～4時間） | カートの放棄など、緊急性の高いユースケースで、即座のフォローアップが効果的な場合 | メッセージ量が多い。一部のセルフコンバーターが表示される可能性があります。高価値のカートの回復に最適 |
| Medium待ち（12～24時間） | 閲覧の放棄やコンテンツエンゲージメントなど、緊急性の高いユースケース | バランスの取れたアプローチ：関連性を維持しながら不要な送信を減らしたい |
| 待機時間（2～7日） | 試用期間のリマインダーや定期的なチェックなど、緊急性の低いユースケース | メッセージ量が少なく、コンテキストの関連性を失うリスクが高い |
| カスタム日時 | 特定の日付に関連付けられたユースケース（例：試用期間の3日前に送付） | 計算された日時まで待ちます。カスタム式エディターを使用します |
| table 0-row-3 1-row-3 2-row-3 3-row-3 4-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| コンバージョンイベント（購入完了など） | コンバージョンが目標である場所で放棄をカートまたは閲覧する | コンバージョンイベントが検出されると、プロファイルは自動的に終了します。オプション Bの最もクリーンなアプローチ |
| Audience membership change | 適格なセグメントから離脱した場合、プロファイルは終了する必要があります | ストリーミング評価され、ほぼリアルタイムで更新されるオーディエンスが必要 |
| ジャーニータイムアウト（最大91日間） | デフォルトの動作 – プロファイルはジャーニーの最大期間の後に終了します | セーフティネット。短期間有効なトリガージャーニーの主な離脱メカニズムにしないでください |
| 明示的な出口基準はない | 対象となるプロファイルごとにメッセージを受信する簡単な確認（オプション A） | プロファイルは、メッセージアクションと終了ノードの後に自然に終了します |
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| チャネル固有の上限（例：週に3通のメール、1日に1通のSMS） | チャネルによって、疲労閾値は異なります | 推奨されるアプローチ。各チャネルの侵入性レベルを尊重します |
| グローバル上限（例：全チャネルで週5回のメッセージ） | あらゆるタイプのコミュニケーションを簡素化 | 管理が容易でありながら微妙な違いが少ない。過剰な制限によって邪魔にならないチャネルがある |
| ジャーニーレベルの再入力クールダウンのみ | この特定のジャーニーには頻度ガバナンスが必要ですが、組織全体には必要ありません | 最も簡単な実装。クロスジャーニーの疲労を防げない |
UI ナビゲーション：ジャーニー/ジャーニーの作成（ジャーニー作成用）、ジャーニーキャンバス/イベントアクティビティのドラッグ（イベント入力用）、ジャーニーキャンバス/ジャーニーキャンバス/待機アクティビティのドラッグ（待機設定の場合）、ジャーニープロパティ/条件のドラッグ（条件分岐の場合）、プロパティ/出口条件（出口設定用）、管理/ビジネスルール/ルールの作成（頻度キャップの場合）
キー設定の詳細：
- イベントスキーマを選択し、条件を定義してジャーニーイベントを設定します
- オプション Bの場合、イベントエントリの直後と条件評価の前に待機ノードを追加します
- プロファイル属性、イベントデータ、オーディエンスメンバーシップチェックを使用した条件ノードの設定
- メッセージアクションノードをチャネルサーフェスにリンクし、フェーズ 3と4でコンテンツを作成します
- ジャーニータイムアウトを適切な期間（トリガーされたジャーニーの場合は91日未満）に設定します
- オプション Cの場合、ジャーニーを公開する前に、管理/ビジネスルールを使用して頻度ルールを作成します
- 他の施策やジャーニーが重複するオーディエンスをターゲットにしている場合、優先度スコアをジャーニーに割り当てます
オプションが異なる場所：
オプション A （イベントがトリガーされたシンプル）の場合：
ジャーニーキャンバスは最小限に抑えられます。イベント入力/オプションの同意/適格性条件/メッセージアクション/終了。 待ち時間のステップやコンバージョンチェックはありません。 イベントが発生するたびにメッセージを生成する必要があるかどうかに基づいて、再入力ルールを設定します。
オプション B （条件付き待機）の場合：
イベント入力後に待機ノードを追加します。 待機後、コンディションノードを追加してコンバージョンを確認します（例：ジャーニー入力後にcommerce.purchases イベントが発生したかどうかを確認します）。または、終了条件を使用して、コンバージョン済みプロファイルを自動的に削除します。 「変換されていない」パスのメッセージアクションと「変換された」パスの終了ノードに分岐します。
オプション C （頻度ガバナンス）の場合：
公開する前に、管理/ビジネスルールを介して組織レベルの頻度の上限を設定します。 ジャーニープロパティでジャーニーレベルの再入力クールダウンを設定します。 オプションで、ジャーニーのプロパティを介して優先順位スコアを割り当て、上限に達したときに成功するコミュニケーションを制御します。 これは、オプション Aまたはオプション Bの上に適用できます。
Experience League ドキュメント：
フェーズ 6：ジャーニーのテストとデプロイ
アプリケーション関数： AJO: Journey Orchestration
設定する内容： テストモードの検証で、ジャーニーがテストプロファイルで期待どおりに動作することを確認し、その後ジャーニーの公開でジャーニーを公開して公開します。
UI ナビゲーション：ジャーニーキャンバス/テストモード切り替え（テスト用）、ジャーニーキャンバス/公開（デプロイメント用）
キー設定の詳細：
- ジャーニーキャンバスでテストモードを有効にして、テストプロファイルでイベントトリガーをシミュレートします
- 有効なチャネル連絡先情報（電子メールアドレス、電話番号）を持つテストプロファイルを選択します
- テストイベントをトリガーし、テストプロファイルが期待されるパスを通過することを確認します
- オプション Bの場合、待機ステップが正しく動作し、条件評価によって想定される分岐が生成されることを確認します
- パーソナライゼーショントークンがテストメッセージで正しくレンダリングされていることを確認します
- テストが成功したら、ジャーニーを公開して公開します
- 公開後にジャーニーのステータスと初期プロファイルエントリ指標を監視する
Experience League ドキュメント：
フェーズ 7：パフォーマンスの監視と報告
Application Function: AJO: Reporting & Performance Analysis, S4: Monitoring & Observability, S5: Reporting & Analysis
設定する内容：配信とエンゲージメントのモニタリング用のライブジャーニーレポートと過去ジャーニーレポート、イベント取り込みとジャーニー処理のエラーに対するプラットフォームアラート、トリガーされたメッセージの有効性のクロスチャネル分析を深めるためのオプションとしてCJA ワークスペース。
このフェーズの決定ポイント：
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| オプション | 選択するタイミング | 検討事項 |
| AJO ネイティブレポートのみ | 配信指標の運用モニタリングで十分である | すぐに利用できます。送信、配信、バウンス、開封、クリック済みのカバーを追加する必要はありません |
| AJOネイティブとCJAの連携 | クロスチャネル分析、コンバージョンアトリビューション、トレンド分析が必要です | AJO データセットにリンクされたCJA接続とデータビューが必要です。より詳細な分析機能を提供します |
UI ナビゲーション：ジャーニー/ジャーニー/ライブレポートを選択（ライブモニタリング用）、ジャーニー/ジャーニーを選択/すべての時間レポート（履歴分析用）、アラート/アラートルール/購読（アラート設定の場合）
キー設定の詳細：
- アクティブな実行中にジャーニーライブレポートにアクセスして、プロファイルのエントリ、終了、配信の指標を監視します
- ジャーニーがアクティブになった後、有意義なデータを蓄積するのに十分な時間について履歴レポートを確認します
- ソースフローの実行エラー（イベントの取り込み）とジャーニー処理の遅延に対するアラートを設定します
- CJA統合の場合、CJA接続にAJO エクスペリエンスイベントデータセット（メッセージフィードバックイベントデータセット、メールトラッキングエクスペリエンスイベントデータセット）が含まれていることを確認します
Experience League ドキュメント：
実装に関する考慮事項
このセクションでは、イベントをトリガーとしたメッセージ実装に関するガードレール、一般的な落とし穴、ベストプラクティス、トレードオフの決定について説明します。
ガードレールと制限
イベントをトリガーにしたメッセージ実装には、次のプラットフォームのガードレールと制限が適用されます。
- 単一イベントスループット：単一イベントジャーニーのサンドボックスあたり1秒あたり最大5,000件のイベント — Journey Optimizer ガードレール
- ライブジャーニーの制限： サンドボックスあたり最大500 ライブジャーニー – Journey Optimizer ガードレール
- ジャーニーキャンバスの制限： ジャーニーキャンバスあたり最大50 アクティビティ
- ジャーニータイムアウト：最大ジャーニー期間は91日（グローバル タイムアウト）です
- 再入場クールダウン：再入場クールダウンの最小値は5分です
- 頻度キャップ設定： サンドボックスごとに最大10個のキャッピング設定
- チャネルサーフェス： サンドボックスごとに、チャネルタイプごとに最大10個のチャネルサーフェス
- ストリーミング取り込み： HTTP接続あたり1秒あたり最大20,000 レコード — 取り込みガードレール
- 計算属性： サンドボックスごとに最大25個の計算属性 – 計算属性のガードレール
- コンテンツフラグメント： メッセージごとに最大30個のコンテンツフラグメント
- ライブレポートの更新： ライブレポートは、60秒ごとに更新され、過去24時間のデータが表示されます
- 履歴レポートの待ち時間：履歴（すべての時間）レポートは、実行終了後に完全に入力するのに最大2時間かかる場合があります
よくある落とし穴
イベントトリガーメッセージを実装する際には、次の一般的な問題に注意してください。
-
ID解決のない匿名イベント： ECID （匿名Cookie ID）のみを持つトリガーイベントは、メッセージ配信用の連絡先プロファイルに解決できません。 トリガーイベントに認証済みのIDが含まれているか、ID グラフがECIDを既知の連絡先にリンクしていることを確認します。 ID解決がなければ、プロファイルはジャーニーにエントリしますが、メッセージ配信手順で失敗します。
-
オプション Bの条件チェックにコンバージョンイベントがありません： コンバージョンイベント（購入など）がAEPに取り込まれていないか、トリガーイベントと同じプロファイル IDに関連付けられていない場合、条件チェックは「コンバージョンされていない」と誤って評価され、不要なメッセージが送信されます。 コンバージョンイベントがリアルタイムでAEPに流れ込み、IDがトリガーイベントと共有されることを確認します。
-
過度に許可された再入力ルール：高頻度のイベントソースに対してクールダウン期間なしで再入力を許可すると、同じプロファイルが数分以内に複数のメッセージを受信する可能性があります。 ビジネスの状況に合わせて、再入力クールダウンを常に設定します（例：買い物かごの放棄に対しては4時間クールダウン、閲覧放棄に対しては24時間クールダウン）。
-
待機ステップのタイムゾーンの不整合：待機ステップは、デフォルトでUTCで処理されます。 ジャーニーが複数のタイムゾーンのプロファイルをターゲットにし、待機が受信者の現地時間に合わせる必要がある場合は、ジャーニーのタイムゾーン設定を適切に設定します。
-
他のキャンペーンと競合している頻度の上限：組織レベルの頻度の上限は、すべてのキャンペーンとジャーニーに適用されます。 プロファイルが既に他のアクティブなキャンペーンから上限に達している場合、新しいトリガージャーニーは抑制される場合があります。 抑制率を監視し、優先順位のスコアを調整して、重要なトリガーメッセージを優先順位付けします。
-
依存関係が欠落しているため、ジャーニーの公開に失敗しました： ジャーニーキャンバスのすべてのブランチは、終了アクティビティで終了する必要があります。 すべてのアクションノードは、アクティブなメッセージコンテンツを持つ有効なチャネルサーフェスを参照する必要があります。 公開前にすべての依存関係を確認します。
ベストプラクティス
イベントをトリガーにしたメッセージの実装を成功させるには、次の推奨事項に従ってください。
-
シンプルに開始し、次の操作を繰り返します。新しいトリガーされたメッセージのユースケースの場合は、オプション Aから始めます。 イベントパイプラインとメッセージ配信を検証した後にのみ、待機と条件ロジック（オプション B）を追加します。 複数のトリガージャーニーがアクティブな場合の頻度ガバナンス（オプション C）を追加します。
-
コンバージョンチェックに条件ノードの代わりに終了条件を使用：終了条件は、条件を満たすイベント（購入など）が発生したときにジャーニーからプロファイルを自動的に削除し、待機ステップ後に明示的な条件ノードを必要としません。 これにより、よりクリーンなジャーニーキャンバスと、より応答性の高いコンバージョン検出が生成されます。
-
開発用サンドボックスで実際のイベントデータを使用してテストを行う：実際のイベントペイロード（テストプロファイルだけでなく）を使用してテストモードを使用し、イベントスキーマフィールド、パーソナライゼーショントークン、条件式が本番環境のようなデータで正しく動作することを検証します。
-
イベント固有の再入力クールダウンを設定： クールダウン期間をトリガーイベントのビジネスコンテキストと一致させます。 カート放棄のジャーニーでは、通常4～24時間のクールダウンが使用されます。確認ジャーニーでは、すぐに再エントリできる場合があります。オンボーディングジャーニーでは、再エントリを完全に防ぐ必要があります。
-
正常性の指標として抑制率を監視します：抑制率（プロファイルが適格ですが、頻度の上限または条件によりメッセージを受信しないプロファイル）が30 ～ 40%を超える場合は、上限が制限されすぎているか、トリガーイベントが広く定義されすぎているかどうかを確認します。
-
ライブ ジャーニーを編集する代わりにバージョン ジャーニー： ライブ ジャーニーを直接編集することはできません。 ジャーニーを複製して変更し、古いバージョンを停止して新しいバージョンを公開することで、新しいバージョンを作成します。 これにより、現在ジャーニーにあるプロファイルの混乱を回避できます。
-
条件ノードにフォールバック/デフォルトパスを含める：予期しないプロファイル状態を処理するために、条件ノードにデフォルト（else）パスを常に設定します。 どの条件ブランチにも一致しないプロファイルは、スタックしたままにするのではなく、正常に終了する必要があります。
トレードオフの決定
イベントをトリガーとしたメッセージ実装を設計する際には、次のトレードオフを考慮してください。
- オプション Aのメリット：すべてのイベントでメッセージが保証される、スピード、シンプルさ、確認スタイルのユースケース
- オプション Bのお気に入り：関連性、メッセージ疲れの軽減、自己変換が一般的な放棄スタイルのユースケース
- 推奨事項：速度が主な値となるトランザクションメッセージと確認メッセージにオプション Aを使用します。 関連性がスピードを上回るリカバリーおよびリエンゲージメントメッセージにオプション Bを使用します。 待機時間を試して、各ユースケースに最適なバランスを見つけます。
- 厳格な大文字の使用：顧客体験、ブランドの評判、配信品質（迷惑メールによる苦情の減少）
- 許可キャップの優先： メッセージのカバレッジ、コンバージョンの機会、見逃したトリガーの回避
- 推奨事項：業界標準の上限（週に3～5通、週に1～2通、プッシュ通知の日に2～3回）から開始し、エンゲージメント指標と配信停止率に基づいて調整します。 優先順位の高いメッセージをトリガーに割り当て、上限に達した場合にバッチキャンペーンの効果を高めます。
- シンプルなジャーニーの利点：実装の高速化、デバッグの簡素化、メンテナンス負担の軽減
- 洗練されたジャーニーの利点：より正確なターゲティング、より優れたパーソナライゼーション、不要な送信の削減
- 推奨事項： ビジネス要件を満たす最もシンプルなジャーニーから始めます。 パフォーマンスデータにもとづいて複雑さを段階的に追加。 信頼性の高いシンプルなジャーニーは、検出されないエラーを伴う複雑なジャーニーよりも価値があります。
関連ドキュメント
以下のリソースでは、この実装で使用される機能に関する追加の詳細を提供します。