Bản đồ không phải là quyết định

Cũng có bằng 28 ngôn ngữ khác

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

A road map spread on a table by a window, and outside, a single blank signpost at a fork in the lane pointing one way. — Hình ảnh được tạo bằng AI

Mô-đun 4 trong 6 của chương Dữ liệu chủ và danh tính, chương 6 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Khớp, gộp và giữ lại · Tiếp theo: Khi thẩm quyền được chia sẻ

Câu hỏi mô-đun này trả lời: Hồ sơ hợp nhất có giống với bản ghi vàng không?

Cùng một khách hàng nằm trong ba hệ thống. Salesforce biết Daniel Reyes, d.reyes@example.com, Dallas. Thương mại điện tử biết Dan Reyes, cùng email, Dallas, TX. Hỗ trợ biết Daniel Reyes, 214-555-0100, Dallas. Data 360 quyết định cả ba là cùng một người và xây một hồ sơ hợp nhất. Tuyệt vời. Chúng ta có bản ghi vàng chưa? Chưa chắc. Chúng ta biết các bản ghi thuộc về nhau; chúng ta chưa quyết định nguồn nào sở hữu sự thật. Điều này có thể gây bối rối cho nhiều người: phân giải danh tính tạo ra một cá nhân hợp nhất, nhưng không tạo ra bản ghi vàng. Vì vậy tôi dạy thẳng vào sự khác biệt:

Hồ sơ hợp nhất là một bản đồ. Bản ghi vàng là một quyết định.

Phân giải danh tính trả lời câu hỏi “Ai?”

Không có phân giải danh tính, một người xuất hiện dưới dạng các hồ sơ rời rạc: marketing thấy một hồ sơ, kinh doanh thấy hồ sơ khác, dịch vụ thấy hồ sơ khác nữa. Data 360 nạp chúng vào và dùng các quy tắc phân giải danh tính để quyết định những hồ sơ nào thuộc về nhau. Khi đó chúng ta có thể nói những bản ghi này có vẻ là cùng một người. Điều đó giải quyết danh tính. Nó không giải quyết việc quản lý dữ liệu chủ.

Và hồ sơ hợp nhất giữ bản đồ ngược về các nguồn của nó. Theo mô tả của chính Salesforce, một hồ sơ hợp nhất không phải là bản ghi vàng: nó là một tập hợp khóa, với các đối tượng liên kết danh tính nối ID của mỗi bản ghi nguồn với ID của hồ sơ hợp nhất (Data 360 Architecture (opens in a new tab), tiếng Anh). Người hợp nhất 10042 ánh xạ đến liên hệ Salesforce 003…, khách hàng thương mại điện tử EC-48372 và khách hàng hỗ trợ SUP-9128. Các bản gốc không biến mất. Điều đó rất gần với registry của mô-đun 2.

Click to enlarge

Hồ sơ hợp nhất là một tấm bản đồ dẫn ngược về các danh tính nguồn.

Quy tắc khớp: độ chặt là một quyết định về rủi ro

Data 360 quyết định ai được hợp nhất bằng cách nào? Quy tắc khớp. Các hồ sơ khớp khi mọi tiêu chí trong một quy tắc được thỏa mãn, và nếu bạn có nhiều quy tắc, khớp theo bất kỳ một quy tắc nào cũng tạo ra hồ sơ hợp nhất. Hướng dẫn của chính Salesforce: dùng nhiều tiêu chí hơn để chính xác (nhiều hồ sơ riêng biệt hơn), ít tiêu chí hơn để hợp nhất (Identity Resolution Match Rules (opens in a new tab), tiếng Anh). Vì vậy thêm tiêu chí vào một quy tắc làm nó chặt hơn; thêm các quy tắc thay thế mở rộng các cách mà hồ sơ có thể khớp. Cấu hình phân giải danh tính không phải là “bật việc khớp”. Đó là định nghĩa bằng chứng nào là đủ để nói những hồ sơ này là một người.

Khớp nhiều hơn không tự động tốt hơn. Mười triệu hồ sơ nguồn trở thành tám triệu hồ sơ hợp nhất. Nới lỏng các quy tắc, và giờ là sáu triệu. Tốt hơn? Có thể bạn đã tìm thấy thêm bản trùng. Hoặc có thể bạn đã bắt đầu trộn những người khác nhau. Một con số nhỏ hơn không phải là bằng chứng của dữ liệu tốt hơn. Mục tiêu không phải là ít hồ sơ nhất; mà là những danh tính có thể bảo vệ được nhất cho mục đích sử dụng. Và mỗi tiêu chí có một phương thức khớp: khớp chính xác, khớp chính xác sau chuẩn hóa, hoặc khớp mờ (Exact / Exact Normalized / Fuzzy) ở độ chính xác cao, trung bình hoặc thấp. Chính lời cảnh báo của Salesforce là điểm mấu chốt: một phương thức kém chính xác hơn làm tăng tỷ lệ hợp nhất, “nhưng có thể dẫn đến những lần khớp không mong muốn.” (Khớp mờ không dùng được cho các trường của Tài khoản, và các giá trị đã chuẩn hóa chỉ được dùng để so sánh; chúng không được lưu trong hồ sơ hợp nhất, đó chính là bước hài hòa hóa của mô-đun 3 đang vận hành: Identity Resolution Match Methods (opens in a new tab), tiếng Anh.) Phương thức càng lỏng, bản thân danh tính càng trở thành một sự phán đoán. Nếu nó sai, chúng ta chỉ cá nhân hóa một trang không tốt, hay cho một người xem lịch sử hỗ trợ của người khác, hay để một tác tử hành động trên dữ liệu của hai người?

Đó là lập trường của tôi: độ chặt của việc khớp là một quyết định về rủi ro. Nó phụ thuộc vào mức độ các trường dùng để khớp định danh một người duy nhất đến đâu và một lần khớp sai tốn bao nhiêu. Ở nơi việc trộn lẫn tốn kém, hãy cố ý khớp ít. Hai hồ sơ cho một người là bất tiện. Một hồ sơ chứa hai người có thể nguy hiểm.

Đối chiếu vẫn không phải là quản lý dữ liệu chủ

Khi các hồ sơ đã được hợp nhất, các nguồn vẫn bất đồng: Salesforce nói Dallas, thương mại điện tử nói Plano, hỗ trợ nói Dallas. Hồ sơ hợp nhất hiển thị gì? Quy tắc đối chiếu quyết định: Last Updated, Most Frequent hoặc Source Priority, đặt theo từng đối tượng và có thể ghi đè theo từng trường (Identity Resolution Reconciliation Rules (opens in a new tab), tiếng Anh). Điều đó nghe giống quy tắc giữ lại của mô-đun 3.

Đây là chỗ các đội gặp rắc rối. Hồ sơ hợp nhất hiển thị Dallas, và ai đó nói: “Tuyệt, Dallas là giá trị vàng của chúng ta.” Chậm lại. Thương mại điện tử vẫn nói Plano. Salesforce nói rõ rằng việc đối chiếu không xóa hay thay đổi dữ liệu nguồn hoặc cập nhật các hệ thống nguồn, và nó không nhằm chọn một giá trị “tốt nhất” cho mọi ứng dụng. Nó chỉ quyết định những gì hồ sơ hợp nhất hiển thị (cùng nguồn). Hiển thị không phải là thẩm quyền.

Kiến thức hay ra thi. Hãy biết phân giải danh tính của Data 360 quyết định và hiển thị như thế nào: trong một quy tắc khớp, tất cả các tiêu chí phải khớp, và chỉ cần bất kỳ một quy tắc nào khớp là các hồ sơ được hợp nhất (nhiều tiêu chí hơn để chính xác, ít tiêu chí hơn để hợp nhất nhiều); ba quy tắc đối chiếu là Last Updated, Most Frequent và Source Priority, đặt theo từng đối tượng và có thể ghi đè theo từng trường; và việc đối chiếu không thay đổi dữ liệu nguồn, và các điểm liên lạc không được đối chiếu.

Các điểm liên lạc còn làm điều này rõ hơn. Một người có thể có email cá nhân và email công việc, điện thoại di động và điện thoại nhà, tất cả đều hợp lệ. Data 360 hoàn toàn không đối chiếu các điểm liên lạc: mọi email và số điện thoại đều ở lại trên hồ sơ hợp nhất (cùng nguồn). Đôi khi nhiều giá trị chính là sự thật. “Hợp nhất” không có nghĩa là một giá trị cho mọi thứ.

Bản ghi vàng là một quyết định

Hãy so sánh với một yêu cầu quản lý dữ liệu chủ thực sự. Nghiệp vụ nói ERP có thẩm quyền đối với tên pháp lý, và giá trị được quản lý chủ là “Oakline Logistics LLC”. Salesforce, hệ thống thanh toán và dịch vụ đều phải dùng nó, và nếu một bên bất đồng, quy trình quản lý dữ liệu chủ đẩy giá trị được quản trị ngược lại. Đó là một kiến trúc khác. Chúng ta không chọn một cái nhìn hiển thị gì; chúng ta quyết định đây là giá trị doanh nghiệp sử dụng, và mọi hệ thống tham gia đều hội tụ về nó.

Vậy: một hồ sơ hợp nhất gom các danh tính và thông tin lại với nhau. Một bản ghi vàng là một quyết định được quản trị về những giá trị nào có thẩm quyền. Một hồ sơ hợp nhất có thể tạo nên một cái nhìn duy nhất tuyệt vời về khách hàng, được ghép từ các nguồn có thẩm quyền. Điều đó không biến nó thành hệ thống quản lý chủ khách hàng.

Click to enlarge

Hồ sơ hợp nhất là một tấm bản đồ. Bản ghi vàng là một quyết định.

Khả năng truy vết

Nếu hồ sơ hợp nhất nói Dallas, giá trị đó đến từ đâu: Salesforce, ERP, thương mại điện tử? Nó được chọn theo mới nhất, phổ biến nhất, hay ưu tiên nguồn? Nguồn gốc đó quan trọng cho kiểm toán, quyền riêng tư, khắc phục sự cố, sửa chất lượng dữ liệu và quyết định của tác tử, và trên hết là để biết việc sửa thuộc về đâu. Nếu Dallas sai, sửa cái nhìn đã được ghép không sửa được nguồn. Bạn cần các ID bên ngoài, các liên kết danh tính và các trường dòng dõi để truy ngược về bản ghi cần thay đổi.

Ba công cụ cho ba công việc

Đây là cách tôi tách bạch chúng:

Quản lý trùng lặp và gộp, bên trong một org Salesforce, khi có một bên thắng rõ ràng và bạn không còn cần các bản trùng (mô-đun 3).
Phân giải danh tính của Data 360, cho một danh tính và một cái nhìn duy nhất qua các nguồn mà không thay đổi chúng: một registry.
Một nền tảng MDM chuyên dụng, khi giá trị phải được quyết định một lần và đẩy ngược lại mọi hệ thống tham gia: cùng tồn tại hoặc tập trung.

Click to enlarge

Ba công cụ cho ba công việc: gộp, liên kết, quản lý chủ.

Đừng mua MDM khi bạn cần một bản đồ. “Chúng tôi muốn nhân viên dịch vụ thấy rằng khách hàng Salesforce này là cùng một người đã mua hàng trực tuyến” có thể cần phân giải danh tính và ngữ cảnh kết hợp, không phải MDM tập trung. “ERP, Salesforce, thương mại điện tử và hệ thống thanh toán đều phải dùng cùng một tên pháp lý được quản trị, và các thay đổi phải chảy ngược về tất cả” thì khác: đó là quản lý dữ liệu chủ. Đừng giải bài toán thứ hai khi bạn có bài toán thứ nhất, và đừng giả vờ bài toán thứ nhất đã giải được bài toán thứ hai.

Một danh tính không phải là một quyền

Phân giải danh tính nói những bản ghi này là một người. Điều đó không có nghĩa là mọi người thấy được một bản ghi nguồn đều được thấy mọi thứ gắn với danh tính hợp nhất. Một Đối tác bán lẻ có thể thấy các lần giao hàng mà mình đã gửi; các lần giao hàng của đối tác khác cho cùng Người nhận đó không phải việc của họ, dù tầng danh tính biết chúng có liên quan. Đồ thị danh tính có thể đúng trong khi thiết kế truy cập lại sai. Hợp nhất danh tính không xóa bỏ ranh giới bảo mật. Đó là lý do khớp quá mức trở thành vấn đề quyền riêng tư, và lý do điểm kiểm tra Steve Trucking xử lý việc hợp nhất Người nhận rất cẩn thận: một bản đồ ai là ai không trao quyền sở hữu, hay quyền truy cập.

Ngoài kỳ thi: AI thay đổi điều gì. Tác tử cần một danh tính để hành động, và hồ sơ hợp nhất cho chúng điều đó. Điều đó nâng mức rủi ro theo cả hai hướng. Khớp quá mức giờ là một sự cố quyền riêng tư: một tác tử hành động cho người này trên dữ liệu của người khác. Và một tác tử “cập nhật khách hàng” phải ghi vào hệ thống gốc của thuộc tính, dùng bản đồ thẩm quyền của mô-đun 1, không phải vào hồ sơ hợp nhất. Bản đồ cho tác tử biết người đó là ai; mô hình thẩm quyền cho nó biết một thay đổi thuộc về đâu.

Kiến trúc sư quyết định gì ở đây

Bằng chứng nào là đủ để hợp nhất hồ sơ, và cái giá của một lần khớp sai đặt ra độ chặt thế nào.
Những quy tắc đối chiếu nào quyết định những gì hồ sơ hợp nhất hiển thị.
Nhu cầu là dọn bản trùng trong một org, danh tính qua các nguồn, hay quản lý dữ liệu chủ doanh nghiệp thực sự.
Nguồn nào vẫn có thẩm quyền cho từng thuộc tính, ngay cả khi Data 360 hiển thị một giá trị đã được đối chiếu.
Danh tính hợp nhất tương tác thế nào với bảo mật, quyền riêng tư, nguồn gốc và hành động của tác tử.

Data 360 có thể cho chúng ta biết những hồ sơ này thuộc về nhau, cho chúng ta một danh tính hợp nhất, đối chiếu những gì nó hiển thị và giữ liên kết ngược về mọi nguồn. Điều đó vô cùng giá trị. Nhưng nếu Salesforce nói một đằng và ERP nói một nẻo, vẫn phải có ai đó quyết định hệ thống nào được thay đổi sự thật của doanh nghiệp. Vì vậy khi ai đó nói “chúng tôi có hồ sơ hợp nhất, nên chúng tôi có bản ghi vàng”, hãy hỏi: chúng ta đã hợp nhất dữ liệu, hay đã quản lý chủ nó?

Tìm hiểu thêm

Salesforce Architects, Data 360 Architecture (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
Salesforce Help, Data 360: Identity Resolution Match Rules (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) và Identity Resolution Reconciliation Rules (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.