将对话追踪为页面浏览的问题

抱歉，我无法直接访问外部链接来获取文章内容。请您把需要翻译的文本粘贴在这里，我会按照您的要求将其翻译成简体中文并保留原有的格式。

Source: …

为什么基于事件的分析从未为对话式 AI 产品构建——以及该怎么做

将对话追踪视为页面浏览的难题

想象一下。 你是一个 AI 初创公司的产品经理，产品上线已六个月。周一早上打开仪表盘，一切看起来……还不错？

• 会话数环比增长 20 %。
• 平均会话时长为 4 分 30 秒。
• 日活跃用户（DAU）在上升。

你截个图，发到投资者更新的 Slack 频道。

然后你查看留存率。

用户出现、进行对话，却又消失。指标显示参与度很高，业务却觉得出了大问题。

没人会在你发布第一个 AI 产品时告诉你的事儿： 你把对话当成页面浏览来追踪，这正是你的仪表盘每天早上都在骗你的原因。

产品经理盯着指标仪表盘一脸困惑
^ 每个 AI 产品经理在周一早上看到数字看起来不错，却发现留存率直线下降时的情景

页面浏览量是为内容静止的世界而构建的

页面浏览量指标在 90 年代中期被发明，用来回答一个问题：有人看过这个东西吗？ 就是这么简单。

• 报纸印刷了一篇报道。
• 你打开它了吗？点击。页面浏览量被记录。
• 内容不会因为你的操作而改变。它就静静地摆在那里。要么你消费了它，要么没有。

这种思维模型蔓延到各个角落：点击、会话、页面停留时间、跳出率、页面深度。所有这些都建立在同一个基础假设之上：

产品是静态的工件，用户在其上移动。
参与度 = 消费。点击越多 = 参与度越高。参与度越高 = 价值越大。

这个假设支撑了 25 年。它造就了今天的分析体系。

然后我们推出了产品，产品本身会 响应 用户的输入。

整个前提崩塌了，而大多数团队还没有注意到。

• 对话 不是 静态的工件。
• 它是一个双向的、动态的交流，拥有内部结构。
• 含义存在于 序列 中：提出了什么问题，如何得到回答，随后发生了什么，用户是否得到了他们真正想要的东西。

这些都不会出现在天真的事件流中。

当你记录 conversation_started 和 conversation_ended 时会失去的东西

当你像为网页应用仪表化一样对 AI 产品进行仪表化时，事件日志看起来像这样：

conversation_started   { "user_id": 123, "timestamp": "10:04:12" }
message_sent           { "user_id": 123, "turn": 1 }
message_sent           { "user_id": 123, "turn": 2 }
message_sent           { "user_id": 123, "turn": 3 }
conversation_ended     { "user_id": 123, "duration": "4m32s" }

看起来合理。现在考虑三个非常不同的情景，它们产生 完全相同 的日志。

所有三者产生 相同的事件日志——但结果却截然不同：

• 故事 A: 产品‑市场匹配。
• 故事 B: 质量问题。
• 故事 C: 正在流失。

你的仪表盘显示了三个“成功的” 4 分钟会话。

Surprised Pikachu
^ 我意识到这三个用户在 Amplitude 中看起来完全相同

从事件追踪中得出的指标在衡量错误的事

像 MAU、DAU、会话时长、对话深度 之类的指标都有同一个假设：活动越多 = 价值越大。它们是参与度的代理，而在产品是网站时，这种代理是有用的。

对于对话式 AI 产品，这个代理会以一种特定的方式失效。

我们使用 Agnost 追踪数百万次跨产品的对话，这一模式始终如一：会话时长最高的用户并不是最满意的用户；有时他们恰恰是最沮丧的那批。

快速对比

右侧的列要求你理解 对话结构：不仅要知道是否有回合发生，还要了解 回合的类型、用户的意图，以及 他们是否成功。

正确的思维模型：对话是一次 任务尝试

重新审视一切：

• 对话 不是 页面浏览。
• 它甚至 不是 传统意义上的会话。
• 对话是一种任务尝试。

用户带着意图出现，尝试完成某件事，结果要么成功要么失败。

问题不在于“他们是否进行过对话？”
而在于“他们是否完成了来此的任务？”

这就是评估客服人员的方式：你不统计他们打开了多少工单；而是统计他们 解决了多少工单。

应该跟踪的指标

要点

1. 停止把对话当作页面浏览量。
2. 从基于活动的代理指标转向基于结果的指标。
3. 为你的产品加装工具，以捕获任务意图、成功/失败以及质量信号。

当你做到这些时，你的仪表盘终于会在每周一早上告诉你需要看到的真实情况。 🚀

对话原生分析：为何转变重要

对话即产品。你的分析应当反映这一点。

传统事件驱动追踪的问题

• 你没有追踪 每次通话的时长。
• 你只追踪客户问题是否得到解决。
• 对 AI 产品也是如此：对话仅是任务完成尝试的媒介，但大多数仪表盘仍然关注 事件（点击、页面浏览、会话时长），而不是 结果。

当你从“事件 = 成功”转向“对话 = 成功”时，许多事情会变得更清晰：

• 短对话 可能是很好的结果（高效解决） 或 是糟糕的结果（用户立即放弃）。上下文决定是哪一种。
• 长对话 可能表明深度参与 或 是挫败感的螺旋。同样，上下文很重要。

你需要一个能够 辨别哪种情况 的分析层。

Source: …

什么是对话原生分析

这并非假设。原始数据层已经存在；只是尚未为 AI 团队产品化。

一次对话具有 结构：

1. 意图 – 用户想要实现的目标。
2. 尝试序列 – 每一次交互都在尝试满足该意图。
3. 结果 – 是否得到解决（或失败）。

每一次交互都是关于该结构运行效果的证据。

实际可追踪的信号

• 解决信号

  • 正向：
    • 对话结束时用户得到想要的结果。
    • 结束时出现正面情绪。
    • 后续提问基于之前的答案。
    • 用户在 48 小时内因相关问题再次返回。
  • 负向（失败）：
    • 用户对同一问题进行三次改写。
    • 中途掉线。
    • 立即返回到流程起始点。

• 重复检测 – 同一问题以不同表述出现 → AI 未理解 → 质量失效。应体现在指标中，而不是被平均会话时长所掩盖。

• 按位置掉线 – 用户在对话的哪个环节放弃？

  • 示例：40 % 的对话在第 3 轮后结束且没有出现解决信号 → 第 3 轮存在可修复的具体问题。

• 意图聚类 – 按 用户想要做什么 而不是他们触达的功能来分组对话。可揭示隐藏模式（例如，30 % 的支持聊天询问的是文档未覆盖的相同问题）。

这并不神奇。 只是在已有数据上套用正确的模型而已。原始对话数据已经存在，关键在于你的分析层是否会读取它。

视觉隐喻

“在意识到整个仪表盘一直在骗你的时候，构建对话原生分析。”

这一路的去向

在 AI 产品上获胜的团队都有一个共同习惯：

• 不再只优化参与度 → 开始优化解决率。
• 将成功度量放在对话层面，而不是会话层面。
• 追踪指标：
  • 任务完成率。
  • 首轮解决率。
  • 典型对话中的精确掉线点。

他们采用的工具把对话视为主要分析单元，而不是事件的聚合。

而行业其他部分仍在截取 MAU（月活跃用户）图表，苦恼于留存率为何如此困难。

这种转变正在到来。 会话式 AI 正在推动一种全新的分析范式，就像十年前移动端推动了全新的网页分析范式一样。最先掌握它的团队将获得显著优势——不仅体现在产品质量上，还体现在能够在流失数据出现之前诊断并解决问题。

总结

• 如果你的核心产品循环是对话，那么核心分析原语也应该是对话，而不是事件。
• 基于事件的跟踪会给你一个数字，但它几乎无法告诉你产品是否真的有效（比如只算电影帧数）。
• Conversation = 单位。
• Resolution = 指标。
• Task completion = 你要优化的结果。

其他一切都是噪音。

Agnost 的构建正是为了解决这个问题：从头为对话型产品设计的分析工具，让你不再猜测，而是知晓。
👉 在此尝试 Agnost

TL;DR

基于事件的分析 跟踪 对话是否发生。
原生对话分析 跟踪 它们是否有效。
你需要后者。

阅读时间: ~7 分钟