10、20、30 —— 一列看起来很有规律的假数据
这是我们自己犯的第二个数据错误，写出来的理由和第一个一样：它不报错、不崩溃，产出的数字看起来还特别规整——而规整恰恰是它最危险的地方。
现象
查看历史记录时，同一个检索底座下的多个措辞，引用计数呈现出 10、20、30 这样的等差排列。
第一反应甚至是「有点意思」——像是排在后面的问题引用来源更多。真去想为什么会有这种规律时才发现不对：几个措辞之间没有任何理由形成这么整齐的递增。
原因
计数器变量在题目循环的外面初始化，所以它从第一题开始一路累加，而每一题结束时写进历史记录的，是到该题为止的累计值，不是这一题自己的计数。
于是第一题记 10、第二题记 10+10=20、第三题记 30。数字全都「有」，也全都不是那一题的真实读数。
已改成每题独立计数。文档里那批旧数据是用相邻两项作差还原出来的。
为什么这类错误特别难发现
它不抛异常。程序跑完了，表格填满了，每个格子里都有数。
它产出的还是单调递增的序列，而单调递增在直觉上很像「真实的趋势」。如果当时顺手把它当成增长曲线画出来，会得到一张非常好看、但完全没有意义的图。
对照我们踩过的第一个坑（把搜索引擎回显的查询词当成命中），两者的共同点是：错误的方向是让数据变好看。这大概不是巧合——让数据变难看的 bug，你当天就会去查。
这件事对读报告的人意味着什么
看到过于规整的序列要警惕。真实的检索数据是噪声很大的，等差、等比、平滑上升这类形态，先怀疑是统计口径出了问题。
问清楚每个数字的口径是「这一次」还是「到目前为止」。这两个口径混在同一张表里，表本身就是错的。
留意旧数据。我们把这次修正记在了文档里，读 08-21 之前的历史记录要按这个说明来理解。发现错误之后回头标注旧数据，是我们认为最低限度该做的事。
要点回顾
- 计数器在循环外初始化，会把累计值写成单次值，数据全有、全错
- 这类 bug 不报错，还倾向于产出好看的单调递增序列
- 我们踩过的两个数据坑，错误方向都是让数据变好看
- 读任何监测报告：问清每个数字是「这一次」还是「累计」，并对过于规整的序列保持警惕
依据：探针脚本的这处修改与修正说明均已记入我们的实测文档，修正日期与影响范围（08-21 之前的历史记录需按相邻差还原）在文档中标注。