文件Journey OptimizerJourney Optimizer 指南

疑難排解您的即時歷程執行 troubleshooting-execution

最後更新： 2026年9月22日
  • 適用對象：
  • Journey Orchestration

建立對象：

  • 中繼
  • 使用者

在此頁面上：​瞭解如何疑難排解即時歷程的執行，包括驗證是否已傳送事件、確認設定檔已進入並透過歷程進行，以及檢查是否已傳送訊息。

style
shade-box

在本節中，瞭解如何疑難排解歷程事件、檢查設定檔是否進入您的歷程、如何導覽歷程，以及是否傳送訊息。

您也可以在測試或發佈歷程之前疑難排解錯誤。 在此頁面🔗上瞭解如何。

如果您使用輸入動作，請在此頁面🔗瞭解如何疑難排解。

檢查是否已正確傳送事件 checking-that-events-are-properly-sent

歷程的起點永遠是一個事件。 您可以使用 Postman 等工具執行測試。

您可以檢查您透過這些工具傳送的 API 呼叫是否已正確傳送。 如果您收到錯誤，則表示您的呼叫發生問題。 再次檢查有效負載、標題（特別是組織 Id）和目的地 URL。 您可以諮詢管理員哪個是要點擊的正確 URL。

不會直接將事件從來源推送到歷程。 事實上，歷程依賴Adobe Experience Platform的串流獲取API。 因此，如果發生與事件相關的問題，您可以參閱Adobe Experience Platform 檔案以疑難排解串流獲取API。

如果您的歷程無法啟用測試模式，錯誤為ERR_MODEL_RULES_16，請確定使用的事件包含使用通道動作時的身分名稱空間。

身分名稱空間會用於唯一識別測試設定檔。 例如，如果使用電子郵件來識別測試設定檔，則應選取身分名稱空間​電子郵件。 如果唯一識別碼是電話號碼，則應該選取識別名稱空間​電話。

檢查是否有人進入歷程 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

  • 事件條件和結構描述資料型別 — 請確定事件條件（規則）中使用的資料型別符合事件結構描述。 不相符的型別（例如，字串與整數）會導致規則評估失敗並捨棄事件。 請參閱驗證事件身分。

  • 已捨棄事件 — 不符合資格條件 — 對於規則型事件，如果事件裝載不符合​資格條件 （例如，必要欄位空白或遺失，或欄位上的條件isNotEmpty失敗），則事件為​已接收但已捨棄，且未觸發歷程。 記錄檔和Splunk追蹤可顯示已接收事件但已捨棄該事件，因為它不符合資格條件，並含有捨棄程式碼，例如notSuitableInitialEvent。 這是預期行為：若不符合資格條件，將會捨棄事件，且不會為該設定檔觸發歷程。 確認事件裝載包含預期的欄位和值，並確認事件設定中的規則符合您傳送的資料。 如果事件是由另一個歷程的​ 自訂動作 ​所觸發，請參閱自訂動作疑難排解中的處理捨棄事件和閒置逾時。

​>>
針對具有串流對象的對象資格歷程：如果您使用對象資格活動作為歷程進入點，請注意，由於時間因素、對象快速退出，或設定檔在發佈前已在對象中，並非所有符合對象資格的設定檔都一定會進入歷程。 深入瞭解串流對象資格計時考量事項。

驗證事件身分 verify-event-identity-and-rule-data-types

設定事件型歷程時，請確認裝載的身分欄位符合在事件🔗中選取的名稱空間。 如果事件包含設定檔比對的欄位，請驗證事件條件中的​ 字母大小寫 ​和​ 資料型別 ​是否完全符合傳入資料。 例如，如果事件結構描述將roStatus定義為字串，則歷程規則也必須將其評估為字串。 不相符的資料型別（例如，字串與整數）會導致規則評估失敗，並捨棄有效事件。 同樣地，如果事件具有​資格條件 （例如，欄位必須是非空白的），則不符合該條件的事件為​捨棄，且不會觸發歷程；記錄檔可能會顯示捨棄的程式碼，例如notSuitableInitialEvent。

若要在Journey Optimizer中驗證您的事件條件，請在事件設定中使用裝載預覽，並確保規則中的型別和值符合裝載結構。 瞭解如何預覽承載和設定規則型事件。

測試模式轉換疑難排解 troubleshooting-test-transitions

如果測試設定檔在測試模式下無法通過您的歷程，或視覺流程未顯示指示步驟進度的綠色箭頭，則此問題可能與轉變驗證有關。 本節提供診斷和解決常見測試模式問題的指引。

測試設定檔未進行中

如果測試設定檔進入歷程但未前進通過初始步驟，請檢查以下內容：

  • 歷程開始日期 — 最常見的原因是歷程的開始日期設定在未來。 如果目前時間在歷程設定的開始和結束日期/時間視窗之外，產生記錄專案： DISPATCHER DISCARD #16 — unqualified on journey version enablements，則會立即捨棄測試設定檔。 若要解決：

    • 確認歷程開始日期未設定在未來
    • 確保目前時間在歷程的有效日期範圍內
    • 如有必要，請將開始日期暫時設定為目前時間之前的測試時間，然後在發佈之前還原

  • 測試設定檔組態 — 確認設定檔在Adobe Experience Platform中被正確標示為測試設定檔。 如需詳細資訊，請參閱如何建立測試設定檔。

  • 身分名稱空間不符 — 名稱空間不符會導致無訊息下降：事件被接受並傳回成功回應，但設定檔從未進入歷程，且UI中未出現任何錯誤。 請確定​ 設定檔識別碼 ​中的名稱空間完全符合事件結構描述中定義的名稱空間（區分大小寫）。 如需詳細資訊，請參閱設定檔識別碼運算式格式。

Null轉變指標

在技術疑難排解期間，您可能會在歷程的技術詳細資料中遇到設定為null的isValidTransition屬性。 此僅限UI的屬性不會影響後端處理或歷程效能。 但是，null值可以表示：

  • 歷程設定錯誤 — 歷程開始日期設定在未來，導致測試事件被無訊息捨棄
  • 已損毀的轉換 — 在極少數情況下，可能需要重新連線歷程節點

如果您遇到持續的轉換問題：

  1. 確認歷程開始日期為目前日期
  2. 停用及重新啟用測試模式
  3. 如果問題仍然存在，請考慮複製受影響的歷程節點並重新連線它們
  4. 對於未解決的情況，聯絡支援人員並提供歷程記錄、受影響的設定檔ID以及有關null轉變的詳細資訊
NOTE
在歷程的有效日期視窗之外傳送的事件，會以記錄專案DISPATCHER DISCARD #16 — unqualified on journey version enablements自動捨棄，且不會出現UI錯誤。 疑難排解測試設定檔進度時，務必先驗證您的歷程計時設定。

檢查人們如何導覽歷程 checking-how-people-navigate-through-the-journey

歷程報告會衡量歷程中個人的進度。 可輕鬆識別人員停止的位置及原因。

以下是一些要檢查的事項：

  • 是否是因為某個條件排除此人？ 例如，條件是 “gender = male”，但人員是女性。 如果條件並非太複雜，則可由業務使用者執行此檢查。
  • 是否是因為呼叫資料來源未回應？ 當歷程處於測試模式時，可在測試模式日誌中看到此資訊。 當歷程為啟用狀態時，管理員可測試直接呼叫資料來源並檢查收到的答案。 管理員也可以複製歷程並進行測試。

由於封鎖歷程執行個體，已捨棄事件 max-instance-stack-events-reached

如果您看到以maxInstanceStackEventsReached原因捨棄的事件，表示歷程執行階段已達到其內部每個設定檔事件棧疊限制，即特定歷程版本的10個事件。 這是安全護欄，可防止當相同設定檔的另一個事件仍在處理中時，棧疊過多待處理事件。

這是​ 不是 ​時間範圍或輸送量限制。 當設定檔的歷程執行個體在長時間執行的步驟（例如，長時間等待、擴充或自訂動作重試）上遭到封鎖，以及相同設定檔（也用於該歷程）的事件累積超過10個事件的限制時，就會發生這種情況。

若要識別，查詢捨棄原因等於maxInstanceStackEventsReached的歷程步驟事件（例如，serviceEvents.stateMachine.eventType或類似欄位中）。 在步驟事件欄位清單中進一步瞭解捨棄的事件型別。

您可以做什麼

  • 減少可能頻繁重新觸發的路徑上的長時間等待或緩慢步驟。
  • 儘可能刪除重複或取消退回上游事件。
  • 將長期執行的情境分割為多個歷程，以避免棧疊。

檢查訊息是否成功傳送 checking-that-messages-are-sent-successfully

如果個人在歷程中的進度正常，但沒有收到應接收的訊息，您可以檢查：

  • Journey Optimizer已正確考慮傳送郵件的要求。 業務使用者可以存取應傳送的訊息，並檢查最新執行的時間是否與歷程的執行時間對應。 他們也可以檢查收到的最新API呼叫/事件。
  • Journey Optimizer已成功傳送訊息。 檢查歷程報告以確定沒有錯誤。

若是透過自訂動作傳送訊息，在歷程測試期間唯一可以檢查的事項，就是自訂動作系統的呼叫是否會導致錯誤。 如果呼叫與自訂動作相關聯的外部系統並未導致錯誤，但並未導致訊息傳送，則應在外部系統端進行一些調查。

NOTE
對於原生Journey Optimizer頻道動作，請查詢訊息回饋事件資料集以確認傳遞狀態，例如sent或bounce。 在Adobe Journey Optimizer中，sent是成功訊息傳遞結果的相關狀態；delivered值未用於Adobe Journey Optimizer訊息回饋事件資料集。 對於自訂動作，請查詢歷程步驟事件資料集，以確認Journey Optimizer已成功執行動作 — 成功的HTTP呼叫本身不會確認外部系統已傳送訊息。 瞭解如何為您的使用案例選擇正確的資料集。

瞭解歷程步驟事件中的重複專案 duplicate-step-events

請利用本節瞭解為什麼重複列會出現在歷程步驟事件中。

為什麼會看到多個具有相同歷程例項、設定檔、節點和請求ID的專案？

查詢歷程步驟事件資料時，您可能會偶爾觀察同一歷程執行的重複記錄專案。 這些專案會針對以下專案共用相同的值：

  • profileID — 設定檔身分
  • instanceID — 歷程執行個體識別碼
  • nodeID — 特定歷程節點
  • requestID — 要求識別碼

但是，這些專案有​個不同的_id值，這是區分此案例與實際資料複製的關鍵指標。

導致此行為的原因是什麼？

這是因為Adobe Journey Optimizer的微服務架構中的後端自動縮放作業（也稱為「重新平衡」）所導致。 在高負載或系統最佳化期間：

  1. 歷程步驟事件開始處理並記錄到歷程步驟事件資料集
  2. 自動縮放作業會重新分配各服務執行處理的工作負載
  3. 另一個服務執行個體可能會重新處理相同的事件，以不同的_id建立第二個記錄專案

這是預期的系統行為，且​運作方式符合設計。

對歷程執行或訊息傳送是否有任何影響？

編號 影響僅限於記錄。 Adobe Journey Optimizer在訊息執行層具有內建的重複資料刪除機制，可確保：

  • 只有一個訊息（電子郵件、簡訊、推播通知等） 會傳送至每個設定檔
  • 動作只會執行一次
  • 歷程執行正確進行

您可查詢ajo_message_feedback_event_dataset或檢查動作執行記錄來驗證此訊息 — 即使有重複的歷程步驟事件專案，您仍會看到實際只傳送了一則訊息。

如何在查詢中識別這些案例？

分析歷程步驟事件資料時：

  1. 檢查_id欄位： True系統層級重複專案會有相同的_id。 不同的_id值表示與上述重新平衡案例不同的記錄專案。

  2. 確認訊息傳送：與訊息回饋資料互動參照，以確認只傳送了一則訊息：

    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;

  3. 依唯一識別碼群組：計算執行次數時，請使用_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追蹤引數移除受影響內容欄位的參考。

AI Knowledge Reference

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 maxInstanceStackEventsReached discard 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 _id values

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 _id values 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 _id values

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 maxInstanceStackEventsReached mean? — 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 _id values are expected and result from backend auto-scaling. Only one message is actually sent; verify with the ajo_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.
recommendation-more-help
journey-optimizer-help