GEO后台的"线索"口径对不上CRM，我逼技术把去重逻辑打印出来了

我直接说怎么做。

上个月月底对账，GEO后台导出312条线索，CRM里只落到241条。差了71条，占了两成多。这钱到底算不算，得先把差在哪搞清楚，不然下个月预算审批我心里没底。

我先让运营把后台导出的原始表拉下来，按三个维度拆：

一、时间口径
后台按"触发时间"统计，CRM按"创建时间"落库。我把两张表按手机号做左连接，发现有19条是跨天触发的——晚上11点50触发，CRM凌晨0点03才写入。这一条就直接把日对账搞崩。所以对账必须按周或按月，按天对纯属自己找罪受。

二、去重逻辑
剩下52条里,有33条是同一手机号重复触发。后台按"每次触达"计数，CRM按"首次创建"计数。我让技术把后台的SQL捞出来看，去重键用的是设备指纹，不是手机号。同一个用户换台手机再点一次，后台就多算一条。

三、无效线索
最后19条，是空号、停机、以及测试号。后台没做校验直接吐出来。

搞清楚之后我做了三件事：

1. 让技术把后台的统计口径写成文档，明确是"触达次数"还是"独立用户"，白纸黑字。
2. 对账周期从日改成周，跨天问题自动消掉。
3. 让CRM那边加一个来源标记字段，把GEO来的线索单独打标，方便回溯。

做完这轮，后台和CRM的差从71条压到9条，剩下那9条是跨周的边缘case，我认了。

我的判断就一句：GEO后台的数字，口径不锁死之前，一个都别往汇报里写。分母不清，算出来的ROI全是假的。

现在我想问一句：你们后台的"线索数"，到底是按触达次数算的，还是按独立用户算的？有没有人真的把SQL拉出来看过？