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

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

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

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

如果您使用傳入動作,請在疑難排解歷程中的傳入動作中瞭解如何疑難排解這些動作。

檢查是否已正確傳送事件 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

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

測試設定檔未進行中 test-profiles-not-progressing

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

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

    • 確認歷程開始日期未設定在未來
    • 確保目前時間在歷程的有效日期範圍內
    • 如有必要,請將開始日期暫時設定為目前時間之前的測試時間,然後在發佈之前還原
  • 測試設定檔組態 — 確認設定檔在Adobe Experience Platform中被正確標示為測試設定檔。 如需詳細資訊,請參閱如何建立測試設定檔。

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

Null轉變指標 null-transition-indicators

在技術疑難排解期間,您可能會在歷程的技術詳細資料中遇到設定為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”,但人員是女性。 如果條件並非太複雜,則可由業務使用者執行此檢查。
  • 是否是因為呼叫資料來源未回應? 當歷程處於測試模式時,可在測試模式日誌中看到此資訊。 當歷程為啟用狀態時,管理員可測試直接呼叫資料來源並檢查收到的答案。 管理員也可以複製歷程並進行測試。
TIP
您也可以在同事中使用​ 追蹤歷程設定檔 ​技能來調查已發佈的歷程。 詢問進入每個節點的設定檔數,以及這些設定檔在分支中的分割方式、哪些設定檔發生錯誤及原因,或單一設定檔遵循的路徑。 進一步瞭解歷程的同事技能

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

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

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

若要識別,查詢捨棄原因等於maxInstanceStackEventsReached的歷程步驟事件(例如,serviceEvents.stateMachine.eventType或類似欄位中)。 在步驟事件欄位清單中進一步瞭解捨棄的事件型別。 如需歷程步驟事件的欄位,請參閱Adobe Journey Optimizer結構描述參考。

您可以做什麼

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

檢查訊息是否成功傳送 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的專案? duplicate-entries-why

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

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

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

導致此行為的原因是什麼? duplicate-entries-cause

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

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

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

對歷程執行或訊息傳送是否有任何影響? duplicate-entries-impact

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

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

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

如何在查詢中識別這些案例? duplicate-entries-queries

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

  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>'
    

如果我觀察到此現象該怎麼辦? duplicate-entries-action

這是正常的系統行為,不需要任何動作。 重複的記錄並不表示您的歷程設定或訊息傳送有問題。

如果您是根據歷程步驟事件建置報表或分析:

  • 使用_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 troubleshooting reference for live journey execution in Adobe Journey Optimizer, covering event delivery, profile entry, test mode transition issues, discarded events, duplicate journey step event entries, message delivery checks, dashboard metric discrepancies, and empty tracking parameter placeholders.

Intents:

  • Diagnose why events are not entering a journey by checking payload structure, headers, event condition data types, and qualification conditions
  • Verify whether profiles are entering and progressing through a journey in test mode or live
  • Resolve test profiles that do not progress, using the journey start date, test profile configuration, and identity namespace checks
  • Understand and handle the maxInstanceStackEventsReached discard reason for blocked journey instances
  • Identify and correctly query duplicate Journey Step Events entries that have different _id values
  • Investigate missing messages by checking journey reporting, message feedback, and custom action call results
  • Fix empty tracking URL placeholders in emails from closed journeys

Glossary:

  • Journey Step Events: The dataset to which journey step events are logged; queried to find discard reasons and duplicate rows, and to confirm that Journey Optimizer executed a custom action (product-specific)
  • notSuitableInitialEvent: A discard code that logs can show when an event was received but discarded because it did not meet the qualification condition (product-specific)
  • maxInstanceStackEventsReached: A discard reason that appears when the journey runtime reaches its internal per-profile event stack limit for a specific journey version (see Guardrails) (product-specific)
  • isValidTransition: A UI-only property in the journey’s technical details; the page states it does not impact backend processing or journey performance, and a null value can indicate a journey misconfiguration (start date set in the future) or a corrupted transition (product-specific)
  • Qualification condition: A condition on rule-based events; when the event payload does not satisfy it (for example, a required field is empty or missing), the event is received but discarded and the journey is not triggered
  • Rebalancing: A backend auto-scaling operation in Adobe Journey Optimizer’s microservices architecture that can cause the same event to be reprocessed by another service instance, creating a second log entry with a different _id

Guardrails:

  • Events sent outside the journey’s active date window are discarded silently with the log entry DISPATCHER DISCARD #16 — unqualified on journey version enablements and no UI error
  • The journey runtime has an internal per-profile event stack limit of 10 events for a specific journey version; events beyond it are discarded with maxInstanceStackEventsReached. This is not a time-window or throughput limit
  • The namespace in the Profile Identifier must match the namespace defined in the event schema exactly (case-sensitive); a mismatch causes a silent drop: the event is accepted and returns a success response, but the profile never enters the journey and no error is surfaced in the UI
  • Overview dashboard metrics only include journeys that had traffic in the last 24 hours; allow up to 30 minutes for metrics to refresh after changes
  • Only republished journeys correctly populate context fields in tracking URLs; a closed journey that was not republished after a relevant product change can show empty placeholders

Terminology:

  • Canonical name: Journey Step Events — variants: journey step events, Journey Step Events dataset, step events
  • Synonyms: “rebalancing” = “auto-scaling” (the backend operation that can create duplicate log entries)
  • Do not confuse: entries with the same _id (duplicates at system level) ≠ entries with different _id values (separate log entries from the rebalancing scenario)
  • Do not confuse: sent ≠ delivered — in Adobe Journey Optimizer Message Feedback Event datasets, sent is the relevant status for successful message delivery outcomes and the delivered value is not used

FAQ:

  • Q: Why are my events not entering a journey even though they are sent successfully? — Check that the journey is in test mode or live, that the event was saved before copying the payload from the payload preview, that the payload has an event id and follows the streaming ingestion APIs payload structure, that the URL and the header key-value pairs (X-gw-ims-org-id, Content-type) are right, that the data types in the event condition match the event schema, and that the qualification condition is satisfied.
  • Q: Why does the journey fail to enable test mode with ERR_MODEL_RULES_16? — Ensure the event used includes an identity namespace when using a channel action.
  • Q: Why do test profiles enter the journey but not advance past the initial step? — The most common cause is a journey start date set in the future; events outside the active date window are discarded silently. Also check the test profile configuration and the identity namespace.
  • Q: What does maxInstanceStackEventsReached mean? — The journey runtime has reached its internal per-profile event stack limit of 10 events for a specific journey version, because the profile’s journey instance is blocked on a long-running step. Reduce long waits or slow steps, deduplicate or debounce upstream events, or split long-running scenarios into multiple journeys.
  • Q: I see duplicate rows in journey step events - is something wrong? — No. Entries with the same profileID, instanceID, nodeID, and requestID but different _id values are expected system behavior from backend auto-scaling; the impact is limited to logging, and only one message is sent. Verify with ajo_message_feedback_event_dataset.
  • Q: Why do tracking URLs in emails show empty placeholders like cid=em-acou-adob{}? — A context field such as context.system.source.actionId could not be resolved because the journey was closed and not republished after a relevant product change. Republish the journey, or remove the reference to the affected context field from the URL tracking parameters.
  • Q: Why does the Overview dashboard show different numbers than the Browse tab? — Check that the journeys had traffic in the last 24 hours, that you have the access permissions to view all journeys in your organization, and allow up to 30 minutes for metrics to refresh.

Related pages:

  • Troubleshooting errors before testing or publishing a journey: Troubleshoot errors before testing or publishing your journey (building-journeys/troubleshooting.md)
  • Troubleshooting inbound actions: Troubleshoot inbound actions in journeys (building-journeys/troubleshooting-inbound.md)
  • Understanding journey step events: Journey step events (reports/journey-step-events-overview.md)
  • Journey error codes: Error codes reference (building-journeys/error-codes-reference.md)
recommendation-more-help
journey-optimizer-help