文档Journey OptimizerJourney Optimizer 指南

对实时历程执行进行故障诊断 troubleshooting-execution

最近更新： 2026年9月9日
  • 适用对象：
  • 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，请确保使用的事件在使用渠道操作时包含标识命名空间。

身份命名空间用于唯一标识测试配置文件。 例如，如果电子邮件用于识别测试用户档案，则应选择身份命名空间​Email。 如果唯一标识符是电话号码，则应选择身份命名空间​电话。

检查人员是否进入历程 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的属性不会影响后端处理或历程性能。 但是，空值可以表示：

  • 历程配置错误 — 旅程开始日期设置为将来，导致以静默方式丢弃测试事件
  • 损坏的过渡 — 在极少数情况下，可能需要重新连接历程节点

如果您遇到永久性过渡问题：

  1. 验证历程开始日期是否为最新
  2. 停用和重新激活测试模式
  3. 如果问题仍然存在，请考虑复制受影响的历程节点并重新连接它们
  4. 对于未解决的情况，联系支持人员，并提供历程日志、受影响的配置文件ID以及有关null过渡的详细信息
NOTE
在历程的有效日期窗口之外发送的事件，将自动被丢弃，日志条目为DISPATCHER DISCARD #16 — unqualified on journey version enablements，并且没有UI错误。 在排查测试用户档案进度时，始终首先验证您的旅程计时配置。

检查人员在历程中的导航方式 checking-how-people-navigate-through-the-journey

历程报表测量旅程中个人的进度。 很容易识别人员在何处被拦住以及为什么被拦住。

以下是一些要检查的内容：

  • 是因为除人员外的情况吗？ 例如，条件为“性别=男性”，而该人员为女性。 如果条件不太复杂，此检查可由商业用户执行。
  • 是由于调用数据源时没有响应吗？ 当历程正在测试时，此信息可在测试模式日志中查看。 当历程处于实时状态时，管理员可以测试对数据源的直接调用并检查收到的答案。 管理员还可以重复历程并进行测试。

由于历程实例被阻止而丢弃的事件 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。 对于自定义操作，请查询历程步骤事件数据集，以确认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>'

如果我观察到了这个怎么办？

这是正常的系统行为，无需执行任何操作。 重复的日志记录并不指示您的历程配置或消息投放存在问题。

如果您基于历程步骤事件构建Reports/Analytics：

  • 使用_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