如何在 AI 对话产品中区分慢回复与用户流失
如果用户习惯按自己的节奏回复，那么 AI 对话中的长时间停顿并不足以证明他们已经离开。要区分用户主动选择的较慢节奏与消息投递问题或未完成的任务，应将用户明确的回复偏好与消息投递情况和任务状态分开记录。仅凭沉默应归类为未知，而非流失的证据。
为什么仅凭流逝时间会对用户产生误判
时间间隔很容易测量，但它无法解释在此期间发生了什么。用户可能是选择稍后再回复；通知可能未送达设备；应用可能未记录已完成的任务；或者可能仅仅是没有需要观察的新操作。这些可能性需要不同的产品应对方式，因此将它们统统归为一个“未活跃”标签会使底层数据更难解读。
消息系统本身就会区分投递阶段。Firebase Cloud Messaging 将发送、Android 应用接收、通知展示和打开作为独立指标进行报告；发送仅表示消息已排队或已传递给 APNs 等服务，并不意味着用户已经看到了它。Firebase 还指出，某些报告存在延迟，且其汇总投递数据存在覆盖范围限制。Firebase: Understanding message delivery
这种区别提示了一条有用的分析规则：绝不要从发送请求等上游事件来推断用户的回复节奏，也绝不要将未打开或未回复视为投递失败的证据。记录产品能够观察到的内容，将未观察到的结果保持为未知。
让用户自主设定偏好的回复节奏
提供一个简单、可选的偏好设置，用于回答一个实际问题：用户希望产品在何时提醒其回复或进行后续跟进？如果适合产品定位，可以使用通俗易懂的选项，如“等我准备好时”、“今天稍后”或“在指定日期提醒我”。具体的选项属于设计决策，而不是对任何特定用户偏好的武断假定。
将该选择作为用户偏好保存，并附带更新时间，以及在适用情况下的过期或结束条件。偏好是关于该用户选择如何使用产品的持久上下文；而回复间隔则是关于单次对话或消息的事实。数据分析平台在描述用户的“用户属性”与描述具体操作的“事件属性”之间也做了类似的区分。Amplitude: User properties and event properties
确保该偏好易于更改或清除。避免将观察到的平均回复时间直接转化为假定的偏好：历史模式有助于描述过去的行为，但只有明确的选择才能表明既定的偏好。如果没有保存的偏好，应将该值记录为未知，而不是擅自代表用户分配一个默认节奏。
将对话任务作为可观察的状态进行追踪
围绕系统可以验证的操作定义一组精简的任务状态。例如：waiting_for_user、waiting_for_service、ready_for_user、completed 和 cancelled。仅在有事件或系统响应支持时才使用某种状态。用户发送消息可能会将任务转为 waiting_for_service；成功的响应可能会使其变为 ready_for_user；明确的完成操作可将其标记为 completed。如果响应或状态更新失败，请记录该故障，并在后续事件明确之前保持任务未解决状态。
为这些事件附加对话或任务标识符，以便分析人员重构事件序列。记录事件时间、事件类型、当前任务状态以及相关的技术结果。将用户级别的偏好与单个任务的细节分开：“偏好在准备好时回复”可以适用于所有对话，而“该任务正在等待用户操作”则描述的是当前的一次交互。在基于事件的分析中，事件属性捕获操作发生时的上下文，而用户属性则描述随时间变化的特征。Amplitude: User properties and event properties
这种分离还能保护历史数据的正确解读。当有人更改偏好时，应在早期事件上保留旧值，并将新值用于后续事件；切勿重写过去，仿佛较新的偏好一直适用一样。Amplitude 的文档中对用户属性的这种时效感知行为进行了描述。Amplitude: User properties and event properties
将投递健康度与用户操作分开
对于每条发出的聊天消息或通知，记录集成实际暴露的各个阶段：尝试发送、消息服务已接受、已投递至应用（如果可用）、已显示（如果可用）、已打开（如果可用）以及任何已知错误。不要捏造平台并未提供的投递回执。在 Apple 平台上，APNs 负责向用户的设备投递远程通知；该系统角色与用户打开通知的记录是截然不同的。Apple: User Notifications
将基础设施层面的结果作为基础设施信号使用。例如，请求失败、服务商拒绝、超时或队列延迟应促使团队去排查投递或服务健康状况。成功的发送请求仅代表该阶段没有问题。Firebase 解释称，其发送统计数据可能代表消息已排队等待投递或已传递给其他服务，并且其汇总的 Android 传输数据描述的是总体趋势，而非每条单独的消息。Firebase: Understanding message delivery
对于内部消息处理，确认回执（acknowledgment）同样需要谨慎解读。Google Cloud Pub/Sub 将消息描述为在确认之前一直处于未决状态，并指出未确认的消息可能会在截止时间后重新投递；消息也可能会被多次投递。这是个有益的提醒：事件处理应能容忍重复，并且需要将处理确认的缺失与用户回复的缺失明确区分开来。Google Cloud: Subscription overview
采用审慎的分类规则
实用的决策辅助工具有助于保持标签的精准且基于证据：
观察到的证据：用户选择了回复时间偏好，且未观察到更新的操作；适用的分析标签：已记录偏好；尚未观察到回复；无法证明的推论：用户已经离开，或投递失败
观察到的证据：服务请求或消息投递阶段失败或超时；适用的分析标签：在记录的阶段出现技术问题；无法证明的推论：用户为何没有回复
观察到的证据：产品有已确认的下一步骤正在等待用户操作；适用的分析标签：任务等待用户操作；无法证明的推论：任务已被放弃
观察到的证据：记录到了完成、取消或其他最终操作；适用的分析标签：已完成或已取消（按观察结果）；无法证明的推论：对未来使用的广泛定论
观察到的证据：证据缺失、延迟或相互矛盾；适用的分析标签：未知或需要对账核对；无法证明的推论：任何具有确定性的行为解释
“流失”标签应当需要明确的产品级规则以及支持该规则的充分证据；它不应成为消息间隔时间长的代名词。如果仪表板在证据齐备之前需要一个状态，那么“未观察到近期回复”比断言用户为何缺席要准确得多。将该状态视为临时状态，并在延迟事件到达时进行修正。
围绕偏好和任务状态构建分析体系
有价值的留存队列分析会探究：明确选择较慢节奏的用户，是否在与其偏好相符的时间范围内完成了既定任务。坚持同类相比：按所选偏好和任务类型进行分组，并分别检查投递失败、未解决的服务请求和完成事件。不要把单个用户的沉默期当成产品范围内的失败信号；应在具有可比性的任务和投递条件下寻找规律。
例如，如果某人选择了“等我准备好时”，对话保持开启，并且产品没有记录到投递错误或新的用户操作，那么合理的归类状态是“未观察到回复；已有记录的偏好；任务仍处于开启状态”。如果发出的响应记录有服务错误，即使已知该用户的偏好，状态也应反映该错误。这是基于上述事件模型的示例性分类，并非实际测得的产品结果。
在将某个指标用于决策之前，请检查特定平台上是否存在事件延迟到达、重复或丢失的情况。Firebase 表示部分投递报告存在延迟，汇总指标可能会遗漏或四舍五入统计结果；Pub/Sub 文档记录了至少一次投递以及可能重复投递的情况。使用稳定的消息或任务标识符对事件进行对账核对，避免将重试误算为用户的第二次操作。Firebase: Understanding message delivery，Google Cloud: Subscription overview
围绕用户的自主选择设计跟进策略
如果后续跟进是产品功能的一部分，请确保它能反映用户所选择的偏好。用户选定的提醒时间可以控制提醒的触发；“等我准备好时”可以意味着不进行基于时间的催促。为用户提供便捷的途径来更改该选择，并在对话中明确显示当前状态，以便他们清楚产品是在等待他们、等待服务响应还是已经结束。
利用数据分析来发现技术缺陷并了解任务完成情况，而不是从沉默中臆断定论。明确的偏好提供了上下文背景，任务状态展示了剩余的工作，而投递事件则揭示了已知的技术阶段。当其中某一项缺失时，请在标签中保留这种不确定性。这样既能对慢回复给出更具实用价值的解释，又能将何时返回的选择权留给用户。