客户资料与统计口径

同一个客户常在销售登记、合同台账、回款记录里各留一条资料，报表算「客户数」前，要先回答哪几条算同一个客户。SZV 让同一个数只有一份口径；合并客户时，来源记录原样保留，只追加指向行。客户原始资料到不了模型，模型网关只给聚合数与令牌。

已有机制与示例设计

口径写成一行数据

口径指一个数怎么算、从哪里取。每个指标的口径是口径定义表里的一行：

报表、物化、导出、汇总与总览取同一份片段，不各算各的。示例：「客户数」的去重键是主记录号，一个客户有三条来源记录，也只数一次。

改口径是新增一行、旧行退役，历史数据按书面执行令重算。重算后已发出的报表值怎样保留，见资金流水与更正里的说明。

想知道一个数怎么来的，看一行口径，不必翻各个报表。

来源记录与指向行

以下用设计口吻描述，不是已有功能。客户资料设计为如下记录：

报表设计为读「每个来源当前指向哪条主记录」，即每个来源最新的一行指向。所以撤销合并设计为追加：新增一行，把这条来源指回原来的主记录，旧行不动。

一次合并设计为如下步骤：

1. 发起人列出要并的来源记录与目标主记录，写明理由。
2. 合并设计为走审批，发起人不签自己的单，其余按审批流转的审批链。
3. 批准后，设计为给每条来源记录追加一行指向，带审批单号。
4. 写留痕：谁、何时、哪几条来源指向哪条主记录、依据哪张审批单。

没有通过审批，主记录与指向设计为保持原样。审计时可以按审批单号，查到谁批了合并、合并了哪几条。

匹配与字段取舍

存储方式只决定合并能不能追溯、能不能撤销。真难的是匹配和字段取舍。

匹配：哪些来源记录是同一个客户。认错有两种代价：把两个客户并成一个（误合并），把一个客户留成两个（漏合并）。通行的做法是实体解析：给每一对记录算一个匹配概率，再据此分层。

Splink 是一个开源的实体解析库，核心算法基于 Fellegi-Sunter 模型，给出成对的匹配概率，再把链接聚成实体。按概率分层，高的由系统提议、低的交人看，是常见用法，阈值怎么取要看数据。示例设计对此不分高低：无论哪一档，合并动作都设计为走审批。

字段取舍：两条来源记录对同一个字段写了不同的值，主记录取哪个，规则怎么写，业界叫字段胜出规则。设计为在设计阶段定下这条规则，写成数据，不写在程序里。

匹配规则在诊断与设计阶段，对着企业自己的数据确定，不预设算法。

从诊断到运营

同样是设计口吻，各阶段设计为这样做：

上线前设计为核对：用一个客户走通，从发起合并、批准，到报表只算一次、按审批单号查到留痕；负责人确认匹配规则。

限制与不适用

匹配规则要对着企业自己的数据定，误合并与漏合并各有代价。示例设计还要在设计阶段补上下表的几条约束；下表是设计推理，现有机制里没有对应的实现。

来源只有一个，或者客户号本来就全局唯一时，不需要合并这一层。

其他做法

验收时可以问的问题

• 请说明匹配规则由谁定、由谁确认，误合并与漏合并的代价各按什么评估。
• 请说明字段冲突时主记录取哪个值，这条规则由谁在设计阶段定。

相关页

• 资金流水与更正：同一份口径怎样用对账自检逐日核对。
• 审批流转：合并审批怎样走。
• 留痕与证据链：合并的记录凭什么不可改写。
• 两周诊断交付什么：客户资料合并怎样进入改造清单。