Eşleştirme, Birleştirme ve Hayatta Kalma

🌐 28 dilde daha mevcut

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

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 6. bölümü olan Ana Veri ve Kimlik bölümündeki 6 modülden 3.‘sü. Her modül kendi başına okunabilir. Önceki: Ana Veriyi Yönetmenin Dört Yolu · Sonraki: Harita Karar Değildir

Bu modülün yanıtladığı soru: Yinelenen kayıtları nasıl bulursunuz ve hangi değerlerin hayatta kalacağına nasıl karar verirsiniz?

Salesforce’ta iki kişi kaydı var: Daniel Reyes, Dallas, d.reyes@example.com ve Dan Reyes, Dallas, d.reyes@example.com. Aynı kişi mi? Muhtemelen. Onları birleştirmeli miyiz? Bu farklı bir soru. Ve birleştirirsek hangi telefon numarası, adres ve unvan hayatta kalır? Yine farklı. Mimarların üç kararı birbirinden ayrı tutması gerekir:

• Eşleştirme: bu kayıtlar aynı şeyi mi temsil ediyor?
• Birleştirme: tek bir kayda mı dönüşmeliler?
• Hayatta kalma (survivorship): veriyi birleştirirsek hangi değerler kazanır?

Önce Eşleştirme Gelir

3. bölüm Salesforce’un yinelenen kayıt ve eşleştirme kurallarını ele aldı; bu yüzden mekaniği yeniden öğretmeyeceğim. Mimari soru şudur: bunların aynı olabileceğini söylemek için hangi kanıt yeterince güçlü? Bir kişi için: e-posta, telefon, ad artı adres, bir müşteri numarası, bir birleşim. Bir şirket için: yasal ad, vergi numarası, ERP müşteri kimliği, adres, web alan adı. “Salesforce bu alanları karşılaştırabilir mi?” değil, “hangi birleşim bize harekete geçecek kadar güven veriyor?”

Ve tam eşleşme kesinlik değildir. Paylaşılan bir e-posta güçlü bir sinyaldir, kanıt değil: aileler adresleri paylaşır, işletmeler purchasing@company.com kullanır, telefon numaraları hanelere aittir, adlar ve adresler benzersiz değildir ve güçlü tanımlayıcılar bile yeniden kullanılır, yanlış yazılır ya da geri dönüştürülür. Eşleştirme metin karşılaştırması değildir. Kimlik hakkında bir ifadedir.

Yanılmanın Bedeli

Bunu öğretirken alanı değiştiririm. Otomotiv pazarlama verisinde iki Daniel Reyes’in aynı kişi olduğuna yanlışlıkla karar veririz ve yanlış olan bir SUV teklifi alır. İyi değil, ama düşük risk. Şimdi aynı yanlış eşleşmeyi tıbbi veride yapın: iki farklı kişinin tıbbi geçmişi birleştirilir. Aynı eşleştirme hatası, bambaşka bir sonuç. Evrensel bir “iyi” eşleştirme eşiğinin olmamasının nedeni bu. Bazen daha büyük risk bir eşleşmeyi kaçırmaktır; bazen aynı olmayan iki kişiyi birleştirmektir. Yanlış eşleşmelerin pahalı olduğu yerde bilerek eksik eşleştiririm.

Önce Uyumlaştırın, Sonra Eşleştirin, Sonra Konsolide Edin

Eşleştirme verinin biçimine de bağlıdır. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Uyumlaştırma değerleri karşılaştırılabilir kılar: standart biçimler, normalleştirilmiş kısaltmalar, eşlenmiş kodlar. Sonra eşleştirirsiniz. Ancak kayıtların birbirine ait olduğu bilindikten sonra bilgilerini tek bir temsilde konsolide edersiniz. Uyumlaştırmak eşleştirmek değildir, eşleştirmek birleştirmek değildir ve konsolide etmek mutlaka ana kaydı yönetmek değildir.

Click to enlarge

Kimlik kararları aşamalar halinde verilir.

Bir Eşleşme Birleştirme Gerektirmez

Bu, bölümdeki en önemli ayrımlardan biri. İki eski sistemden gelen iki müşteri kaydının aynı şirket olduğundan eminiz. Onları birleştirmek zorunda mıyız? Hayır. Her biri bir kaynak sistem kimliği taşıyor olabilir; tarihsel işlemler her birine işaret ediyor olabilir; denetçilerin izlere ihtiyacı olabilir; hâlâ taşıma yapıyor olabiliriz; eski sistemin tam olarak ne dediğini bilmemiz gerekebilir. İki kaydın aynı şey olduğunu bilmek bizi onları tek kayda indirmeye zorlamaz. Onları bağlayabiliriz ve bu çoğu zaman daha güvenli mimaridir.

Birleştirme Kuralım: Net Bir Kazanan

Pozisyonum: yalnızca net bir kazanan olduğunda ve yinelenen kayıt saklamanız gereken hiçbir şey eklemediğinde birleştirin. Bir temsilci dün yinelenen bir hesap oluşturdu; orijinali açıkça yerleşik kayıttır. İyi bir birleştirme adayı. Şimdi değiştirin: müşterileri kendi kimlikleri, daha eski değerleri, belki onlara bağlı işlemleri ya da denetim gereksinimleri olan eski bir sistemden içe aktardık. Çok daha temkinliyim. Eski değerlere geri izlemeniz gerekebilecekse harici yüklemelerden gelen yinelenen kayıtları tutun, çünkü birleştirme o geçmişi yok eder.

Bir Salesforce Birleştirmesi Gerçekte Ne Yapar

Bir bağlantı “bunlar birbirine ait” der. Bir birleştirme “bunlar artık tek” der ve Salesforce’ta bu gerçek bir değişikliktir. Hesaplar için en fazla üç kayıt seçer ve birini ana kayıt (principal) olarak belirlersiniz; diğerlerinin hangi alan değerlerinin korunacağını seçersiniz, gizli ve salt okunur alanlar ise ana kayıttan gelir. Birleştirilmiş kayıt, hangisi ana kayıt olursa olsun en eski kaydın Oluşturan ve Oluşturma Tarihi bilgisini korur. Ana kayıt olmayanlar Geri Dönüşüm Kutusu’na gider. Etkinlikler gibi ilgili kayıtlar, istisnalarıyla birlikte, birleştirilmiş kayda taşınır. Lightning’de birleştirme, yinelenen kayıt kurallarınızın tespit ettiği kayıtlar üzerinde çalışır. Ve kişi hesapları için iletişim noktası nesneleri birleştirmeyi desteklemez: ilişkileri kaybolur (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab), İngilizce).

Sınav bilgisi. Bir Salesforce hesap birleştirmesinin ne yaptığını bilin: en fazla üç kayıt; gizli ve salt okunur alanları korunan bir ana kayıt (principal); hangisi ana kayıt olursa olsun en eski kaydın Created By ve Created Date değerleri; diğer kayıtlar Geri Dönüşüm Kutusu’na gider; ve kişi hesapları için iletişim noktası nesneleri birleştirilmez.

Kararı vermek için her uç durumu bilmeniz gerekmez. Sonucu bilmeniz gerekir: bir birleştirmeden sonra başladığınız bağımsız kayıtlar yok olur. 1. bölümün Tersinirlik Testi geçerlidir: bağlamayı geri almak kolaydır; birleştirmeyi değil. Ve bir müşteri nadiren tek başına durur: kişiler, vakalar, fırsatlar, dosyalar, onay kayıtları, özel alt kayıtlar, harici kimlikler, entegrasyon referansları. Üst kaydı birleştirmeden önce ona bağlı her şeye ne olacağını anlayın. Yinelenen kayıtlar bir yüklemeyle geldiğinde ekiplere alt kayıtlar için üç seçenek veririm: hayatta kalan kayda taşıyın; kimsenin ihtiyacı yoksa hiç yüklemeyin; ya da aramada hâlâ çıksınlar diye diğer kayıtta, etkin değil olarak işaretleyip tutun. Birincisi, bir birleştirmenin sizin için yaptığı şeydir. Diğer ikisi izi korur ve çoğu zaman asıl mesele de budur.

Hayatta Kalma: Hangi Değer Kazanır?

Kayıtlar birbirine ait, ama çelişiyorlar: Salesforce ve faturalama 602-555-0100 diyor, ERP 602-555-0188 diyor. Hayatta kalma kuralları kazananı seçer. Yaygın olanlar: en yeni (son güncelleme), en sık (çoğu kaynağın üzerinde anlaştığı değer) ve kaynak önceliği (bu kaynağa şundan daha çok güven); artı birleşimler, eşikler, ağırlıklar ve işe özgü kurallar. Hiçbiri doğası gereği doğru değildir.

“En yeni” teknik bir ayar değildir. Güven hakkında bir ifadedir: sistemler çeliştiğinde en yeni değerin doğru olma olasılığı daha yüksektir. Bir cep telefonu numarası için makul. Bir yasal ad için berbat: sahibi ERP ise birinin beş dakika önce Salesforce kopyasını değiştirmesi umurumda değil. “En sık”, uzlaşmanın kanıt olduğunu varsayar, ama aşağı akıştaki üç bayat kopya kayıt kaynağını oylamada yenemez. “Kaynak önceliği” bunu açıkça söyler: bu kaynağa daha çok güveniyoruz. Dolayısıyla hayatta kalma kuralları mimariye ve yönetişime aittir ve her kuralın bir sahibe ihtiyacı vardır. En yeni adresin kazanacağına ya da ERP’nin Salesforce’tan üstün geleceğine kim karar verdi?

1. modülün yetki haritası kredi limitinin sahibinin ERP olduğunu zaten söylüyorsa hayatta kalma kolaydır: ERP kazanır, zekice bir puanlamaya gerek yok. Zor durumlar, yetkinin paylaşıldığı, belirsiz olduğu ya da tek bir ana kaynak yerine kanıta dayandığı özniteliklerdir. Hayatta kalma kurallarının hakkını verdiği yer orasıdır.

Click to enlarge

Hayatta kalma kuralları güven hakkında ifadelerdir.

Eşikler, İnceleme ve Zenginleştirme

Bazı eşleştirmeler kanıtı tartar: bir müşteri kimliği eşleşmesi çok güçlü, bir e-posta güçlü, bir telefon orta, benzer bir ad zayıf, benzer bir adres destekleyicidir. Bir puanın üzerinde eşleşme; bir diğerinin altında farklı; arada bir kişi inceler. Ders algoritma değildir. Eşik, hataya toleransınızdır ve iş riskini izlemelidir. Ve kanıt soruyu doğurup çözmediğinde sistemin bildiğini varsaymayın. İncelemeye yönlendirin. Daha yavaş ve bu sorun değil: iki farklı müşteriyi kendinden emin biçimde birleştiren otomasyon değerli değildir.

Zenginleştirme bir kaynak sorusu daha ekler. Posta referans verisi, sektör kodları, firma bilgileri, harici risk puanları ana veriyi iyileştirir; ama her değer nereden geldi, ne kadar güvenilir ve güncel, onu bu amaç için kullanabilir miyiz, kişisel veri içeriyor mu? Bir veri sağlayıcısından gelen “Sektör = Taşımacılık”, müşterinin size söylemesiyle aynı şey değildir. Bu ayrımı koruyun.

Steve Trucking: Benzer Aynı Değildir

İki Perakende Ortağı aynı telefon numarasıyla John Smith, 123 Main Street, Columbus adresine teslimat gönderiyor. Aynı kişi mi? Muhtemelen. Steve Trucking onları birleştirmeli mi? Kimin olduklarını hatırlayın: bu Alıcılar ortakların müşterileridir ve bir ortak asla bir başkasınınkini görmemelidir. Yanlış bir eşleşme veriyi o sınırın ötesine karıştırırdı. Birden bu bir veri kalitesi sorusu değil, bir gizlilik ve yalıtım sorusu olur; eşiklerin sonuçlara bağlı olmasının nedeni tam olarak budur. Kararı kontrol noktası veriyor. Şimdilik: eşleştirme kolaylığının iş kararını vermesine izin vermeyin.

Bazen karmaşayı korumak size bir şey söyler. Bu kayıt eski sistemden, şu Salesforce’tan, bu satın alınan şirketten geldi; kimlikleri, geçmişleri ve çeliştikleri gerçeği önemli olabilir. Temiz veri değerlidir. İzlenebilirlik de öyle. Kullanım için hangisinin daha önemli olduğuna mimar karar verir.

Sınavın ötesinde: yapay zekânın değiştirdikleri. Kötü bir eşleşme eskiden iki e-posta ya da bölünmüş bir servis geçmişi demekti. Şimdi bir ajan müşteri olduğunu düşündüğü kişiyi bulur ve onun siparişlerini, vakalarını, adreslerini ve notlarını çeker. İki kişi yanlışlıkla eşleştirildiyse bir kişinin bilgisine göre bir başkası için işlem yapabilir. Eşleştirme kararı güvenlik sınırının bir parçası haline geldi ve karıştırmanın pahalı olduğu yerde daha katı eşleştirme daha güvenli tasarımdır.

Mimarın Burada Karar Verdikleri

• Her veri alanında olası bir yinelenen kaydı işaretlemek için hangi kanıtın yeterli olduğu.
• Teyit edilmiş bir eşleşmenin birleştirmeye mi, bağlantıya mı yoksa insan incelemesine mi dönüşeceği.
• Çelişkide hangi değerlerin hayatta kalacağı ve her hayatta kalma kuralının sahibinin kim olduğu.
• İşin kaçırılan eşleşme riskine karşı ne kadar yanlış eşleşme riskini tolere edebileceği.
• Herhangi bir birleştirmeden önce hangi kaynak kimliklerinin, geçmişin ve ilgili kayıtların korunması gerektiği.

Dikkatle eşleştirin, bilinçli birleştirin, hayatta kalma kurallarını kasıtlı seçin. Oraya yanlış müşterileri birleştirerek vardıysanız temiz bir müşteri kaydı pek bir şeye değmez.

Daha Fazlası

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) ve Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.