我让技术把GEO后台的线索ID和CRM的成交ID用SQL对了一遍，发现两边去重逻辑根本不是一回事

我直接说怎么做。

上周三下午，销售总监把我叫过去，甩了一张表：GEO后台显示本月线索37条，CRM里只录进去11个销售机会。他问我：“剩下26条是被你吃了还是被系统吃了？”

我没急着解释，先干了三件事。

第一步：把两边ID拉出来做全量比对

我让技术写了条SQL，从GEO后台的lead_id和CRM的opportunity_id各自抽出来，用手机号+创建时间做哈希，做full outer join。结果出来我盯着屏幕看了半分钟——两边能对上的只有9条，剩下的28条里，有14条手机号在两边都有但时间戳差了超过24小时，另外14条CRM里压根没有。

第二步：查去重逻辑，发现口径完全不同

这里就是坑。GEO后台的去重逻辑是“同一手机号24小时内多次咨询算一条”，用的是首次触发时间。CRM的去重逻辑是“同一手机号同一销售名下不重复建机会”，用的是销售手动创建时间。

问题来了：一个客户早上9点点了GEO的咨询按钮，留了电话，后台记了一条，时间戳09:00。销售下午2点才在CRM里手动录入这条线索，CRM记录的时间戳是14:00。这时候另一个渠道晚上8点又触达了同一个客户，客户又点了咨询，GEO后台因为超过24小时，又记了一条，时间戳20:00。

在GEO后台看：两条线索，09:00和20:00。
在CRM看：一条机会，14:00。

这账对得上才有鬼。

第三步：把分母口径写死，再重算

我让技术把两边的时间锚点统一到一个字段：first_touch_time，取GEO后台的首次触发时间。然后CRM端也强制用这个字段做去重基准，不认销售手动录入时间。

重算之后，37条线索变成23条有效线索，CRM里能匹配上的变成19条。剩下4条是客户留了电话但销售没跟进，那是执行问题，不是数据问题。

我的判断

GEO后台的“线索数”和CRM的“机会数”本来就是两个东西，但很多公司直接拿前者除以后者算转化率，这跟拿苹果数除以橘子数没区别。

你要做的不是吵谁对谁错，是先把两个系统的去重维度和时间锚点拉出来对齐。对不齐，后面所有归因都是假的。

最后问一句

你们公司GEO后台的线索去重，是按“首次触发时间”还是“最后触发时间”？CRM那边认不认这个字段？如果两边时间锚点不一样，你们是怎么做跨系统归因的？评论区说说，我看看有没有更野的路子。