マルチステップのオーケストレーションジャーニー
このガイドでは、Adobe Journey Optimizer （AJO）とReal-Time Customer Data Platform （RT-CDP）を使用して、マルチステップのオーケストレーションされたジャーニーを構築するための包括的な実装の設計図を提供します。 これは、複数のメッセージを長期的に配信する、分岐したマルチタッチのカスタマージャーニーを編成する必要があるソリューションアーキテクト、マーケティングテクノロジスト、実装エンジニア向けに設計されています。
実行可能なすべての実装オプション、すべての設定ポイントでの決定の考慮事項、およびAdobe Experience League ドキュメントへのリンクが表示されます。 このガイドでは、マルチステップのジャーニー実装を計画、設定、検証する方法を説明します。
ユースケースの概要
マルチステップのオーケストレーションされたジャーニーは、単一のメッセージでは顧客が望む結果を得るのに不十分なビジネスシナリオに対処します。 このジャーニーでは、1回限りの送信ではなく、プロファイル属性、行動シグナル、イベントデータにもとづいてパスを適応させる分岐ロジックを使用して、電子メール、SMS メッセージ、プッシュ通知、アプリ内メッセージなどの一連の顧客接点を数日から数週間にわたって誘導します。
これらのジャーニーは、AJOの最も複雑なキャンペーンパターンです。 オーディエンスベースまたはイベントベースのエントリを、アクションノード（メッセージ）、条件ノード（分岐ロジック）、待機ノード（時間遅延）、および終了条件（コンバージョンイベントまたはタイムアウト）のキャンバスと組み合わせます。 プロファイルはジャーニーを独自のペースで進み、各ステップでコンテキストに即したコンテンツを受け取ります。
このパターンでは、単純なパターンである、単一送信キャンペーンのバッチアウトバウンドメッセージのアクティベーションと、単一イベントの応答に対するイベントトリガーメッセージを使用します。 このパターンは、ユースケースにおいて、複数のインタラクションを通じてプロファイルを育成する必要がある場合に使用します。
主なビジネス目標
このユースケースパターンでは、次のビジネス目標をサポートしています。
顧客維持率の向上
価値主導の体験と継続的な関係育成を通じて、既存顧客との関係を維持し、更新する。
KPI: リテンション、顧客生涯価値、エンゲージメント
顧客オンボーディングの改善
合理化され、パーソナライズされたウェルカムエクスペリエンスとアクティベーションジャーニーにより、新規顧客の価値創出までの時間を短縮できます。
KPI:のエンゲージメント、リテンション、コンバージョン率
休眠顧客のリエンゲージメント
行動シグナルにもとづいたリエンゲージメント施策を実施し、非アクティブな顧客や休眠顧客を取り戻すことができます。
KPI:のエンゲージメント、リテンション、コンバージョン率
放棄されたカートとジャーニーを回復する
タイムリーでパーソナライズされたフォローアップにより、購入、申し込み、登録のフローの途中で離脱したユーザーをリエンゲージできます。
KPI: コンバージョン率、増収率、エンゲージメント
戦術的なユースケース
次のシナリオは、マルチステップのオーケストレーションされたジャーニーパターンの一般的なアプリケーションを示しています。
- 顧客オンボーディングシリーズ – ようこそ電子メール、機能教育、登録後の最初の14日間のアクティベーションプロンプト
- 再エンゲージメント ドリップキャンペーン – リマインダーメール、インセンティブオファー、3週間にわたる休眠顧客への最終通知
- ロイヤルティマイルストーンジャーニー – 階層アップグレード通知、続いて限定オファー、メンバーシップの契約応当日の更新リマインダー
- ウィンバック シーケンス — 「お見逃ししています」電子メール、電子メールによる割引オファー、解約した購入者に対する最終的なSMS リマインダー
- 製品の導入ジャーニー – 試用版の歓迎、使用のヒント、試用期間の進行に伴うアップグレードプロンプト
- サブスクリプション更新シーケンス — 30日間の通知、7日間のリマインダー、および今後のサブスクリプション更新の有効期限メッセージ
- 購入後のナーチャリング – お礼の電子メール、使い方ガイド、クロスセルのレコメンデーション、購入後30日間にわたるレビューリクエスト
主要業績評価指標
次のKPIを使用して、マルチステップのオーケストレーションされたジャーニー実装の効果を測定します。
ユースケースパターン
複数ステップの調整されたジャーニー
待機、条件、複数のメッセージアクションを経時的に使用する分岐マルチタッチジャーニーを通じてプロファイルを導きます。
関数チェーン： オーディエンスの評価/ジャーニーの実行（マルチノード）/条件分岐/メッセージ配信（xN）/出口条件/レポート
アプリケーション
このユースケースパターンを実装するには、次のアプリケーションを使用します。
- Adobe Journey Optimizer（AJO） — ジャーニー オーケストレーション エンジン、メッセージ オーサリング、チャネル設定、コンテンツの実験、頻度と競合の管理、レポート
- Adobe Real-Time Customer Data Platform（RT-CDP） — ジャーニーエントリのオーディエンスのオーディエンス評価と定義、パーソナライゼーションおよび条件分岐のプロファイルデータ
- Adobe Experience Platform（AEP） — プロファイルストア、ID サービス、イベントデータ取り込み、基礎データインフラストラクチャ
基本関数
このユースケースパターンでは、次の基本機能を使用する必要があります。 各機能について、ステータスは、通常それが必要か、事前設定が想定されているか、適用できないかを示します。
サポート機能
次の機能は、このユースケースパターンを強化しますが、コア実行には必要ありません。
アプリケーション関数
この計画では、アプリケーション機能カタログから次の機能を実行します。 関数は、番号付きのステップではなく実装フェーズにマッピングされます。
Journey Optimizer （AJO）
Real-Time CDP （RT-CDP）
前提条件
実装を開始する前に、次の前提条件を満たしてください。
- [ ] AJO サンドボックスは、ジャーニーの作成と公開の権限でプロビジョニングされています
- [ ]少なくとも1つのチャネルサーフェス （電子メール、SMS、またはプッシュ）が設定され、アクティブになっています
- [ ] プロファイル スキーマには、条件の分岐とパーソナライゼーションに必要な属性が含まれています
- [ ] エクスペリエンスイベントスキーマは、終了条件で使用されるコンバージョンイベント用に設定されています
- [ ] イベントストリーミングは、出口条件またはイベントトリガーエントリで使用されるリアルタイムイベントに対してアクティブです
- [ ]個のID名前空間と結合ポリシーがクロスチャネルプロファイル解決用に設定されています
- [ ]個のコンテンツアセット（画像、コピー、CTA）をメッセージのタッチポイントごとに準備
- [ ] エントリ オーディエンスが定義され、評価されます（オーディエンス読み取りジャーニーの場合）
- [ ] トリガーイベント スキーマが設定されています（イベント トリガーされたジャーニーの場合）
- [ ジャーニーテストモードの検証に]個のテストプロファイルを使用できます
- [ ]抑制リストは、使用されているすべてのチャネルについてレビューされ、最新の状態になっています
実装オプション
次のオプションを確認して、マルチステップのオーケストレーションされたジャーニーに最適なアプローチを決定します。
オプション A：オーディエンス読み取りオーケストレーションジャーニー
最適な用途：既知のオーディエンスがジャーニーに入り、スケジュールされたタッチポイントを進む時間ベースのナーチャリングシーケンス（オンボーディングシリーズ、更新シーケンス、リエンゲージメントの低下、ロイヤルティマイルストーンジャーニー）です。
仕組み：
オーディエンスは、ジャーニーのエントリ時に、1回限りの読み取りまたは定期的なスケジュールで読み取られます。 すべての適格なプロファイルが同時にジャーニーにエントリし、待機時間と条件評価によって管理される、独自のペースでキャンバスを進みます。 ジャーニーにおける各プロファイルの経路は独立しています。「エンゲージ済み」ブランチを取るプロファイルもあれば、行動や属性に基づいて「エンゲージしていない」ブランチを取るプロファイルもあります。
オーディエンスは、オーディエンスを読み取りアクティビティの実行時に評価されます。 繰り返しジャーニーの場合、オーディエンスは繰り返しごとに再評価され、新しい適格プロファイルがジャーニーに入ると、既にジャーニー内にあるプロファイルはパスを継続します。 このアプローチは、入場タイミングを予測できるので、スケジュール型のライフサイクルプログラムに適しています。
重要な考慮事項：
- オーディエンスは、ジャーニーをアクティベートする前に定義および評価する必要があります
- 繰り返し読み取りを使用すると、新しい修飾子を各サイクルに入力できます
- ジャーニー内のプロファイルは再読み取りされません。後続の読み取りには新しい修飾子のみが入力されます
- オーディエンス読み取りジャーニーの待機ステップの所要時間は最低1時間です
利点：
- ビジネススケジュールに沿った予測可能な入力タイミング
- 大規模なオーディエンスボリュームをサポート（最大20,000個のプロファイル/秒のデフォルトのスロットル）
- 既知のオーディエンス母集団を使用して容易にテストおよび監視
- 定期的なエントリ（毎日、毎週、毎月）にスケジュールできます
制限：
- エントリはバッチベースであり、リアルタイムではありません。プロファイルは、適格性が高い場合ではなく、スケジュールされた読み取り時間に入力されます
- すぐに応答が必要な行動開始シーケンスには適していません
- 読み取り間のオーディエンスの変更は、既にジャーニーにあるプロファイルには反映されません
Experience League:
オプション B：イベントトリガーのオーケストレーションジャーニー
リアルタイム イベントがジャーニーを開始する行動開始シーケンスに最適です。カート放棄のエスカレーション、購入後のナーチャリング、マイルストーンをトリガーとしたロイヤルティジャーニー、体験版アクティベーションのシーケンスなど。
仕組み：
個々のプロファイルに対する単一のイベント（購入、買い物かご放棄、フォーム送信、アプリのインストールなど）では、トリガージャーニーのエントリがリアルタイムで実行されます。 イベントが受信されると、プロファイルがジャーニーにエントリし、条件、待機、分岐を含むタッチポイントのシーケンスを進みます。 このアプローチは、イベントをトリガーにしたメッセージの即時性と、ジャーニー全体のマルチステップのオーケストレーションを組み合わせたものです。
トリガーイベントは、スキーマと条件が定義されたジャーニーイベントとして設定する必要があります。 ジャーニーはイベントを継続的にリッスンし、イベントが到着するたびにプロファイルを1つずつ入力します。 後続のジャーニーノードは、プロファイルの応答を評価して、フォローするブランチを決定できます。
重要な考慮事項：
- リアルタイム イベント ストリーミングをアクティブにする必要があります
- イベントスキーマと条件は、誤ったトリガーを防ぐために正確に設定する必要があります
- 再入力ルールは非常に重要です。イベントが再度発生した場合に、プロファイルが再入力できるかどうかを判断します
- 1秒あたり5,000件までのイベントをサンドボックスごとにサポート
利点：
- 顧客の行動にもとづいてリアルタイムでエントリ – 詳細なコンテキストを把握
- 各プロファイルは、イベントが発生したときに、スケジュールではなく独立して入力されます
- 行動応答シーケンス（カート放棄、購入後）への自然な適合
- エントリ後のパーソナライズされた分岐のために、プロファイルデータと組み合わせることができます
制限：
- ストリーミングイベント基盤を導入する必要がある
- イベントスキーマの設定とテストの複雑さ
- 各イベントは1つのプロファイルとして扱われ、一括オーディエンスアクティベーションには適していません
- デバッグには、個々のプロファイルジャーニーを追跡する必要があります
Experience League:
オプション C：マルチチャネルジャーニーのオーケストレーション
各顧客接点で異なるチャネルを使用する クロスチャネルシーケンス（メール、SMS、プッシュエスカレーション、メール、アプリ内メッセージなど）に最適です。 オーディエンス読み取りエントリまたはイベントトリガーエントリを使用できます。
仕組み：
このオプションは、同じジャーニー内に複数のメッセージングチャネルを組み込むことで、オプション Aまたはオプション Bを拡張します。 ジャーニーの各アクションノードは、異なるチャネル（電子メール、SMS、プッシュ通知、アプリ内メッセージ、web）をターゲットにすることができるため、それぞれに個別のチャネルサーフェスが必要です。 ジャーニーデザイナーは、各ステップで適切なチャネルを選択し、エスカレーションパターン（メールが最初で、エンゲージメントがない場合はSMS）または補完的なパターン（アプリ内メッセージの強化など）を有効にします。
クロスチャネルジャーニーでは、使用する各チャネルのチャネルサーフェスが必要です。チャネル固有のパーソナライゼーション、キャラクターの制限、オプトイン要件を考慮する必要があります。 コンディションノードは、以前のメッセージとのエンゲージメントを確認できます（例：「開封メール？」）。 ブランチ条件として）を使用して次のチャネルを決定します。
重要な考慮事項：
- ジャーニーで使用される各チャネルにアクティブなチャネルサーフェスが必要です
- 各チャネルには、それぞれ異なるパーソナライゼーション機能とコンテンツ制約があります
- 同意はチャネルごとに検証する必要があります。プロファイルはSMSではなく電子メールでオプトインできます
- チャネル固有の配信頻度の上限を設定し、チャネルをまたいだ過剰メッセージを防ぐ必要があります
利点：
- 顧客が好むチャネルでプロファイルをエンゲージすることで、リーチを最大化
- レスポンシブではないプロファイルのエスカレーション戦略を有効にします
- チャネルをまたいだ補完的なメッセージをサポートし、エンゲージメントを強化
- 非常に洗練された顧客体験を実現
制限：
- 実装の複雑さが最も大きい：各チャネルに設定が必要
- コンテンツは、各顧客接点でチャネルごとに作成する必要があります
- 同意と頻度の管理は、チャネルをまたいでより複雑になる
- テストでは、すべてのチャネルサーフェスを検証する必要があります
Experience League:
オプションの比較
次の表は、3つの実装オプションを主要な基準と比較したものです。
適切なオプションの選択
次の意思決定フローに従って、適切な導入アプローチを選択します。
-
ジャーニーは顧客行動またはイベントによって開始されますか？ はい場合は、オプション B （イベントがトリガーされました）を選択します。 ジャーニーがスケジュールされたオーディエンス読み取りによって開始された場合は、オプション A （オーディエンス読み取り）を選択します。
-
ジャーニーでは、複数のメッセージングチャネル（電子メールやSMSなど）を使用していますか？ はい場合は、入力方法の選択肢（AまたはB）の上にオプション C （マルチチャネル）を適用します。 ジャーニー全体で単一のチャネルを使用する場合は、オプション AまたはBだけで十分です。
-
エンゲージメントに基づいて別のチャネルにエスカレーションする必要がありますか？ はいの場合は、以前のメッセージと分岐のエンゲージメントをチェックする条件ノードを含む オプション C を選択してチャネルを切り替えます。
-
オーディエンスは事前に把握されていて、スケジュールに従って処理されていますか？ はい場合は、オプション Aを選択します。プロファイルがアクションを実行した瞬間にジャーニーに入る必要がある場合は、オプション Bを選択します。
実装フェーズ
次のフェーズでは、マルチステップのオーケストレーションされたジャーニーをエンドツーエンドで実装します。
フェーズ 1：チャネルの設定とオーディエンスの準備
アプリケーション関数： AJO: Channel Configuration、RT-CDP: Audience Evaluation
ジャーニーを設計する前に、すべてのチャネルサーフェスをアクティブにし、（オプション Aの）エントリオーディエンスを定義して評価する必要があります。 この段階では、インフラストラクチャでメッセージを配信する準備が整っています。
各顧客接点のチャネルタイプの決定
各顧客接点で、ジャーニーがどのメッセージングチャネルを使用するか？
オーディエンス評価方法の決定（オプション A）
プロファイルは、どの程度の期間でエントリオーディエンスに適格となる必要がありますか？
サブドメインのデリゲーション方法を決定する（メールチャネル）
メール送信サブドメインをAdobeにデリゲートする方法を教えてください。
UI ナビゲーション
- チャネルサーフェス：管理/チャネル/チャネルサーフェス/サーフェスを作成
- サブドメイン：管理/チャネル/サブドメイン
- SMS設定：管理/チャネル/SMS設定
- プッシュ設定：管理/チャネル/プッシュ通知設定
- オーディエンス：顧客/オーディエンス/オーディエンスの作成/ルールの構築
主要な設定の詳細
- 電子メールのIP プールウォームアップステータスの検証：新しいIP プールには、2～4週間にわたる段階的なウォームアッププランが必要です
- SMSの場合は、プロバイダーの資格情報を設定し、送信者番号の登録を確認します
- プッシュの場合は、APNs証明書とFCM サーバーキーをアップロードします
- セグメントビルダーを使用して、ターゲット母集団をカバーするセグメントルールでエントリオーディエンスを定義します
- オーディエンス定義に抑制ルールを含める（最近変換された、グローバルに購読解除を除外）
選択肢が異なる点
オプション A （オーディエンス読み取り）の場合：
エントリオーディエンスの定義と評価。 オーディエンスの母集団が0以外であることを確認します。 ジャーニーで1回限りのオーディエンス読み取りまたは繰り返し読み取りスケジュールを使用するかどうかを決定します。
オプション B （イベントがトリガーされた場合）:
トリガーイベントスキーマが設定されており、イベントがプラットフォームにストリーミングされていることを確認します。 事前に定義されたオーディエンスは必要ありません。プロファイルは、イベントの受信時に個別に入力されます。
オプション C （マルチチャネル）の場合：
ジャーニーで使用される各チャネル（メール、SMS、プッシュ、アプリ内）のチャネルサーフェスを設定します。 ターゲット母集団のチャネルごとの同意ステータスを確認します。
Experience League ドキュメント
フェーズ 2: メッセージコンテンツの作成
アプリケーション関数： AJO: メッセージのオーサリング
ジャーニーの各顧客接点のメッセージコンテンツを作成します。 メッセージごとに、コンテンツ、パーソナライゼーションの深さ、チャネルが異なる場合があります。 このフェーズでは、ジャーニーアクションノードが参照するすべての成果物コンテンツが作成されます。
コンテンツアプローチの決定
各メッセージはテンプレートから始めるのか、ゼロから設計するのか、それともHTMLをインポートするのか？
パーソナライゼーションの深さを決定する
各メッセージにどの程度のパーソナライゼーションを含めるべきか？
フラグメント戦略の決定
共有コンテンツブロック（ヘッダー、フッター、法的テキスト）を再利用可能なフラグメントとして作成する必要がありますか？
UI ナビゲーション
- コンテンツ管理/ コンテンツテンプレート / 参照
- 電子メールDesigner（キャンペーンまたはジャーニーアクション内）
- コンテンツ管理/ フラグメント / フラグメントを作成
主要な設定の詳細
- ジャーニーの各メッセージアクションのコンテンツを作成する – 4 ステップのジャーニーでは、4つの個別のメッセージデザインが必要になる場合があります
- XDM プロファイルパスを参照するパーソナライゼーション式を使用します（例：
{{profile.person.name.firstName}}） - セグメント固有のバリエーション用に動的コンテンツブロックを設定できます
- テストプロファイルを使用して各メッセージをプレビューし、パーソナライゼーションのレンダリングを検証
- コンテンツのレビューのために社内関係者にプルーフを送信する
- SMSの場合、文字制限（標準GSM エンコーディングの場合は160文字）を尊重します
- プッシュの場合は、タイトル、本文、画像、ディープリンク/URL アクションを設定します
Experience League ドキュメント
フェーズ 3：ジャーニーの設計とアクティブ化
アプリケーション関数： AJO: Journey Orchestration
エントリノード、アクションノード（メッセージ）、条件ノード（分岐）、待機ノード（時間遅延）、および終了条件を含むマルチステップジャーニーキャンバスを設計します。 その後、テストプロファイルでテストし、公開します。
エントリタイプの決定
プロファイルはどのようにジャーニーにエントリすればよいですか？
再エントリのポリシーを決定
プロファイルは、完了後または完了後にジャーニーを再入力できますか？
顧客接点をまたいで待機時間を決定する
各メッセージの間、ジャーニーはどのくらい待つべきですか？
分岐条件の決定
プロファイルのパスを決定する条件
出口基準の決定
プロファイルがジャーニーを早期に離脱する原因となるイベントまたは条件は何か？
ジャーニータイムアウトの決定
プロファイルがジャーニーに保持できる最大期間は何ですか？
UI ナビゲーション
- ジャーニーの作成：ジャーニー/ジャーニーの作成
- ジャーニーのプロパティ：ジャーニーキャンバス/プロパティパネル
- エントリノード：ジャーニーキャンバス/ドラッグ「オーディエンスを読み取り」またはイベントアクティビティ
- アクションノード：ジャーニーキャンバス/チャネルアクションをドラッグ（メール、SMS、プッシュ）
- コンディションノード：ジャーニーキャンバス/ドラッグ「コンディション」アクティビティ
- 待機ノード：ジャーニーキャンバス/「待機」アクティビティをドラッグ
- 出口基準：ジャーニープロパティ/出口基準/設定
- テストモード：ジャーニーキャンバス/テストモード切り替え
- 公開：ジャーニーキャンバス/公開
主要な設定の詳細
- 明確で記述的な規則を使用してジャーニーに名前を付けます（例：「Onboarding_Series_Email_v1」）
- 一貫した待機ステップ処理のためのジャーニータイムゾーンの設定
- 各アクションノードに適切なチャネルサーフェスを設定し、作成したメッセージコンテンツにリンクします
- すべてのブランチは終了アクティビティで終了する必要があります
- ユースケースに適した再入力ルールの設定
- テストプロファイルでテストモードを使用して、公開前にジャーニーパス全体をシミュレートします
- テストプロファイルが期待されるパスをトラバースし、正しいメッセージを受信することを確認します
選択肢が異なる点
オプション A （オーディエンス読み取り）の場合：
- 「オーディエンスを読み取り」アクティビティをエントリノードとしてドラッグします
- フェーズ 1で定義されたターゲットオーディエンスを選択します
- 必要に応じて、定期的な読み取りスケジュール（毎日、毎週）を設定します
- 下流システムの負荷が懸念される場合は、読み取り速度のスロットルを設定します
オプション B （イベントがトリガーされた場合）:
- トリガーイベントをエントリノードとしてドラッグします
- イベントスキーマとエントリ条件の設定
- 繰り返しイベントから重複するエントリを避けるために、再入力ルールを慎重に設定します
オプション C （マルチチャネル）の場合：
- オプション AまたはBのエントリメソッドを使用する
- 各アクションノードで、そのタッチポイントに適したチャネルサーフェスを選択します
- チャネル間に条件ノードを追加して、エンゲージメントを確認します（例：「プロファイルがメールを開きましたか？」）。 代替チャネルにルーティングすることができます
Experience League ドキュメント
フェーズ 4：ガバナンスと最適化の設定
アプリケーション関数： AJO：頻度とビジネスルール、AJO：競合と優先度の管理、AJO：コンテンツ実験、RT-CDP：同意とガバナンスの適用
頻度の上限を適用してメッセージ過剰を防ぎ、他のアクティブなコミュニケーションとの競合解決に優先順位スコアを割り当て、オプションでジャーニーメッセージ内のA/B テストを設定し、同意の履行を検証します。
周波数キャップ設定の決定
ジャーニーメッセージはグローバルな頻度上限を尊重すべきですか？
優先スコアの割り当てを決定
他のアクティブなキャンペーンやジャーニーと比較して、このジャーニーをどのようにランク付けするべきですか？
コンテンツ実験の決定
ジャーニーメッセージにA/B テストや多変量テストを含めるべきですか？
UI ナビゲーション
- 頻度ルール：管理/ビジネス・ルール/ルールの作成
- 優先スコア：ジャーニープロパティ/優先スコア
- 競合検出：管理/ビジネス・ルール/競合と優先度
- コンテンツ実験：ジャーニーキャンバス/メッセージアクションを選択/コンテンツ実験トグル
- 同意ポリシー：プライバシー/ポリシー/同意ポリシー
主要な設定の詳細
- チャネル固有の配信頻度の上限を設定します（例：1週間あたり最大3通の電子メール、1日あたり最大1通のSMS、2回のプッシュ/日など）
- 他のアクティブなコミュニケーションに対するビジネスの重要性を反映する優先度スコアをジャーニー（0～100）に割り当てます
- 競合の検出パネルを確認して、重複するキャンペーンやジャーニーを特定します
- コンテンツ実験を行う場合、処理のバリエーションを定義し、トラフィック配分を設定し、成功指標（開封数、クリック数、コンバージョン数）を選択し、信頼度のしきい値（通常は95%）を設定します
- ジャーニーで使用される各チャネルについて、同意の適用がアクティブであることを確認します
Experience League ドキュメント
フェーズ 5: レポートと監視の設定
アプリケーション関数： AJO: Reporting & Performance Analysis、Monitoring & Observability、Reporting & Analysis
アクティベーション中とアクティベーション後のジャーニー実行を監視し、ステップごとの配信とエンゲージメント指標を確認できます。また、ジャーニー処理の失敗に対するアラートを設定できます。さらに、funnelの詳細なビジュアライゼーションとフォールアウトビジュアライゼーションを実現するCJA workspace analysisの構築も可能です。
レポート方法の決定
このジャーニーに必要なレポートツールは何ですか？
アラート設定の決定
トリガーアラートはどのようなジャーニーのエラーが必要ですか？
UI ナビゲーション
- ジャーニーライブレポート：ジャーニー/ジャーニーを選択/ライブレポート
- ジャーニーのすべての時間レポート：ジャーニー/ジャーニーを選択/すべての時間レポート
- アラート：アラート/アラートルール/購読
- CJA ワークスペース：プロジェクト/新規プロジェクトを作成
主要な設定の詳細
-
ジャーニーの実行中にライブレポートにアクセスし、プロファイルのエントリ、終了、ステップごとの配信指標をリアルタイムで監視できます
-
ジャーニーの完了後（または十分なデータが蓄積された後）、すべての時間レポートで包括的な分析を確認します
-
ジャーニー処理の失敗と配信の問題に対するプラットフォームアラートを設定します
-
CJA分析の場合、CJA接続にAJO エクスペリエンスイベントのデータセット（メッセージフィードバック、メールトラッキング、ジャーニーステップイベント）が含まれていることを確認します
-
次の機能を使用してCJA Workspaceを構築します。
- 各ジャーニーのステップでのプロファイル数を示すFunnelのビジュアライゼーション
- 離脱ポイントを特定するためのフォールアウトの可視化
- ステップ換算レート計算
- コンバージョンまでの時間の分析
- チャネルレベルのエンゲージメントの内訳（マルチチャネルジャーニー向け）
Experience League ドキュメント
実装に関する考慮事項
導入前と導入中に、次のガードレール、落とし穴、ベストプラクティス、トレードオフを確認しましょう。
ガードレールと制限
- サンドボックスあたりの最大500 ライブジャーニー — Journey Optimizer ガードレール
- 最大ジャーニー期間は91日 （グローバルタイムアウト）です。タイムアウト時にまだジャーニー内にあるプロファイルは自動的に終了されます
- ジャーニーキャンバスごとに最大 50 アクティビティ 個
- 1秒あたり最大20,000件のプロファイルを読み取るオーディエンスジャーニー処理 （デフォルトのスロットル）
- 単一イベントジャーニーは、サンドボックスごとに最大 5,000 イベント/秒 をサポートします
- オーディエンス読み取りジャーニーの待機ステップの最小期間は 1時間 です
- ジャーニー 再エントリ クールダウンの最小値は5分です
- サンドボックスごとにチャネルタイプ あたり最大 10 チャネルサーフェス
- 最適な配信品質を得るために、最大メールサイズの 100 KB をお勧めします
- メッセージあたり最大30 コンテンツフラグメント
- 実験ごとの最大10件のコンテンツ実験の処理 （バリエーション）数
- サンドボックスごとに最大10個のキャッピング設定
- サンドボックスごとに最大4,000個のセグメント定義
よくある落とし穴
- テストなしで公開： テストプロファイルを使用して常にテストモードを使用し、公開前にジャーニーパス全体を検証します。 プロファイルが期待される分岐をトラバースし、手順が正しく進むのを待ち、メッセージが適切にレンダリングされることを確認します。
- ブランチに終了アクティビティがありません：すべてのジャーニーブランチは、終了アクティビティで終了する必要があります。 任意のブランチが終了ノードなしで残っている場合、ジャーニーは公開できません。
- 過度に広範なエントリ条件：緩く定義されたエントリ オーディエンスまたはイベント条件は、意図しないプロファイルでジャーニーをフラッディングする可能性があります。 特定の属性チェックと抑制ルールを使用して、エントリ基準を調整します。
- 再入力ルールを無視しています： イベントがトリガーされたジャーニーの場合、プロファイルがトリガーイベントを複数回起動することがあります。 適切な再入力設定（再入力期間またはクールダウン期間を拒否）がないと、プロファイルがジャーニーに蓄積し、メッセージが重複する可能性があります。
- 待機ステップのタイムゾーンの混乱：待機期間はUTCで処理されます。 ジャーニープロパティでジャーニータイムゾーンを明示的に設定し、待機ステップが予想される現地時間に進むようにします。
- ライブジャーニーの編集： ライブジャーニーは直接編集できません。 変更を行うには、ジャーニーを複製し、コピーを修正し、元のバージョンを停止して、新しいバージョンを公開します。 本番稼働前にジャーニーのバージョン管理を計画します。
- 終了条件が定義されていません：終了条件がなければ、ジャーニーの途中でコンバージョンしたプロファイルは、その後もメッセージを受信し続けます。これは無関係または矛盾している可能性があります。 コンバージョンイベントの終了条件を常に設定します。
- チャネルの同意の不整合： プロファイルはメールにオプトインできますが、SMSにはオプトインできません。 マルチチャネルジャーニーでは、チャネルごとの同意を尊重する必要があります。 各チャネルサーフェスに同意フィールドが入力され、適用されていることを確認します。
ベストプラクティス
- シンプルに開始し、反復：複雑な分岐を追加する前に、線形の2 ～ 3 ステップのジャーニーで開始します。 条件とチャネルにレイヤー化する前に、コアフローの動作を検証します。
- わかりやすい命名規則を使用する： ジャーニーノード、条件、待機の手順を明確に指定します（例：「Wait 1」ではなく「Wait_3_Days_After_Welcome」など）。 これにより、テストモードのデバッグとレポートの解釈がはるかに簡単になります。
- 終了条件を早期に設定： ジャーニーパスを設計する前に、コンバージョンイベントを終了条件として定義します。 これにより、コンバージョンに至ったプロファイルは、どの段階であるかにかかわらず、ジャーニーから確実に削除されます。
- 有意義な待機時間を設定：顧客行動データのベース待機時間（一般的なインタラクション、期待される応答期間、チャネルに適した頻度の間の時間）（メール間で2 ～ 3日、SMS間で1週間など）。
- 条件ノードを使用してエンゲージメントを確認する： メッセージアクションの後、条件を追加して、プロファイルがエンゲージしたか（開封したか、クリックしたか）を確認します。 エンゲージメントしたプロファイルを1つのパスにルーティングし、エンゲージメントしていないプロファイルをエスカレーションまたは代替チャネルパスにルーティングします。
- 分岐に計算属性を活用する： エンゲージメントスコア、購入頻度、最後のアクティビティからの日数などの計算属性を使用して、任意ではなくデータにもとづいた分岐を決定します。
- 監視と最適化を繰り返し行います。最初の実行中は、ジャーニーレポートを毎週確認します。 脱落ポイントの特定、待機時間の調整、条件の調整、ステップごとのパフォーマンスデータにもとづくメッセージ内容の最適化を実現できます。
- ジャーニーのバージョン：変更を行う場合は、ジャーニーを複製して新しいバージョンを作成します。 監査と最適化の追跡のために、バージョン変更のログを管理します。
トレードオフの決定
以下のトレードオフは、お客様の特定のビジネス要件のコンテキストで評価する必要があります。
オーディエンス読み取りエントリとイベントトリガーエントリ
オーディエンス読み取りエントリは、予測可能なバッチベースの処理を提供し、管理とテストが容易になります。 イベントトリガー型エントリは、よりコンテキストに即したリアルタイムの応答性を提供しますが、ストリーミングインフラストラクチャと、より慎重な再エントリ管理が必要です。
- オーディエンス読み取りのメリット：予測可能性、大量の処理、スケジュールされたライフサイクルプログラム、簡単なテスト
- イベントをトリガーにしたメリット： リアルタイムの関連性、行動コンテキスト、個人プロファイルのペーシング、顧客の行動に対する即座の対応
- 推奨事項： タイミングがビジネス主導の予定ライフサイクルプログラム（オンボーディング、更新）にオーディエンス読み取りを使用します。 顧客主導のタイミングで行動を示すシーケンス（カート放棄、購入後）に、イベントトリガーを使用します。
シングルチャネルとマルチチャネルジャーニーの違い
シングルチャネルジャーニーは、導入、テスト、管理が容易です。 マルチチャネルジャーニーは、より広範なリーチとエスカレーション機能を提供しますが、コンテンツ作成、同意管理、頻度ガバナンスにおける複雑さが増します。
- 単一チャネルの利点：実装の高速化、同意管理の簡素化、コンテンツ制作の労力の軽減、デバッグの簡素化
- マルチチャネルのお気に入り： エンゲージメントの可能性が高まり、レスポンシブではないプロファイルのチャネルのエスカレーション、より包括的な顧客体験が得られます
- 推奨事項：単一チャネルのジャーニーから開始し、マルチチャネルに拡張する前に、フローとビジネスへの影響を検証します。 エンゲージメントデータから、主要なチャネルがオーディエンスに効果的にリーチしていないことが判明したチャネルを段階的に追加。
ジャーニーの複雑さと管理の容易性
多くの条件とパスを持つ、分岐の多いジャーニーは、より多くのシナリオに対応できますが、テスト、デバッグ、最適化が困難になります。 より少ない支店でよりシンプルなジャーニーを構築することで、管理は容易になりますが、パーソナライズされたエクスペリエンスが減少する可能性があります。
- 複雑なジャーニーに対応：詳細なパーソナライゼーション、セグメント固有のパス、包括的なシナリオカバレッジ
- よりシンプルなジャーニーのメリット：導入の高速化、テストの簡素化、レポートの明確化、メンテナンス負担の軽減
- 推奨事項： ジャーニーの上限は、主要な分岐が3 ～ 5個、アクティビティが15 ～ 25個です。 ロジックがより複雑な場合は、単一のモノリシックなジャーニーではなく、ジャーニー間の調整によって複数のジャーニーに分割することを検討してください。
頻度上限の厳格さとジャーニーの完了の比較
厳格な配信頻度の上限により、過剰なメッセージから保護されますが、ジャーニーのメッセージが抑制され、プロファイルのスキップやジャーニーの完了率の低下につながる可能性があります。 寛大な上限を設定することで、ジャーニーメッセージは配信されますが、チャネル疲れのリスクが高まります。
- 厳格な大文字の使用：顧客体験の保護、登録解除率の削減、ブランドの信頼
- Lenient caps favor: ジャーニー完了率、メッセージシーケンスの完全な配信、マーケティングプログラムの効果
- 推奨事項：重要なジャーニーメッセージ（オンボーディング、更新）に高い優先度スコアを割り当て、上限に達したときにプロモーション施策よりも優先されるようにします。 真に重要なコミュニケーションのみに「上限の適用から除外」します。
関連ドキュメント
以下のリソースでは、この実装で使用される機能に関する追加の詳細を提供します。