Pencocokan, Penggabungan, dan Survivorship
Juga tersedia dalam 28 bahasa
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 3 dari 6 dalam bab Data Master dan Identitas, bab 6 kursus Data Architect. Setiap modul dapat dibaca secara mandiri. Sebelumnya: Empat Cara Mengelola Data Master · Berikutnya: Peta Bukanlah Keputusan
Pertanyaan yang dijawab modul ini: Bagaimana Anda menemukan duplikat, dan memutuskan nilai mana yang bertahan?
Salesforce punya dua kontak: Daniel Reyes, Dallas, d.reyes@example.com, dan Dan Reyes, Dallas, d.reyes@example.com. Orang yang sama? Mungkin. Haruskah kita menggabungkannya? Itu pertanyaan yang berbeda. Dan jika ya, nomor telepon, alamat, dan jabatan mana yang bertahan? Lain lagi. Arsitek perlu memisahkan tiga keputusan:
- Pencocokan: apakah rekaman-rekaman ini mewakili hal yang sama?
- Penggabungan: haruskah semuanya menjadi satu rekaman?
- Survivorship: jika kita menggabungkan data, nilai mana yang menang?
Pencocokan Datang Lebih Dulu
Section titled “Pencocokan Datang Lebih Dulu ”Bab 3 sudah membahas aturan duplikat dan aturan pencocokan Salesforce, jadi saya tidak akan mengajarkan ulang mekanismenya. Pertanyaan arsitekturnya adalah bukti apa yang cukup kuat untuk mengatakan bahwa semua ini mungkin sama? Untuk seseorang: email, telepon, nama ditambah alamat, nomor pelanggan, atau kombinasinya. Untuk perusahaan: nama resmi, NPWP atau nomor pajak, ID pelanggan ERP, alamat, domain web. Bukan “bisakah Salesforce membandingkan bidang-bidang ini?” melainkan “kombinasi apa yang memberi kita cukup keyakinan untuk bertindak?”
Dan persis sama belum tentu pasti. Email yang sama adalah sinyal kuat, bukan bukti: keluarga berbagi alamat, perusahaan memakai purchasing@company.com, nomor telepon dimiliki satu rumah tangga, nama dan alamat tidak unik, dan bahkan pengenal yang kuat bisa dipakai ulang, salah ketik, atau didaur ulang. Pencocokan bukanlah perbandingan string. Pencocokan adalah sebuah pernyataan tentang identitas.
Harga dari Sebuah Kesalahan
Section titled “Harga dari Sebuah Kesalahan ”Saat mengajarkan ini, saya mengganti domainnya. Dalam data pemasaran otomotif, kita keliru memutuskan bahwa dua orang bernama Daniel Reyes adalah orang yang sama, dan orang yang salah mendapat penawaran SUV. Tidak bagus, tetapi risikonya rendah. Sekarang buat kecocokan palsu yang sama dalam data medis: riwayat medis dua orang yang berbeda tergabung. Kesalahan pencocokan yang sama, konsekuensi yang sama sekali berbeda. Itulah sebabnya tidak ada ambang pencocokan “yang baik” yang universal. Kadang risiko yang lebih besar adalah melewatkan kecocokan; kadang risikonya adalah menggabungkan dua orang yang bukan orang yang sama. Di tempat kecocokan palsu itu mahal, saya sengaja melakukan pencocokan yang lebih sedikit (under-match).
Harmonisasi, lalu Pencocokan, lalu Konsolidasi
Section titled “Harmonisasi, lalu Pencocokan, lalu Konsolidasi ”Pencocokan juga bergantung pada bentuk datanya. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonisasi membuat nilai-nilai bisa dibandingkan: format standar, singkatan yang dinormalkan, kode yang dipetakan. Lalu Anda melakukan pencocokan. Baru setelah rekaman-rekaman diketahui saling terkait, Anda mengonsolidasikan informasinya ke dalam satu representasi. Harmonisasi bukanlah pencocokan, pencocokan bukanlah penggabungan, dan konsolidasi belum tentu pengelolaan master.
Keputusan identitas terjadi secara bertahap.
Kecocokan Tidak Mewajibkan Penggabungan
Section titled “Kecocokan Tidak Mewajibkan Penggabungan ”Ini salah satu pembedaan terpenting dalam bab ini. Kita yakin dua rekaman pelanggan dari dua sistem lama adalah perusahaan yang sama. Apakah kita harus menggabungkannya? Tidak. Masing-masing mungkin membawa identitas sistem sumber; transaksi historis mungkin menunjuk ke masing-masing; auditor mungkin butuh jejaknya; kita mungkin masih dalam proses migrasi; kita mungkin perlu tahu persis apa yang dikatakan sistem lama. Mengetahui bahwa dua rekaman adalah hal yang sama tidak memaksa kita meleburkannya. Kita bisa menautkannya, dan itu sering kali arsitektur yang lebih aman.
Aturan Penggabungan Saya: Pemenang yang Jelas
Section titled “Aturan Penggabungan Saya: Pemenang yang Jelas ”Posisi saya: gabungkan hanya ketika ada pemenang yang jelas dan duplikatnya tidak membawa apa pun yang perlu Anda simpan. Seorang sales membuat akun duplikat kemarin; yang asli jelas merupakan rekaman yang sudah mapan. Kandidat penggabungan yang baik. Sekarang ubah situasinya: kita mengimpor pelanggan dari sistem lama, dengan ID-nya sendiri, nilai-nilai lama, mungkin transaksi atau persyaratan audit yang terkait dengannya. Saya jauh lebih berhati-hati. Simpan duplikat dari muatan eksternal ketika Anda mungkin perlu menelusuri kembali nilai-nilai lama, karena penggabungan menghancurkan riwayat itu.
Apa yang Sebenarnya Dilakukan Penggabungan di Salesforce
Section titled “Apa yang Sebenarnya Dilakukan Penggabungan di Salesforce ”Tautan berkata “semua ini saling terkait.” Penggabungan berkata “semua ini sekarang satu,” dan di Salesforce itu perubahan yang nyata. Untuk akun, Anda memilih hingga tiga rekaman dan memilih satu sebagai principal; Anda memilih nilai bidang mana dari yang lain yang dipertahankan, sementara bidang tersembunyi dan read-only diambil dari principal. Rekaman hasil penggabungan mempertahankan Created By dan Created Date dari rekaman tertua, mana pun yang menjadi principal. Rekaman non-principal masuk ke Tempat Sampah. Rekaman terkait seperti aktivitas berpindah ke rekaman hasil penggabungan, dengan beberapa pengecualian. Di Lightning, penggabungan bekerja pada duplikat yang dideteksi aturan duplikat Anda. Dan untuk akun pribadi, objek contact point tidak mendukung penggabungan: hubungannya hilang (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).
Pengetahuan untuk ujian. Ketahui apa yang dilakukan penggabungan akun Salesforce: hingga tiga rekaman; satu rekaman utama (principal), yang bidang tersembunyi dan bidang baca-sajanya dipertahankan; Created By dan Created Date dari rekaman yang paling lama, mana pun yang menjadi rekaman utama; rekaman-rekaman lainnya masuk ke Tempat Sampah; dan untuk akun pribadi, objek contact point tidak digabungkan.
Anda tidak perlu mengetahui setiap kasus tepi untuk mengambil keputusan. Anda perlu tahu konsekuensinya: setelah penggabungan, rekaman-rekaman mandiri yang Anda miliki di awal sudah tidak ada. Uji Reversibilitas dari Bab 1 berlaku: menautkan mudah dibatalkan; menggabungkan tidak. Dan seorang pelanggan jarang berdiri sendiri: kontak, kasus, peluang, file, rekaman persetujuan, anak-anak kustom, ID eksternal, referensi integrasi. Sebelum menggabungkan induknya, pahami apa yang terjadi pada semua yang melekat padanya. Ketika duplikat datang bersama sebuah muatan data, saya memberi tim tiga pilihan untuk rekaman-rekaman anaknya: pindahkan ke rekaman yang bertahan; jangan dimuat sama sekali, jika tidak ada yang membutuhkannya; atau simpan pada rekaman lainnya, ditandai tidak aktif, agar tetap muncul dalam pencarian. Pilihan pertama adalah apa yang dilakukan penggabungan untuk Anda. Dua pilihan lainnya menjaga jejaknya, dan sering kali justru itulah intinya.
Survivorship: Nilai Mana yang Menang?
Section titled “Survivorship: Nilai Mana yang Menang? ”Rekaman-rekaman saling terkait, tetapi tidak sepakat: Salesforce dan sistem penagihan bilang 602-555-0100, ERP bilang 602-555-0188. Aturan survivorship memilih pemenangnya. Yang umum: paling baru (pembaruan terakhir), paling sering (nilai yang disepakati paling banyak sumber), dan prioritas sumber (percayai sumber ini di atas sumber itu), ditambah kombinasi, ambang, bobot, dan aturan khusus bisnis. Tidak satu pun yang pada dasarnya benar.
“Paling baru” bukanlah pengaturan teknis. Itu sebuah pernyataan tentang kepercayaan: ketika sistem-sistem tidak sepakat, nilai terbaru lebih mungkin benar. Masuk akal untuk nomor ponsel. Buruk sekali untuk nama resmi: jika ERP memilikinya, saya tidak peduli bahwa seseorang mengubah salinan di Salesforce lima menit lalu. “Paling sering” berasumsi bahwa kesepakatan adalah bukti, tetapi tiga salinan hilir yang basi tidak bisa mengalahkan suara sumber pencatatannya. “Prioritas sumber” mengatakannya dengan gamblang: kami lebih memercayai sumber ini. Jadi survivorship termasuk dalam arsitektur dan tata kelola, dan setiap aturan butuh pemilik. Siapa yang memutuskan bahwa alamat terbaru menang, atau bahwa ERP mengungguli Salesforce?
Jika peta otoritas di modul 1 sudah menyatakan ERP memiliki batas kredit, survivorship menjadi mudah: ERP menang, tanpa perlu penilaian yang cerdik. Kasus yang sulit adalah atribut yang otoritasnya dibagi, tidak jelas, atau berdasarkan bukti alih-alih satu master. Di situlah aturan survivorship membuktikan manfaatnya.
Aturan survivorship adalah pernyataan tentang kepercayaan.
Ambang, Tinjauan, dan Pengayaan
Section titled “Ambang, Tinjauan, dan Pengayaan ”Sebagian pencocokan menimbang buktinya: kecocokan ID pelanggan sangat kuat, email kuat, telepon sedang, nama yang mirip lemah, alamat yang mirip sebagai pendukung. Di atas satu skor, cocok; di bawah skor lain, berbeda; di antaranya, seseorang meninjaunya. Algoritmenya bukan pelajarannya. Ambang adalah toleransi Anda terhadap kesalahan, dan harus mengikuti risiko bisnis. Dan ketika buktinya memunculkan pertanyaan tanpa menuntaskannya, jangan berpura-pura sistemnya tahu. Teruskan untuk ditinjau. Lebih lambat, dan itu tidak apa-apa: otomatisasi tidak berharga jika ia dengan percaya diri menggabungkan dua pelanggan yang berbeda.
Pengayaan (enrichment) menambah satu pertanyaan asal-usul lagi. Data referensi pos, kode industri, data firmografis, skor risiko eksternal memang memperbaiki data master, tetapi dari mana setiap nilai berasal, seberapa andal dan terkini ia, apakah kita boleh memakainya untuk tujuan ini, apakah ia memuat data pribadi? “Industri = Transportasi” dari penyedia data tidak sama dengan pelanggan yang memberi tahu Anda. Pertahankan pembedaan itu.
Steve Trucking: Mirip Bukan Berarti Sama
Section titled “Steve Trucking: Mirip Bukan Berarti Sama ”Dua Mitra Ritel mengirim pengiriman ke John Smith, 123 Main Street, Columbus, dengan nomor telepon yang sama. Orang yang sama? Mungkin. Haruskah Steve Trucking menyatukannya? Ingat milik siapa mereka: para Penerima itu adalah pelanggan mitra, dan satu mitra tidak boleh pernah melihat pelanggan mitra lain. Kecocokan palsu akan mencampur data melintasi batas itu. Tiba-tiba ini bukan lagi soal kualitas data melainkan soal privasi dan isolasi, dan justru itulah sebabnya ambang bergantung pada konsekuensi. Checkpoint yang akan memutuskannya. Untuk sekarang: jangan biarkan kemudahan pencocokan yang mengambil keputusan bisnis.
Kadang membiarkan kekacauan justru memberi tahu Anda sesuatu. Rekaman ini datang dari sistem lama, yang itu dari Salesforce, yang ini dari perusahaan yang diakuisisi; ID-nya, riwayatnya, dan fakta bahwa semuanya tidak sepakat mungkin semuanya penting. Data yang bersih itu berharga. Begitu pula ketertelusuran. Arsitek memutuskan mana yang lebih penting untuk penggunaannya.
Di luar ujian: apa yang diubah AI. Dulu kecocokan yang buruk berarti dua email atau riwayat layanan yang terpecah. Sekarang sebuah agen menemukan apa yang dikiranya pelanggan itu lalu mengambil pesanan, kasus, alamat, dan catatannya. Jika dua orang keliru dicocokkan, agen bisa bertindak atas informasi satu orang untuk orang lain. Keputusan pencocokan telah menjadi bagian dari batas keamanan, dan di tempat pencampuran itu mahal, pencocokan yang lebih ketat adalah desain yang lebih aman.
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”- Bukti apa yang cukup untuk menandai kemungkinan duplikat di setiap domain data.
- Apakah kecocokan yang sudah dikonfirmasi menjadi penggabungan, tautan, atau tinjauan manusia.
- Nilai mana yang bertahan ketika terjadi ketidaksepakatan, dan siapa pemilik setiap aturan survivorship.
- Seberapa besar risiko kecocokan palsu yang bisa ditoleransi bisnis dibandingkan risiko kecocokan yang terlewat.
- Identitas sumber, riwayat, dan rekaman terkait mana yang harus dipertahankan sebelum penggabungan apa pun.
Cocokkan dengan hati-hati, gabungkan dengan sengaja, pilih aturan survivorship dengan sadar. Rekaman pelanggan yang bersih tidak banyak artinya jika Anda sampai ke sana dengan menggabungkan pelanggan yang salah.
Jelajahi
Section titled “Jelajahi ”- Bantuan Salesforce, Considerations for Merging Duplicate Accounts (opens in a new tab) dan Merge Duplicate Accounts in Lightning Experience (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
- Bantuan Salesforce, Things to Know About Duplicate Rules (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).