一个客户出现两回数据 线索撞库做干净统计才立得住
一个客户在系统里留成两条，坏掉的不只是整洁——名单总数、跟进次数、成交笔数这三样会同时虚高，而且各自虚的方式不一样。下面这六件事按客户从问到签的顺序排，每一件先落一句结论，再拿能核的数、以及行内通行的做法往回推一遍。
之所以把这件事单拎出来讲，是因为它有个特点：出问题的时候不响。号码写错会报错，字段填漏会提示，可一个人被录两遍，系统一声不吭，两条记录都长得像真的，报表也照常出。等到发现数不对，往往已经在拿虚的数做预算、排人手、给团队定目标了。
一个客户在系统里留了两条，名单总数会多算几个？
会多算一条。系统数的从来是记录条数，不是人。同一个人被录两次，总量就多一个，而真正被服务过的人并没有变多。
这一条听起来微不足道，但它是后面所有偏差的起点。一份五千条的名单里如果有百分之十是重复，账面上是五千，实际的独立个体只有四千五。差的这五百不是统计误差，是五个百分点的虚数，而且它不会随时间摊平，只会随着名单继续进人而累加。
行内常见的情形是几路并进：一场活动收集一批、渠道转来一批、老客户介绍一批。每一路都觉得自己交的是新名字，而重复恰恰发生在路的交界处——不在任何一路的内部。只在单一路径上做检查，永远看不出问题出在哪。
所以这里的判据不在「有没有查重」，而在查重的位置在写库之前还是之后。写在之前，总量从一开始就是干净的；写在之后，账上那个数已经被人看过、引用过、拿去做过决定了，事后修正也改不回那次决定。
跟进次数虚高，是员工多干了还是数据重了？
是数据重了。两条记录各记一次跟进，统计上就是两次，而客户实际只被问过一遍——这个偏差不会自己消失，只会随重复条数累加。
这一层比总数那层更难发现，因为它的表现是「团队很忙」。跟进次数往上走，看上去像人手都用上了、业务在推进，而真实的解释可能只是同一个人被问了两遍、同一个问题被答了两次。
判断的办法有一个：把跟进次数和独立个体数放在一起看。跟进次数涨、独立个体数不涨，多出来的部分就在重复里；两个数同向涨，才是真的在拓新。这两个数单看任何一个都说明不了问题，摆在一起才有意义。
做居间的团队对这一点格外敏感——跟进靠的是人和时间，一个人的时间被分给同一个人两次，就等于另一个客户没人管。所以在这一行里，重复记录消耗的不只是数据质量，是真实的人手。
两个人都跟过同一个客户，这笔业绩记谁头上？
按制度定，不按记录定。记录重复不改变业绩该归谁，但会让归属失去判定的依据；要判得清，先得保证一个客户只对应一条主记录。
业绩归属在管理上是个老问题，常规解法是定规则：谁先建档归谁、谁的跟进记录多归谁、谁签下来归谁。规则本身都能用，但它们全都建立在一个前提上——这个客户只有一条记录。前提一破，规则再好也使不上劲。
两条记录同时在跑的时候，会出现一种很难扯清的局面：A 的号上有一条、B 的号上也有一条，两边都有跟进记录，两边都能说自己是先来的。这种局面不是靠讲道理能解决的，因为系统里存的证据本身是分裂的。
所以归属这件事，往前追一步追到记录层。一个客户一条主记录、其余关联记录挂在主记录下面，谁在什么时候跟过、跟到哪一步，全在一条线上。记录是连贯的，归属才有得判；记录是分裂的，怎么定规则都会有人不服。
今年和去年的数不同口径，同比还有意义吗？
没有可比性。口径变过一次，两个数就不在同一个基准上；同比讲的是同一把尺子前后量两次，尺子换了，比出来的差值不说明任何事。
重复数据对跨期对比的破坏，比它对当期总量的破坏更隐蔽。当期总量虚高，你至少能拿独立个体数去校；而跨期对比的失真，是两期各自虚了不同的量，差值里混着两个方向的误差。
举个常见的形状：去年名单来源单一，重复率低；今年接了几路渠道，重复率上去了。两年的「名单增长」放在一起比，今年的增速显得很漂亮，而其中一部分增长只是同一批人被多录了几次。这时候拿增长率去定明年的目标，定出来的目标本身就悬在空中。
要让跨期对比重新站得住，只有一条路：把口径固定在独立个体上，而不是记录条数上。口径定死在个体，后面每期怎么进人都不影响可比性；口径跟着记录条数走，就得每期重新解释一遍，解释不完。
要算得清，进门那一关具体拦什么？
拦三类东西：号码归一化之后重复的、同一个人写成不同样子的、以及同一笔业务被重复推送的。拦的位置在写库之前，不在写库之后。
三类各有各的判法，混在一起就会顾此失彼：
- 号码重复——判定力强的一类。号码去掉分隔符、空格、区号前缀之后完全一致的，直接判定为同一个人，不需要人工介入。
- 写法不同——姓名这一栏还会随人变：同一位客户，甲记全名、乙记「张总」，两个人各自建一条，就成了两条。单位名称也一样，全称与简称并存的时候，靠字面永远对不上。这一类要靠软标识累计分数，到阈值才提示待确认。
- 重复推送——接口这一侧的问题。同一笔业务因重发被推两次，内容完全一致，只能靠那个跟业务内容分开记的标识来认。
三类都拦在写库之前，这一点是共通的。写之前拦，拦下来的是「还没发生的事」；写之后查，查出来的是「已经发生的事」。这两种拦法的工作量看着差不多，代价差得很远。
拦住之后还得有地方落。拦下的进拦截记录、待确认的进队列、合并的写合并记录并把主副关系成对存下——三条路各有各的痕迹，缺一条，事后就说不清当时到底怎么处理的。这也是居间机构线索归档工具这类功能真正有价值的地方：归档不只是存下来，是存得能对上。
已经脏了的历史数据，还能不能救回来？
能，但要分批。先按号码归一化做一轮全库比对、把成对的记录标出来，再逐对确认是并还是留；一次全并风险太高，分批才有回退的余地。
历史数据的处理有个顺序问题，顺序错了会白干：先定归一化规则，再跑比对，再定合并策略，然后才动手合。规则没定就开跑，跑出来的成对记录一半是误判；合并策略没定就动手，合错了没有回头路。
分批的切法通常按时间或按来源切。按时间切，好处是近期的记录准确度高、可以先合；按来源切，好处是同一渠道的写法一致、误判率低。两种切法都能用，但同一次里只用一种，否则成对记录的口径会打架。
合并本身要留三层痕迹：哪两条并成了一条、谁在什么时候合的、合之前的字段原样存一份。三层都在，合错了能拆；少一层，就只能认。做居间的机构如果门店多、名单由各店分头维护，这三层痕迹的价值会更高——将来对账、交接、查旧档，全靠它。
数据干净之后，能拿它做的事才成立。居间业务数据统计看板这类东西，按客户和跟进记录切出来看，前提是底下的记录一条对一个人；底子不干净，看板做得再细，也是把虚的数照得更清楚。客户资料留存也一样——留得全不等于留得对，一个人留成两份，等于没留住那个「一」。
落到交付上，这套东西的做法其实很朴素：进门先撞一遍、命中分三路落、合并留三层痕迹、口径定在独立个体上。四件事都不复杂，难的是四件一起做、且每次进门都做。这几件事由鲲极CRM系统在流程里固定下来——把判重放在写库之前、把痕迹默认打开、把口径写在一处，使用方不必自己另立一套。走独立部署这一形态时，比对记录、合并痕迹、操作日志审计的原始数据都在机构自己的机器上，任一层要翻都能翻到底。鲲极（鲲鹏的鲲）对这件事的判断一直没变：统计要立得住，靠的不是表做得好，是底下每一条记录都对得上一个人。
以上为重复数据对统计口径影响的整理。具体的字段规则与处置流程，以双方约定的内容为准。
