月结最后一晚，同比多出来的十几个点

月结那张同比表我做了三年，前两年没出事。第三年的一个六月，最后一晚拼表到十点，同比跑出来比预期高十几个点，运营在群里说这是翻倍。真实情况是涨了四五个点。

三张表，十点二十才拼完

销售、流量、广告三个后台各导各的。销售那张最大，导完就过四点；广告那张要等刷新，等到七点；流量那张最容易出问题，那晚多花四十分钟去掉一类重复会话。拼完跑同比，用的还是前两年的同一个脚本。

那晚慢的是拼表的时间，慢这个字不重要，重要的是拼得太晚。三个源七点以后才齐，中间任何一处出错都没有第二次机会，而第二天上午十点就要开月度经营会。

翻倍是从分母来的

当时的判断是错的。我们先怀疑今年重复了，把销售表按订单号去重一遍，重跑没变化；接着怀疑广告口径动过，这条又走掉一个多小时。第三步才回头看去年。

去年那张表里有两个站点是三月才补录进去的。补录之前，这两个站的订单只同步了一部分，接站的运营等不及一天多的同步时间，直接导后台那份存成了月结基线。补录做完，没人回来改那张基线。

同比这个算法，去年分母小一截，今年就显得涨得多。多出来的十几个点，一分都没落在今年的业务上。

补录这件事没有主人

表是对的，脚本是对的，做表的人也是对的，错的是两个正确的东西凑在一起。这种错最难防，因为链路上每一步都能自证清白。

我后来复盘这类事，问的第一个问题跟数字无关：先问这个基线是什么时候建的、中间有没有人改过底下的东西。建基线是一次性动作，可它服务的是往后每个月。

多出来的十几个点不在今年，在去年的分母

月结日现在多花二十分钟

顺序改了：先核基线，再拼当月。

这二十分钟放在月底，拦住的是把错数带进第二天上午的经营会。真正省下来的也不是那两天重算，是会上被拉向一个错误方向的那一个小时。

当晚发现的数，宁可第二天早上再发

那晚十点多发现不对，已经是这个月最后一天，第二天上午十点开会。如果那个数进了会，年度目标的基数就按它定了，改一次要动三个部门的计划。

现在我们把月结自查提前到下午三点，那会儿发现问题还剩两个小时能改。晚上八点以后发现的同类问题，等第二天早上发，不硬扛。宁可让会议晚半天，也不要让一个方向性的错数在会上被讨论一个小时——那种共识一旦形成，往下推十页材料都拉不回来。