このページ：では、ライブジャーニーの実行をトラブルシューティングする方法について説明します。これには、イベントの送信、ジャーニーへのプロファイルの入力と進行状況の確認、メッセージの配信の確認などが含まれます。
この節では、ジャーニーイベントのトラブルシューティングを行う方法と、プロファイルがジャーニーにエントリしたかどうか、プロファイルがジャーニーをどのように移動したか、メッセージが送信されたかどうかを確認する方法について説明します。
また、ジャーニーをテストまたは公開する前に、エラーのトラブルシューティングを行うこともできます。 方法について詳しくは、このページを参照してください。
インバウンドアクションを使用している場合、トラブルシューティングを行う方法について詳しくは、このページを参照してください。
イベントが適切に送信されているかを確認 checking-that-events-are-properly-sent
ジャーニーの開始点は常にイベントです。 Postman などのツールを使用してテストを実行できます。
これらのツールを介して送信する API 呼び出しが正しく送信されているかどうかを確認できます。 エラーが返された場合は、呼び出しに問題があるということです。 ペイロード、ヘッダー（特に組織 ID）、宛先の URL を再度確認します。 ヒットするのに適した URL を管理者に問い合わせることができます。
イベントは、ソースからジャーニーに直接プッシュされるわけではありません。 実際、ジャーニーはAdobe Experience Platformのストリーミング取得APIに依存しています。 その結果、イベントに関連する問題が発生した場合は、ストリーミング取り込みAPIのトラブルシューティングに関するAdobe Experience Platform ドキュメント を参照できます。
ジャーニーでエラー ERR_MODEL_RULES_16 が発生してテストモードを有効にできない場合は、チャネルアクションを使用する際に、使用するイベントに ID 名前空間が含まれていることを確認してください。
ID 名前空間は、テストプロファイルを一意に識別するために使用されます。 例えば、メールを使用してテストプロファイルを識別する場合は、ID 名前空間の メール を選択する必要があります。 一意の識別子が電話番号の場合は、ID 名前空間の 電話 を選択する必要があります。
ジャーニーへのエントリを確認 checking-if-people-enter-the-journey
ジャーニーレポートでは、ジャーニーへのエントリをリアルタイムで測定します。
イベントが正常に送信されたにもかかわらず、ジャーニーへのエントリが確認できない場合、ジャーニーのイベント送信とイベント受信の間に何か問題があるということです。
次の質問に従って、トラブルシューティングを開始できます。
-
イベントを受信するジャーニーが、テストモードまたはライブになっているか。
-
ペイロードプレビューからペイロードをコピーする前にイベントを保存したか。
-
イベントペイロードにイベント ID が含まれているか。
-
正しい URL をヒットしたか。
-
イベント設定ペインのペイロード構造プレビューを使用して、ストリーミング取得 API のペイロード構造に従ったか。 詳しくは、このページを参照してください。
-
イベントのヘッダーで正しいキーと値のペアを使用しましたか？
code language-none X-gw-ims-org-id - your organization's ID Content-type - application/json -
イベント条件とスキーマデータタイプ - イベント条件（ルール）で使用されるデータタイプがイベントスキーマと一致していることを確認します。 一致しないタイプ（文字列と整数など）は、ルール評価が失敗し、イベントがドロップされます。 イベント IDの確認を参照してください。
-
イベントが破棄されました – 資格条件が満たされていません - ルールベースのイベントの場合、資格条件がイベントペイロードによって満たされていない場合（例えば、必須フィールドが空または不足している、またはフィールドの
isNotEmptyなどの条件が失敗した場合）、イベントは受信されましたが破棄されました、ジャーニーはトリガーされません。 ログとSplunk トレースは、イベントが受信されたが、資格条件を満たしていないため破棄されたことを示します。破棄コードはnotSuitableInitialEventです。 これは想定される動作です。資格条件が満たされない場合、イベントは破棄され、そのプロファイルに対してジャーニーがトリガーされません。 イベントペイロードに期待されるフィールドと値が含まれており、イベント設定のルールが送信するデータと一致することを確認します。 イベントが別のジャーニーから カスタムアクション によってトリガーされた場合は、「 カスタムアクションのトラブルシューティングにおける破棄イベントとアイドルタイムアウト の処理」を参照してください。
>>
ストリーミングオーディエンスを含むオーディエンスの選定ジャーニーの場合：オーディエンスの選定アクティビティをジャーニーのエントリポイントとして使用している場合、タイミング要因、オーディエンスからの迅速な退出、プロファイルが公開前にオーディエンス内に既に存在していたなどの理由により、オーディエンスに選定されたすべてのプロファイルが必ずしもジャーニーにエントリするわけではありません。 詳しくは、ストリーミングオーディエンスの選定のタイミングに関する考慮事項を参照してください。
イベント IDの確認 verify-event-identity-and-rule-data-types
イベントベースのジャーニーを設定する際に、ペイロードのID フィールドが、イベント 🔗で選択した名前空間と一致することを確認します。 イベントにプロファイルマッチング用のフィールドが含まれる場合は、イベント条件の 文字ケース と データタイプ がインバウンドデータと完全に一致することを確認します。 例えば、イベントスキーマがroStatusを文字列として定義している場合、ジャーニールールはそれを文字列として評価する必要があります。 データ型が一致しない（文字列と整数など）場合、ルールの評価が失敗し、有効なイベントがドロップされます。 同様に、イベントに 選定の条件 がある場合（例えば、フィールドが空でない必要があります）、その条件を満たさないイベントは破棄され、ジャーニーをトリガーしません。ログにはnotSuitableInitialEventなどの破棄コードが表示される場合があります。
Journey Optimizerでイベント条件を検証するには、イベント設定でペイロードプレビューを使用し、ルールのタイプと値がペイロード構造と一致することを確認します。 ペイロードを プレビューおよび ルールベースのイベントを設定する方法について説明します。
テストモードの移行のトラブルシューティング troubleshooting-test-transitions
テストモードでテストプロファイルがジャーニーの進行に失敗した場合や、視覚的なフローにステップの進行を示す緑色の矢印が表示されない場合、問題は移行の検証に関連していることがあります。 この節では、一般的なテストモードの問題の診断と解決に関するガイダンスについて説明します。
テストプロファイルが進行しない
テストプロファイルがジャーニーにエントリしたが、最初のステップを超えて進まない場合は、次の点を確認してください。
-
ジャーニーの開始日 - 最も一般的な原因は、ジャーニーの開始日が今後に設定されている場合です。 現在の時間がジャーニーで設定された開始日と終了日/時間 ウィンドウの外にある場合、テストプロファイルはすぐに破棄され、ログエントリは
DISPATCHER DISCARD #16 — unqualified on journey version enablementsになります。 解決するには：- ジャーニーの開始日が今後に設定されていないことを確認します
- 現在の時刻がジャーニーのアクティブな日付ウィンドウ内にあることを確認します
- 必要に応じて、開始日を現在の瞬間より前の時間に一時的に設定してテストを行い、公開前に復元します
-
テストプロファイル設定 - プロファイルがAdobe Experience Platformでテストプロファイルとして正しくフラグ付けされていることを確認します。 詳しくは、テストプロファイルの作成方法を参照してください。
-
ID名前空間の不一致 – 名前空間の不一致により、サイレント ドロップが発生します。イベントは受け入れられ、成功応答が返されますが、プロファイルはジャーニーに入らず、エラーはUIに表示されません。 プロファイル識別子の名前空間が、イベントスキーマで定義されている名前空間と正確に一致することを確認します（大文字と小文字を区別します）。 詳細については、 プロファイル ID式の形式を参照してください。
Null トランジション指標
技術的なトラブルシューティング中に、ジャーニーの技術的な詳細で isValidTransition プロパティが null に設定されている場合があります。 この UI 専用プロパティは、バックエンドの処理やジャーニーのパフォーマンスには影響しません。 ただし、null 値は次を示す場合があります。
- ジャーニーの設定ミス - ジャーニーの開始日が今後に設定されているので、テストイベントが通知なしで破棄されます。
- 破損したトランジション - まれに、ジャーニーノードを再接続する必要がある場合があります
永続的な移行の問題が発生する場合：
- ジャーニーの開始日が最新であることを確認します
- テストモードの非アクティブ化と再アクティブ化
- 問題が解決しない場合は、影響を受けるジャーニーノードを複製し、再接続することを考慮します
- 未解決のケースについては、ジャーニーログ、影響を受けるプロファイル ID、null トランジションの詳細を サポート にお問い合わせください
DISPATCHER DISCARD #16 — unqualified on journey version enablementsとUI エラーなしでサイレントに破棄されます。 テストプロファイルの進行をトラブルシューティングする際は、常に最初にジャーニーのタイミング設定を確認します。ジャーニーの進行状況を確認 checking-how-people-navigate-through-the-journey
ジャーニーレポートは、ジャーニーでの個人の進行状況を測定します。 ユーザーがどこで、なぜ停止したのかを容易に特定できます。
以下に、確認すべき点をいくつか示します。
- 停止の原因が、該当するユーザーを除外する条件であるか。 例えば、条件が「性別 = 男性」で、ユーザーが女性の場合。 このチェックは、条件が複雑すぎない場合、ビジネスユーザーが実行できます。
- データソースへの呼び出しが応答しないためか。 この情報は、ジャーニーのテスト中にテストモードログに表示されます。 このジャーニーがライブになると、管理者はデータソースへの直接呼び出しをテストし、受け取った回答を確認できます。 管理者は、このジャーニーを複製してテストすることもできます。
ジャーニーインスタンスがブロックされたために破棄されたイベント max-instance-stack-events-reached
maxInstanceStackEventsReachedの理由で破棄されたイベントが表示された場合、ジャーニーランタイムは、特定のジャーニーバージョンのプロファイルごとのイベントスタックの内部制限である10 イベントに達しました。 これは、同じプロファイルの別のイベントがまだ処理中である間に、保留中のイベントが積み重なるのを防ぐ安全ガードレールです。
これは、時間枠またはスループットの制限として not です。 これは、プロファイルのジャーニーインスタンスが長時間実行中のステップ（長時間待機、エンリッチメント、カスタムアクションの再試行など）でブロックされ、同じプロファイルのイベントがジャーニーでも使用され、イベントの上限10を超えて積み重ねられるときに発生します。
それを識別するには、破棄の理由がmaxInstanceStackEventsReachedに等しいジャーニーステップイベントをクエリします（例：serviceEvents.stateMachine.eventTypeまたは同様のフィールド）。 破棄されたイベントタイプについて詳しくは、 ステップイベントフィールドリスト を参照してください。
実行できること
- 長い待ち時間や、頻繁に再トリガーされる可能性のあるパスのステップを減らします。
- 可能な場合は、アップストリームイベントの重複を排除するか、離脱します。
- 長時間実行しているシナリオを複数のジャーニーに分割し、積み重ねないようにします。
メッセージが正常に送信されたかを確認 checking-that-messages-are-sent-successfully
個人がジャーニーを適切に進んでいるのに、受信すべきメッセージが届いていない場合は、以下の点を確認します。
- Journey Optimizer がメッセージの送信リクエストを正しく認識している。 ビジネスユーザーは、送信すべきメッセージにアクセスできます。また、最新の実行時刻がジャーニーの実行時刻と一致するかどうかを確認できます。 また、受け取った最新の API 呼び出しやイベントも確認できます。
- Journey Optimizer が正常にメッセージを送信している。 ジャーニーレポートを調べ、エラーがないことを確認します。
カスタムアクションを介して送信されたメッセージの場合、ジャーニーテストで確認できるのは、カスタムアクションのシステムを呼び出すことでエラーが発生するかどうかだけです。 カスタムアクションに関連付けられた外部システムへの呼び出しがエラーにならず、それでもメッセージが送信されない場合は、外部システム側で調査する必要があります。
sentやbounceなどの配信ステータスを確認します。 カスタムアクションの場合は、ジャーニーステップイベントデータセットをクエリして、Journey Optimizerがアクションを正常に実行したことを確認します。成功したHTTP呼び出しだけでは、外部システムがメッセージを配信したことを確認することはできません。 ユースケースに適したデータセット 🔗を選択する方法について説明します。ジャーニーステップイベントの重複エントリについて duplicate-step-events
この節では、ジャーニーステップイベントに重複する行が表示される理由を説明します。
同じジャーニーインスタンス、プロファイル、ノード、リクエスト IDを持つ複数のエントリが表示されるのはなぜですか？
ジャーニーステップイベントデータに対してクエリを実行する際に、同じジャーニー実行に対して重複ログエントリのように表示されるものが確認される場合があります。 これらのエントリは、次の項目について同じ値を共有します。
profileID- プロファイル IDinstanceID- ジャーニーインスタンス識別子nodeID- 特定のジャーニーノードrequestID- リクエスト識別子
ただし、これらのエントリには 異なる _id 値 があり、これがこのシナリオを実際のデータ重複と区別する主なインジケーターとなります。
この動作の原因は何ですか？
これは、Adobe Journey Optimizerのマイクロサービスアーキテクチャにおけるバックエンドの自動スケーリング操作（「リバランス」とも呼ばれます）が原因で発生します。 負荷が高い期間またはシステムが最適化されている期間：
- ジャーニーステップイベントの処理が開始され、ジャーニーステップイベントデータセットに記録されます
- 自動スケーリング操作により、サービスインスタンス間でワークロードが再配分されます
- 同じイベントが別のサービスインスタンスにより再処理され、異なる
_idを持つ 2 番目のログエントリが作成される場合があります
これは、想定されたシステム動作で、ザインどおりに動作しています。
ジャーニーの実行やメッセージの配信に影響はありますか？
No. 影響はログ記録のみに限定されます。 Adobe Journey Optimizerには、メッセージ実行レイヤーに次の機能を備えた重複排除メカニズムが組み込まれています。
- 1つのメッセージ（メール、SMS、プッシュ通知など）のみ 各プロファイルに送信されます
- アクションは 1 回のみ実行されます
- ジャーニーの実行は正しく進行します
これを確認するには、ajo_message_feedback_event_dataset に対してクエリを実行するか、アクション実行ログを確認します。ジャーニーステップイベントエントリが重複しているにもかかわらず、実際に送信されたメッセージは 1 つのみであることがわかります。
クエリでこれらのケースを特定するにはどうすればよいですか？
ジャーニーステップイベントデータを分析する場合：
-
_idフィールドを確認：真のシステムレベルの重複では_idが同じです。_id値が異なる場合は、上記のリバランスシナリオとは異なるログエントリであることを示します。 -
メッセージの配信を確認：メッセージフィードバックデータと相互参照して、1 つのメッセージのみが送信されたことを確認します。
code language-sql SELECT timestamp, _experience.customerJourneyManagement.messageExecution.messageExecutionID, _experience.customerJourneyManagement.messageDeliveryfeedback.feedbackStatus FROM ajo_message_feedback_event_dataset WHERE _experience.customerJourneyManagement.messageExecution.journeyVersionID = '<journeyVersionID>' AND TO_JSON(identityMap) like '%<profileID>%' ORDER BY timestamp DESC; -
一意の識別子でグループ化：実行をカウントする際は、正確なカウントを取得するために
_idを使用します。code language-sql SELECT COUNT(DISTINCT _id) as unique_executions FROM journey_step_events WHERE _experience.journeyOrchestration.stepEvents.journeyVersionID = '<journeyVersionID>' AND _experience.journeyOrchestration.stepEvents.profileID = '<profileID>'
これを確認した場合はどうすればよいですか？
これは、通常のシステム動作で、アクションは不要です。 重複したログは、ジャーニー設定やメッセージ配信に問題があることを示すものではありません。
ジャーニーステップイベントに基づいてレポートや分析を作成している場合：
- 一意のイベントをカウントするプライマリキーとして
_idを使用します - メッセージ配信を分析する際は、メッセージフィードバックデータセットと相互参照します
- タイミング分析では、エントリが相互に数秒以内にクラスター化して表示される場合があります
ジャーニーステップイベントのクエリについて詳しくは、クエリの例を参照してください。
ダッシュボードの指標の不一致に関するトラブルシューティング dashboard-metrics
概要ダッシュボードに表示される指標が「参照」タブの実際のジャーニー数と一致しない場合は、次の点を確認してください。
- 最近のアクティビティがないジャーニーはダッシュボードから除外されるので、該当するジャーニーに過去 24 時間以内にトラフィックが含まれていたことを確認します。
- 組織内のすべてのジャーニーを表示する適切なアクセス権限があることを確認します。
- ジャーニーに変更を行った後、指標が更新されるまで最大 30 分かかります。
矛盾が解決しない場合は、「概要」タブと「参照」タブの両方のスクリーンショットを使用して、Adobe サポート にお問い合わせください。
クローズしたジャーニーの空のプレースホルダーを表示するトラッキングパラメーター tracking-parameters-closed-journeys
送信済みメールのトラッキング URLにcid=em-acou-adob{}などの空のプレースホルダーが含まれている場合は、context.system.source.actionIdなどのコンテキストフィールドを解決できなかったことを示している可能性があります。 これは通常、ジャーニーが閉じられ、関連する製品の変更後に再公開されなかった場合に発生します。再公開されたジャーニーのみが、トラッキング URLにこれらのコンテキストフィールドに正しく入力されます。
これを解決するには、ジャーニーを再公開するか（新しいバージョンを作成して公開）、またはチャネル設定またはメールコンテンツのURL トラッキングパラメーターから影響を受けるコンテキストフィールドへの参照を削除します。
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page is a comprehensive troubleshooting reference for live journey execution in Adobe Journey Optimizer, covering event delivery, profile entry failures, test mode transition issues, discarded events, duplicate step event logs, message delivery checks, and dashboard metric discrepancies.
Intents:
- Diagnose why events are not triggering journey entry by checking payload structure, headers, and qualification conditions
- Verify whether profiles are entering and progressing through a live or test-mode journey
- Resolve test mode transition failures caused by future start dates or misconfigured identity namespaces
- Understand and handle the
maxInstanceStackEventsReacheddiscard reason for blocked journey instances - Identify and correctly query duplicate Journey Step Event log entries caused by backend auto-scaling
- Investigate missing messages by checking journey reporting and custom action call results
- Fix empty tracking URL placeholders in emails from closed journeys
Glossary:
- Journey Step Events: A dataset that logs each step a profile executes within a journey, used for reporting and debugging (product-specific)
- notSuitableInitialEvent: A discard code indicating an event was received but dropped because the qualification condition was not met (product-specific)
- maxInstanceStackEventsReached: A discard code indicating the per-profile journey instance event stack limit of 10 has been exceeded (product-specific)
- isValidTransition: A UI-only property in journey technical details; a null value may indicate a future start date or corrupted node connection, but does not affect backend processing (product-specific)
- Qualification condition: A rule defined on an event that must be satisfied for the event to trigger a journey; events failing this condition are discarded
- Rebalancing: A backend auto-scaling operation in AJO microservices that can create duplicate Journey Step Event log entries with different
_idvalues
Guardrails:
- Events sent outside the journey’s active date/time window are silently discarded with no error message
- The per-profile journey instance event stack limit is 10 events; exceeding this causes events to be discarded with
maxInstanceStackEventsReached - Duplicate Journey Step Event entries with different
_idvalues are expected system behavior and do not indicate message duplication - Dashboard Overview metrics only include journeys with traffic in the last 24 hours; metrics may take up to 30 minutes to refresh
- Closed journeys that have not been republished after a product change may produce empty placeholders in tracking URLs
Terminology:
- Canonical name: Journey Step Events — Acronym: none — variants: step events, journey execution logs
- Canonical name: Qualification condition — Acronym: none — variants: event qualification rule, event condition
- Synonyms: “rebalancing” = “auto-scaling” (backend operation causing duplicate log entries)
- Do not confuse: “duplicate
_id” ≠ “duplicate log entries from rebalancing” — true duplicates share the same_id; rebalancing duplicates have different_idvalues
FAQ:
- Q: Why are my events not triggering a journey even though they are being sent successfully? — Check that the journey is live or in test mode, the payload matches the event schema structure, the qualification condition is satisfied, and the correct headers (
X-gw-ims-org-id,Content-type) are included. - Q: Why do test profiles enter the journey but not advance past the first step? — The most common cause is a journey start date set in the future; events are silently discarded outside the active date window. Also verify the test profile flag and identity namespace match.
- Q: What does
maxInstanceStackEventsReachedmean? — The journey runtime has hit the internal 10-event stack limit for a specific profile instance, typically because a long-running step is blocking processing. Reduce long waits, deduplicate upstream events, or split the scenario into multiple journeys. - Q: I see duplicate rows in Journey Step Events — is something wrong? — No. Duplicate entries with different
_idvalues are expected and result from backend auto-scaling. Only one message is actually sent; verify with theajo_message_feedback_event_dataset. - Q: Why do tracking URLs in emails show empty placeholders like
cid=em-acou-adob{}? — The journey was closed and not republished after a product change; context fields cannot be resolved. Republish the journey or remove the affected context field reference from the URL tracking parameters. - Q: Why does the Overview dashboard show different numbers than the Browse tab? — The dashboard only counts journeys with traffic in the last 24 hours, metrics take up to 30 minutes to refresh, and access permissions may limit visibility.