舆情监控系统：同一用户多次咨询时怎样区分人数与次数
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /75f61ad6a333.html
📄
舆情监控系统：同一用户多次咨询时怎样区分人数与次数
结论先给：能不能把“多次咨询”拆成人数与次数，取决于系统里有没有一个跨会话稳定的身份键，并且这个键在业务上被允许合并。若只有会话ID或渠道昵称，你得到的是会话次数，不是人数；把会话数直接当人数，会在同一人换设备、换昵称或清理缓存时重复计数。下一步动作是先确认身份键的生成规则与合并范围，再决定报表口径。
先分清三个计数层级，再决定哪个能当“人数”
多数舆情监控系统实际存在三层计数：消息条数、会话次数、去重主体数。消息条数是原始记录，一条咨询可能被切成多条；会话次数依赖会话超时设置，同一人在超时后继续发言会被算成两次；去重主体数依赖身份键，只有这个键稳定时才能接近真实人数。
可操作的判断方法是抽样：取一段时间内同一渠道的咨询记录，按时间排序，观察是否存在同一身份键在短间隔内反复出现。如果身份键相同但会话ID不同，说明系统按会话切分，此时会话次数高于人数；如果身份键也变化，说明身份键本身不稳定，人数会被高估。这个动作的结果直接决定下一步：身份键稳定就修正报表口径，不稳定就先补身份采集字段。
一个会让结论失效的反例：共用设备与代咨询
即使身份键跨会话稳定，也存在一个明确的反例：多人共用同一设备或同一账号，或者一人代替多人咨询。此时按身份键去重会把多个真实咨询人合并成一个，人数被低估，而次数仍然正确。反过来，如果业务场景是家庭共用账号咨询不同事项，把去重结果当人数就会得出偏小的结论。
判断这类反例是否成立，需要看咨询内容是否指向不同主体。假设一段记录里同一账号先后询问两个不同订单的问题，且订单归属人不同，那么“一人多次”这个前提就不成立。这个假设只用于说明比较方法，不代表任何真实项目数据。确认反例存在后，人数口径应改为“账号数”并单独标注，而不是继续称为咨询人数。
次数口径本身也要固定超时与合并规则
次数不是天然唯一的。会话超时设成三十分钟还是二十四小时，同一用户的连续咨询会被切成不同数量。舆情监控系统如果允许自定义超时，报表里的次数会随配置漂移，跨周期对比就失去意义。
- 先固定一个超时值，并把它写进报表说明，避免不同人拉数时口径不一。
- 再确认系统是否把同一身份键的并发会话合并；若不合并，次数会偏高。
- 最后检查是否存在机器人或自动回复被计入次数，这类记录应单独排除。
完成这三步后，次数才具备可比性。若跳过固定超时直接对比两个周期，次数变化可能只来自配置调整，而不是咨询量真实变化。
把人数与次数分开落库，报表才可复核
更稳妥的做法是在数据层保留两个字段：身份键和会话ID，分别用于去重人数和统计次数。查询时用身份键做去重计数，用会话ID做次数计数，两者不互相替代。这样当有人质疑人数时，可以回溯到具体会话，检查是否存在共用设备或代咨询。
具体动作是先在明细表增加身份键字段并回填历史数据，再在报表层分别输出两个指标。回填后若发现人数与次数差距异常大，优先检查身份键是否被错误合并，而不是直接调整统计逻辑。这个检查结果会决定是否需要引入人工复核规则。
下一步：用一次抽样验证代替口径争论
不要停留在讨论“应该算人数还是次数”。取最近一段咨询记录，按身份键和会话ID分别计数，人工核对差距最大的若干条记录，判断差距来自超时切分、身份键变化还是共用设备。根据核对结果确定唯一口径，并在报表中注明适用条件。若核对后发现身份键无法稳定获取，就先把人数指标标记为估算值，避免把它当作精确人数使用。
