统计美洽“软留言”对话量，最核心的是先定好口径：以会话（thread_id）为单元计数、按固定超时时间合并断续消息、剔除系统/机器人干扰并区分“仅客户留言”与“有客服回复”的会话；基于这个口径，从消息表和会话表抽取原始数据、去重、按天/频道/语言分组，再做校验与可复现的存档，才能得到可信的对话量指标。
先把概念讲清楚（像在教一个新同事一样）
嗯，我们先把“软留言”“对话量”“会话”这些词弄明白，别急，慢慢来。
什么是“软留言”
软留言通常指用户在非实时或非人工即时接入场景下留下的文本信息——例如页面小窗体发送的留言、客服不在线时的留言、或开启了离线留言的渠道；它强调的是异步、没有即时响应的那种交互。
什么是“对话量”
“对话量”不等于消息条数。*对话量*更接近会话（session/thread）数量，即以一次完整的用户-系统/客服交互为一单位计数。把每个独立的会话计为1，而不是按消息条数累加，这样才有业务可比性。
会话的边界由谁来决定？
- 最常见：基于 thread_id 或 session_id（小程序/网页/APP会话标识）。
- 补充规则：若无明确 session_id，可按用户+渠道+超时（比如 30 分钟、4 小时）合并消息为一个会话。
- 注意：跨设备与跨渠道（微信/网页/邮件）可能需要合并映射规则。
做统计前必须明确的口径（不一致会导致半夜争论）
这里是几条不能偷懒的规则，定好了，你的报表就不会被“打回去重做”。
- 计数单位：会话（thread_id）优先；没有则用 user_id+channel+timeout。
- 时间窗：通常按自然日统计（UTC 或本地时区要一致），报表需注明时区。
- 是否计入机器人：明确是否包含自动回复/机器人引导产生的会话。
- 客服参与度：区分仅用户留言（无人回复）和有人工/机器人回复的会话。
- 重复与重试：同一用户短时间内多次提交应按会话规则合并或标注重试次数。
数据源与表结构示例（实际可根据美洽数据仓库调整）
下面是个精简版的表结构示范，便于理解如何从源头抽数。
| messages | 存储每条消息 |
| message_id | 唯一ID |
| thread_id | 会话ID |
| user_id | 用户ID |
| channel | 渠道（网页/微信/邮件） |
| sender_type | user/agent/bot/system |
| created_at | 时间戳 |
还有一个会话表（threads）：thread_id、start_at、end_at、first_msg_id、last_msg_id、status（open/closed）、assigned_agent 等字段会很有用。
典型的统计流程（一步步来做）
- 抽取消息与会话原始数据（按时间范围），保存为可复现的快照。
- 根据口径过滤消息：剔除 system 类型、筛选 channel、区分 bot 与 human。
- 按 thread_id 聚合成会话，若缺 thread_id 则按 user+channel+timeout 合并。
- 标注会话属性：是否有客服回复、首次留言时间、是否为重试、语言标签等。
- 生成日报/周报/月报：按日期、渠道、语言、国家、产品线分组计数。
- 做校验：抽样对话回看、和客服台账交叉比对、检查异常波动。
示例 SQL（思路性的，需根据实际字段改写）
以下只是思路表达，不保证直接可跑：
SELECT DATE(created_at) as day, channel, COUNT(DISTINCT thread_id) as conversations FROM messages WHERE created_at BETWEEN ? AND ? AND sender_type != ‘system’ GROUP BY day, channel;
如何处理常见棘手情况（避免“统计陷阱”）
- 机器人会话：若机器人会话被计入，会显著放大对话量。解决：单独统计机器人会话或以比例注释。
- 跨渠道合并：用户从网页切到邮件，若能通过统一的 user_id 识别，应合并为一会话；否则会被重复计数。
- 短时重试：同一用户短间隔连发多条留言（例如 1 分钟内），通常视为一个会话内的重试或补充。
- 离线回访：客服在数日后回复的会话，是延续会话还是新会话？口径需明确，一般建议按 thread_id 归并。
- 消息编辑与撤回：编辑不应改变会话计数；撤回也通常不调整会话数，但要保留操作日志。
如何做验收与质量控制（QA）
统计出来的数字如果不能复现，那就没意义。几条实操建议：
- 保留抽数脚本与中间表快照，按时间点可以回溯。
- 做随机抽样，把原始会话回看 100 条，验证口径执行情况（例如是否误把系统消息算进去了）。
- 建立异常监测：对话量日增减幅度超过阈值触发告警，并保留触发时的快照便于诊断。
- 定期比对客服平台导出数据与仓库统计结果，发现字段映射或时区问题。
报表展示建议（便于产品与运营读得懂）
报表别只给一个“总数”，要分层：渠道、语言、国家、是否有人回复、平均首次响应时长（ART）、会话长度（消息数）、转化（如工单、成交）等。
| 维度 | 示例指标 |
| 渠道 | 会话量、占比、ART |
| 语言 | 会话量、无回复率 |
| 客服 | 平均处理会话数、首次响应率 |
举个小案例（帮助把抽象变具体）
假设某天网页渠道的消息表中有 1 万条消息，但 thread_id 只有 1,800 个不重复，会话超时口径为 4 小时。这意味着直接按消息条数统计会高估约 5.5 倍。进一步查看，发现 ~30% 为机器人自动回复，会话在人工统计时可单独剔除或标注。于是最终给到运营的“人工可处理的软留言会话”约 1,260 个（1800 * 0.7），这类数字对排班和 SLA 规划更有意义。
最后说两句实践层面的建议（像朋友聊天那样）
不要一开始就追求完美的全覆盖；先把一套清晰可复现的口径做好，把脚本写稳、把抽样校验做足，再逐步补齐跨渠道与语言的复杂性。嗯，我觉得如果你现在就能把 thread_id 的抽取和“有无客服回复”的判断做到位，后面的分析就顺利多了。稍后你可能还会发现更多边角问题，不过那是正常的。