匹配、合并与存活规则
另有 28 种语言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 3 个模块，共 6 个，属于 Data Architect 课程第 6 章主数据与身份。每个模块都可以单独阅读。 上一篇：主控数据的四种方式 · 下一篇：地图不是决定
**本模块回答的问题：**如何找出重复，并决定哪些值存活下来？
Salesforce 里有两个联系人：Daniel Reyes，达拉斯，d.reyes@example.com；以及 Dan Reyes，达拉斯，d.reyes@example.com。是同一个人吗？多半是。我们应该合并它们吗？那是另一个问题。而如果合并，哪个电话号码、地址和职位存活下来？这又是另一个问题。架构师需要把三个决定分开：
- **匹配：**这些记录代表的是同一样东西吗？
- **合并：**它们应该变成一条记录吗？
- **存活规则：**如果我们合并数据，哪些值胜出？
第 3 章讲过 Salesforce 的重复规则和匹配规则，所以我不再重复机制。架构问题是：**什么证据强到足以说这些可能是同一个？**对一个人来说：电子邮件、电话、姓名加地址、一个客户编号，或者某种组合。对一家公司来说：法定名称、税号、ERP 客户 ID、地址、网站域名。问题不是“Salesforce 能比较这些字段吗？”，而是“什么组合能给我们足够的信心去采取行动？”
而且完全一致也不等于确定。一个共用的电子邮件是一个强信号，但不是证明：家人会共用地址，企业会用 purchasing@company.com，电话号码属于整个家庭，姓名和地址都不唯一，即使是很强的标识符也会被重复使用、输错或回收。匹配不是字符串比较，而是一个关于身份的声明。
出错的代价
Section titled “出错的代价 ”讲到这里时，我会换一个领域。在汽车营销数据中，我们错误地认定两个 Daniel Reyes 是同一个人，结果错误的那个人收到了一份 SUV 的优惠。不好，但风险很低。现在在医疗数据中犯同样的错误匹配：两个不同的人的病史被合并在一起。同样的匹配错误，完全不同的后果。这就是为什么不存在一个通用的“好”匹配阈值。有时更大的风险是漏掉一个匹配；有时是把两个不是同一个人的人合并在一起。在错误匹配代价高昂的地方，我会有意少匹配。
先协调，再匹配，然后整合
Section titled “先协调，再匹配，然后整合 ”匹配也取决于数据的形态。AZ、Arizona、Ariz.；6025550198、(602) 555-0198、+1 602 555 0198。协调让值变得可以比较：标准格式、规范化的缩写、映射后的代码。然后才去匹配。只有在知道记录属于一起之后，才把它们的信息整合成一个表示。协调不是匹配，匹配不是合并，而整合也不一定是主控。
身份决定是分阶段做出的。
匹配不要求合并
Section titled “匹配不要求合并 ”这是本章最重要的区别之一。我们确信来自两个旧系统的两条客户记录是同一家公司。我们必须合并它们吗？不必。每一条可能都带有一个源系统的身份；历史交易可能分别指向它们；审计人员可能需要这条轨迹；我们可能还在迁移中；我们可能需要确切知道旧系统当时是怎么说的。知道两条记录是同一样东西，并不会迫使我们把它们合二为一。我们可以把它们关联起来，而这往往是更安全的架构。
我的合并规则：有明确的胜出者
Section titled “我的合并规则：有明确的胜出者 ”我的立场是：**只有当有明确的胜出者、而且重复记录里没有任何你需要保留的东西时，才合并。**一位销售代表昨天创建了一个重复的客户；原来那条显然是已经确立的记录。很好的合并候选。现在换一种情况：我们从一个遗留系统导入了客户，带着它自己的 ID、较旧的值，也许还有与之相关的交易或审计要求。我就会谨慎得多。**当你可能需要回溯到较旧的值时，保留来自外部加载的重复记录，**因为合并会毁掉那份历史。
Salesforce 合并实际上做了什么
Section titled “Salesforce 合并实际上做了什么 ”关联说的是“这些属于一起”。合并说的是“这些现在是一个了”，而在 Salesforce 上这是一次真正的改变。对于客户，你选择最多三条记录，并选其中一条作为主记录；你挑选要保留其他记录的哪些字段值，而隐藏字段和只读字段来自主记录。合并后的记录保留最早那条记录的创建人和创建日期，不管哪条是主记录。**非主记录会进入回收站。**活动等相关记录会移到合并后的记录上，但有例外。在 Lightning 中，合并作用于你的重复规则检测到的重复记录。而对于个人客户，**联系点对象不支持合并：**它们的关系会丢失（Considerations for Merging Duplicate Accounts (opens in a new tab)；Merge Duplicate Accounts in Lightning Experience (opens in a new tab)，英文）。
考点。掌握 Salesforce 客户合并做了什么：最多三条记录；一条主记录（principal），保留它的隐藏字段和只读字段；保留最早那条记录的创建人和创建日期（Created By、Created Date），无论哪条是主记录；其他记录进入回收站；对于个人客户，联系点对象不会被合并。
你不需要了解每一个边缘情况才能做出决定。你需要的是后果：合并之后，你最初拥有的那些独立记录就没了。第 1 章的可逆性测试适用：关联很容易撤销；合并则不然。而且一个客户很少是孤立存在的：联系人、个案、业务机会、文件、同意记录、自定义子记录、外部 ID、集成引用。在合并父记录之前，先弄清楚挂在它上面的一切会怎样。当重复记录随一次加载进来时，我会就子记录给团队三个选择：把它们移到存活的记录上；如果没人需要，干脆不加载；或者把它们留在另一条记录上，并标记为不活跃，让它们仍然能在搜索中出现。第一种正是合并替你做的事。另外两种保留了痕迹，而这往往正是关键所在。
存活规则：哪个值胜出？
Section titled “存活规则：哪个值胜出？ ”记录属于一起，但它们的值不一致：Salesforce 和计费系统说 602-555-0100，ERP 说 602-555-0188。存活规则挑选胜出者。常见的有：最新（最近的一次更新）、最常见（大多数来源一致认同的值）、来源优先级（相信这个来源胜过那个来源），以及它们的组合、阈值、权重和特定于业务的规则。没有哪一条本身就是对的。
“最新”不是一个技术设置，而是一个关于信任的声明：**当系统之间不一致时，最新的值更有可能是正确的。**对于手机号码来说这很合理。对于法定名称来说就很糟糕：如果 ERP 拥有它，我才不在乎五分钟前有人改了 Salesforce 里的副本。“最常见”假定一致就是证据，但三份过时的下游副本并不能以多胜少地压过记录来源。“来源优先级”直截了当地说：**我们更信任这个来源。所以存活规则属于架构和治理，而且每一条规则都需要一个所有者。**是谁决定最新的地址胜出，或者 ERP 的优先级高于 Salesforce？
如果模块 1 的权威系统图已经说明 ERP 拥有信用额度，存活规则就很简单：ERP 胜出，不需要任何巧妙的评分。难的情况是那些权威是共享的、不清晰的，或者基于证据而不是某个单一主控方的属性。那才是存活规则发挥作用的地方。
存活规则是关于信任的声明。
阈值、审核与数据丰富
Section titled “阈值、审核与数据丰富 ”有些匹配会权衡证据：客户 ID 一致是非常强的证据，电子邮件一致是强证据，电话是中等，相似的姓名是弱证据，相似的地址是辅助证据。高于某个分数，算作匹配；低于另一个分数，算作不同；介于两者之间，由人来审核。算法不是重点。**阈值就是你对错误的容忍度，**而它应该跟随业务风险。当证据提出了问题却没有给出定论时，不要假装系统知道答案。把它转给人审核。这会慢一些，没关系：自动化如果信心十足地合并了两个不同的客户，就毫无价值了。
数据丰富又带来了一个来源问题。邮政参考数据、行业代码、企业信息、外部风险评分能改善主数据，但每个值从哪里来，有多可靠、多新，我们可以把它用于这个目的吗，它是否包含个人数据？来自数据供应商的“行业 = 运输”，和客户亲口告诉你的，不是一回事。要保留这种区别。
Steve Trucking：相似不等于相同
Section titled “Steve Trucking：相似不等于相同 ”两个零售合作伙伴都向 John Smith，123 Main Street，哥伦布，配送货物，电话号码也相同。是同一个人吗？多半是。Steve Trucking 应该把他们统一起来吗？记住他们是谁的：这些收货人是合作伙伴的客户，而一个合作伙伴绝不能看到另一个合作伙伴的。一次错误匹配会让数据跨越那条边界混在一起。突然之间，这就不再是一个数据质量问题，而是一个隐私和隔离问题，而这正是为什么阈值取决于后果。检查点会做出决定。现在请记住：不要让匹配上的便利去替你做业务决定。
有时保留这份混乱本身就能告诉你一些东西。这条记录来自旧系统，那条来自 Salesforce，这条来自被收购的公司；它们的 ID、它们的历史，以及它们彼此不一致这个事实，可能都很重要。干净的数据很有价值。可追溯性也是。由架构师来决定，对于这种用途，哪个更重要。
**考试之外：AI 改变了什么。**过去，一次糟糕的匹配意味着两封电子邮件或一份被拆开的服务历史。现在，一个智能体找到它认为的那个客户，然后拉出他们的订单、个案、地址和备注。如果两个人被错误地匹配了，它就可能把一个人的信息用在另一个人身上。匹配决定已经成为安全边界的一部分，而在混合代价高昂的地方，更严格的匹配是更安全的设计。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 在每个数据领域中，什么证据足以标记一个可能的重复。
- 一个确认的匹配是变成合并、关联，还是交给人审核。
- 值不一致时哪些值存活，以及谁拥有每一条存活规则。
- 相对于漏掉匹配的风险，业务能容忍多大的错误匹配风险。
- 在任何合并之前，必须保留哪些源身份、历史和相关记录。
谨慎地匹配，有意识地合并，有目的地选择存活规则。一条干净的客户记录，如果是靠合并错误的客户得来的，就没什么价值。
- Salesforce Help，Considerations for Merging Duplicate Accounts (opens in a new tab) 和 Merge Duplicate Accounts in Lightning Experience (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce Help，Things to Know About Duplicate Rules (opens in a new tab)（英文），查阅日期 2026-10-14。