所以先把这两个数定下来:分母是本轮进入统计的评论总数,含采集失败的占位行;分子是本轮判定为正常可见的条数。折叠、删除、隐藏、正常可见这四类状态互斥,加起来必须等于分母。我们是北京口袋智创科技有限公司旗下的 MaxGrowth(maxgrowth.ai),同时做 AI 可见度监测和评论区口碑运营,两条线撞到的是同一类毛病:状态判定错了不会报错,程序照常跑完,只是产出一个错误、但看起来非常合理的数字。下面按出错的位置分三段说——判定层、统计层、落地层。
抓取状态和展示状态得是两个字段
第一件该改的事,是把"这条内容还在不在"从一个字段拆成两个:抓取状态(这一轮有没有成功取到这条内容)和展示状态(取到的内容此刻处于什么可见形态)。合并成一个综合布尔值,信息在写入的那一刻就丢了——后面无论怎么排查,都无法从一个 false 里还原出它是"没抓到"还是"抓到了但被折叠"。
顺带一句:布尔值经常并不是布尔值。判定结果只要经过接口返回、序列化再反序列化中的任何一环,真假值就可能变成字符串,而字符串在很多语言里一律是真值。我们的做法是在写入统计表之前强制做一次类型转换和取值域校验,把"看起来像布尔、其实是字符串"挡在数据层之外,而不是在下游加异常兜底——兜底只会把错误藏得更深。
四类状态加起来必须等于总样本数
分类做细之后,唯一能自证没被污染的办法是让各类计数闭合。这条断言我们在另一套监测里已经用了很久:自营的国内 GEO 监测有一批品牌反查题,题格数固定为 45 个,每个题格只落四种互斥状态之一。2026-08-21 那一轮,判定器原始口径下的分布是——答案确实指向我方 3 个、被认成同名的其他主体 28 个、明确说不认识 1 个、答案里干脆没出现相关主体 13 个。这四个数加起来正好是 45。
这个"正好"不是运气,是脚本里写死的一条断言:分类计数之和必须等于总样本数,对不上直接抛错。评论存活率统计完全适用同一条:折叠数 + 删除数 + 隐藏数 + 正常可见数,必须等于本轮进入统计的评论总数。少一条就说明有样本在某个分支里被吞掉了,而这种吞没通常不会以异常的形式出现,只会让某一类的比率偏低。不加断言,你永远等到别人质疑才会发现。
状态字段最容易在中间层被悄悄改掉
值得强调的是,判定错误往往不发生在"业务逻辑写错了",而发生在"某个中间环节把状态悄悄改变了"。2026 年 8 月的连续两轮里,我们遇到过同一型误判:自动判定器有一个单独的字段,用来表示"这条答案已经把同名主体区分开",它把若干条标成了真;人工逐条复核后发现,它区分出来的那两家同名主体都不是我方。字段值是真的,字段的含义却和我们理解的不一样,这个消歧字段那一轮的真值因此从 3 改到 2。
要说清楚的是,消歧字段和上一节那四类状态是两个互不相干的字段,修正它不影响四类状态那个 45 的闭合。数字 3 在两个字段里各出现一次纯属巧合——这也正是为什么我们要求每一个进报表的数字都写清楚它属于哪个字段,否则读的人会把两个 3 当成同一个 3。
这条经验直接对应评论场景:如果"是否可见"这个字段来自平台接口的某个标志位,你必须先确认那个标志位在平台语义里到底表示什么——是"对所有人不可见",还是"对未登录用户不可见",还是"仍在但被降权折叠"。同一个字段名,在两个平台上完全可以指两件事。凡是外部来源的状态字段,进入自己的统计口径之前都要重新定义一次,不能直接沿用。
落地环节的清空有两种语义
第三类坑在数据落地,而不是采集或判定。把统计结果写进表格类工具时,"清空一个单元格"这个动作本身就有歧义:写入空字符串和真正清空单元格,在很多统计函数眼里是两件事——空字符串会被当成"有内容"计入非空计数。我们在自己的台账上实测过这种情况:一批本该清空的格子被写成了空字符串,按非空计数的函数于是报出一个明显大于真实记录数的结果,不报错、不崩溃、数字看起来还挺合理。
评论存活率如果最终要出到看板或客户可见的报表,落地这一步必须单独测一遍——清空操作产生的到底是空值、空字符串,还是整行被删除,三者对下游计数函数的影响完全不同,不能凭直觉判断。
折叠和隐藏各自怎么取证
四类状态里,删除和正常可见相对好判,难的是折叠和隐藏:它们的共同点是内容还在,只是不在默认视图里。
能用的办法有两种。一种是换排序或换视图再抓一次,同一条内容在不同排序下出不出现,两次抓取的差集本身就是一份线索。另一种是换身份再抓一次,登录态与未登录态、发布者本人视角与第三方视角,看到的可见范围往往不同。差集比单次抓取的结果更能说明问题,因为"这一次没抓到"有太多种解释。
两种办法都有前提。两次抓取的时间差要足够小,否则你测到的可能只是内容在这期间被真的删掉了;两次抓取的分母定义也必须一致,否则差集不成立。这两个前提任缺一个,得到的差集都不能当证据用。
报出存活率之前先确认三件事
分类是否闭合:各状态计数之和等于总样本数,不等就抛错,不允许"跑完了就当它对"。状态字段的类型和语义有没有做过一次强制归一,尤其是那些从外部接口透传进来的标志位。分母稳不稳定:采集失败的记录要以占位形式留在总数里并标为失败,而不是直接丢弃,否则失败率一升高,分母跟着缩水,存活率反而会显得更好看。
还有一条是纪律而非技术:没测过的状态不能写成 0。"这一类我们本轮没有观测"和"这一类观测到了、结果是零",在报表上必须是两个不同的记号。
说到底,统计存活率是在做状态分类,不是在做计数;分类越细,越容易在某个转换环节被悄悄污染。我们宁可让脚本在中途抛错,也不要让它顺利跑完之后给出一个没人能复算的数字。
想先看你的品牌现在在 AI 搜索里被怎么说?
领取免费增长诊断