业务方要的复购率，我们的日志里从来没记过

运营提了个需求：要按渠道看复购率。这个数听着像报表里加一列就行，我打开底表翻了整个下午，发现日志里压根没有记过这件事。

需求提上来的时候很轻

需求是在周会上顺口提的，一句话，说想知道哪条渠道带来的人更值得再买一次。这种话当时没人反对，因为听起来像是在现有报表上加一个维度。

我当天下午开始翻。翻完发现，现有日志记了订单，记了 SKU 的属性，记了流量来源，但没记人和订单的对应关系——买家标识在一次用户数据清理之后没被完整保留下来。

要算复购，得知道两个订单是不是同一个买家。这个字段我们没记，或者记了但被清库动作洗掉了。

补埋点等了六周

往前补不齐，往后等六周

补这个字段本身不难，难在它要排进版本。产品的迭代节奏是一个月一版，加进去要过测试和评审，那一轮排期满了。

中间被催了三次。第一次是业务方问进度，第二次是我自己去问排期，第三次是运营直接在群里问产品。产品那边的回话我记着：能做，但不是这一版，也不是下一版。

六周里我犯过一个错。有一版排期提上去的时候，需求描述写的是支持按渠道看复购率，没写清是全量订单还是已确认收货。产品按自己理解做了范围，评审时没人提出。等上线试跑才发现要的是已确认收货那部分，得改逻辑，又多了一周半。

需求文档写得再细也挡不住这个，因为错的那个词藏在渠道的定义里。这次之后我在这类需求上会专门写一句哪些订单算进来，这一句值一周半。

等排期的那两周没人催

中间还有一段没人在催的日子。第四周到第五周，产品那边在做另一个功能，我们在等。我那两周把复购的定义翻来覆去写了三页，越写越长，其实最后只用上一页就说清了。

这件事的坏处是自己忙。定义写得再细，也得有产品那边排得上才行。等待期间能做的是把将来要问的问题准备好。

那半年只能是空缺

六周之后上线，往后的数据齐了。前面那半年的历史，回不来。

上线之后我给了业务方两个东西：往后每月的复购率，和一句实话——2026 年之前没有这个数。

第二种东西给出去的时候对方不太高兴。有个运营问能不能从优惠券使用记录里倒推一下，看谁回来过。这个想法我试了半天，优惠券记录能看出人回来，看不出是不是复购，混着太多别的东西，凑出来的数看着完整，其实没人敢用。

没记过的维度只能用往后换

这件事我记住了三条。

第一条：需求评审时先问一句，这个数需要什么字段。字段不在当下的日志里，问题的性质就不是排期，是造数，周期至少差六周。这一句话能把需求卡在进队列之前。

第二条：需求文档里写清哪些订单算进来。这一句花两分钟，它值那一周半。

第三条：造出来的数要带起始月份，写在表头。这一条不写，业务方一定会拿它跟去年的数放在一起看，看不出不可比，就会得出一个错的趋势。

数据缺失这件事本身不可怕，可怕的是缺失的那一段被悄悄填上了。