比對、合併與存續規則
另有 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。