Harita Karar Değildir
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)
Data Architect kursunun 6. bölümü olan Ana Veri ve Kimlik bölümündeki 6 modülden 4.‘sü. Her modül kendi başına okunabilir. Önceki: Eşleştirme, Birleştirme ve Hayatta Kalma · Sonraki: Yetki Paylaşıldığında
Bu modülün yanıtladığı soru: Birleşik bir profil, bir altın kayıtla aynı şey midir?
Aynı müşteri üç sistemde duruyor. Salesforce Daniel Reyes, d.reyes@example.com, Dallas’ı biliyor. E-ticaret Dan Reyes’i, aynı e-postayı, Dallas, TX’i biliyor. Destek Daniel Reyes’i, 214-555-0100’ü, Dallas’ı biliyor. Data 360 üçünün de aynı kişi olduğuna karar veriyor ve birleşik bir profil oluşturuyor. Mükemmel. Bir altın kaydımız var mı? Mutlaka değil. Kayıtların birbirine ait olduğunu biliyoruz; doğrunun sahibinin hangi kaynak olduğuna karar vermedik. Bu insanların kafasını karıştırabilir: kimlik çözümleme birleşik bir birey oluşturur, ama bir altın kayıt oluşturmaz. Bu yüzden farkı doğrudan öğretirim:
Birleşik profil bir haritadır. Altın kayıt bir karardır.
Kimlik Çözümleme “Kim?” Sorusunu Yanıtlar
Bölüm başlığı “Kimlik Çözümleme “Kim?” Sorusunu Yanıtlar ”Kimlik çözümleme olmadan tek bir kişi birbirinden kopuk profiller olarak görünür: pazarlama birini, satış bir başkasını, servis bir başkasını görür. Data 360 onları alır ve hangilerinin birbirine ait olduğuna karar vermek için kimlik çözümleme kurallarını kullanır. Sonra bu kayıtların aynı kişi gibi göründüğünü söyleyebiliriz. Bu kimliği çözer. Ana veri yönetimini çözmez.
Ve birleşik profil kaynaklarına geri haritayı tutar. Salesforce’un kendi tanımıyla birleşik bir profil altın kayıt değildir: her kaynak kaydın kimliğini birleşik profilin kimliğine bağlayan kimlik bağlantısı nesneleriyle birlikte bir anahtarlar kümesidir (Data 360 Architecture (opens in a new tab), İngilizce). Birleşik kişi 10042, Salesforce kişisi 003…, e-ticaret müşterisi EC-48372 ve destek müşterisi SUP-9128 ile eşlenir. Orijinaller yok olmaz. Bu, 2. modülün kayıt defterine çok yakındır.
Birleşik profil, kaynak kimliklere geri giden bir haritadır.
Eşleştirme Kuralları: Katılık Bir Risk Kararıdır
Bölüm başlığı “Eşleştirme Kuralları: Katılık Bir Risk Kararıdır ”Data 360 kimin birleştirileceğine nasıl karar verir? Eşleştirme kuralları. Profiller, bir kuraldaki tüm ölçütler karşılandığında eşleşir ve birkaç kuralınız varsa herhangi birindeki eşleşme birleşik profili oluşturur. Salesforce’un kendi önerisi: doğruluk için daha fazla ölçüt (daha fazla ayrı profil), konsolidasyon için daha az ölçüt (Identity Resolution Match Rules (opens in a new tab), İngilizce). Yani bir kurala ölçüt eklemek onu katılaştırır; alternatif kurallar eklemek profillerin eşleşme yollarını genişletir. Kimlik çözümlemeyi yapılandırmak “eşleştirmeyi aç” demek değildir. Bu profillerin tek bir kişi olduğunu söylemek için hangi kanıtın yeterli olduğunu tanımlamaktır.
Daha fazla eşleştirme otomatik olarak daha iyi değildir. On milyon kaynak profil sekiz milyon birleşik profile dönüşür. Kuralları gevşetin, artık altı milyon. Daha mı iyi? Belki daha fazla yinelenen kayıt buldunuz. Ya da belki farklı insanları birleştirmeye başladınız. Daha küçük bir sayı daha iyi verinin kanıtı değildir. Hedef en az profil değil; amaç için en savunulabilir kimliklerdir. Ve her ölçütün bir eşleştirme yöntemi vardır: Exact, Exact Normalized ya da yüksek, orta veya düşük hassasiyette Fuzzy. Salesforce’un kendi uyarısı asıl noktadır: daha az hassas bir yöntem birleştirme oranını yükseltir, “ama istenmeyen eşleşmelere yol açabilir.” (Fuzzy, Hesap alanları için kullanılamaz ve normalleştirilmiş değerler yalnızca karşılaştırma için kullanılır; birleşik profilde saklanmaz; bu, 3. modülün uyumlaştırma adımının iş başında olmasıdır: Identity Resolution Match Methods (opens in a new tab), İngilizce.) Yöntem ne kadar gevşekse kimliğin kendisi o kadar bir yargıya dönüşür. Yanlışsa yalnızca bir sayfayı kötü kişiselleştirmiş mi oluruz, yoksa bir kişinin destek geçmişini başkasına mı gösteririz ya da bir ajanın iki kişinin verisine göre işlem yapmasına mı izin veririz?
Pozisyonum bu: eşleştirme katılığı bir risk kararıdır. Eşleştirme alanlarının bir kişiyi ne kadar benzersiz tanımladığına ve yanlış bir eşleşmenin bedeline bağlıdır. Karıştırmanın pahalı olduğu yerde bilerek eksik eşleştirin. Tek bir kişi için iki profil zahmetlidir. İki kişiyi tutan tek bir profil tehlikeli olabilir.
Uzlaştırma da Yönetmek Değildir
Bölüm başlığı “Uzlaştırma da Yönetmek Değildir ”Profiller birleştirildikten sonra kaynaklar hâlâ çelişir: Salesforce Dallas, e-ticaret Plano, destek Dallas diyor. Birleşik profil neyi gösterir? Uzlaştırma kuralları karar verir: Last Updated, Most Frequent ya da Source Priority; nesne başına ayarlanır ve alan başına geçersiz kılınabilir (Identity Resolution Reconciliation Rules (opens in a new tab), İngilizce). Bu, 3. modülün hayatta kalma kurallarını hatırlatmalı.
Ekiplerin başının derde girdiği yer burası. Birleşik profil Dallas gösteriyor ve biri “Harika, Dallas bizim altın değerimiz” diyor. Yavaş. E-ticaret hâlâ Plano diyor. Salesforce, uzlaştırmanın kaynak veriyi silmediğini ya da değiştirmediğini veya kaynak sistemleri güncellemediğini açıkça söylüyor ve her uygulama için “en iyi” bir değer seçmek amacıyla tasarlanmamış. Yalnızca birleşik profilin neyi gösterdiğine karar veriyor (aynı kaynak). Gösterim yetki değildir.
Sınav bilgisi. Data 360 kimlik çözümlemesinin nasıl karar verdiğini ve gösterdiğini bilin: bir eşleştirme kuralında tüm ölçütler eşleşmelidir ve herhangi bir kuralın eşleşmesi profilleri birleştirir (doğruluk için daha çok ölçüt, birleştirme için daha az); üç uzlaştırma kuralı Last Updated, Most Frequent ve Source Priority’dir, nesne başına ayarlanır ve alan başına geçersiz kılınabilir; ve uzlaştırma kaynak veriyi değiştirmez ve iletişim noktaları uzlaştırılmaz.
İletişim noktaları bunu daha da netleştirir. Bir kişinin kişisel ve iş e-postası, cep ve ev telefonu olabilir; hepsi meşrudur. Data 360 iletişim noktalarını hiç uzlaştırmaz: her e-posta ve telefon birleşik profilde kalır (aynı kaynak). Bazen birkaç değer düpedüz gerçeğin kendisidir. “Birleşik” her şey için tek değer demek değildir.
Altın Kayıt Bir Karardır
Bölüm başlığı “Altın Kayıt Bir Karardır ”Gerçek bir ana veri yönetimi gereksinimini karşılaştırın. İş birimi yasal ad için esas kaynağın ERP olduğunu ve yönetilen değerin “Oakline Logistics LLC” olduğunu söylüyor. Salesforce, faturalama ve servisin hepsi onu kullanmalı ve biri çelişirse yönetim süreci yönetilen değeri geri gönderir. Bu farklı bir mimaridir. Tek bir görünümün ne göstereceğini seçmiyoruz; kurumun kullandığı değerin bu olduğuna ve katılan her sistemin onda birleştiğine karar veriyoruz.
Yani: bir birleşik profil kimlikleri ve bilgileri bir araya getirir. Bir altın kayıt, hangi değerlerin esas olduğuna dair yönetilen bir karardır. Birleşik bir profil, esas kaynaklardan bir araya getirilmiş mükemmel bir tek müşteri görünümü olabilir. Bu onu müşterinin ana kaydını yöneten sistem yapmaz.
Birleşik profil bir haritadır. Altın kayıt bir karardır.
İzlenebilirlik
Bölüm başlığı “İzlenebilirlik ”Birleşik profil Dallas diyorsa bu nereden geldi: Salesforce’tan mı, ERP’den mi, e-ticaretten mi? Last Updated, Most Frequent, Source Priority ile mi seçildi? Bu kaynak bilgisi denetim, gizlilik, sorun giderme, veri kalitesini düzeltme ve ajan kararları için ve her şeyden önce bir düzeltmenin nereye ait olduğunu bilmek için önemlidir. Dallas yanlışsa bir araya getirilmiş görünümü düzenlemek kaynağı düzeltmez. Değişmesi gereken kayda geri izlemek için harici kimliklere, kimlik bağlantılarına ve köken alanlarına ihtiyacınız vardır.
Üç İş İçin Üç Araç
Bölüm başlığı “Üç İş İçin Üç Araç ”Onları şöyle ayırırım:
- Yinelenen kayıt yönetimi ve birleştirme, tek bir Salesforce org’u içinde, net bir kazanan olduğunda ve yinelenen kayıtlara artık ihtiyacınız olmadığında (3. modül).
- Data 360 kimlik çözümleme, kaynaklar genelinde onları değiştirmeden tek bir kimlik ve tek bir görünüm için: bir kayıt defteri.
- Özel bir MDM platformu, değerlerin bir kez karara bağlanıp katılan her sisteme geri gönderilmesi gerektiğinde: birlikte var olma ya da merkezî.
Üç iş için üç araç: birleştir, bağla, yönet.
Bir haritaya ihtiyacınız varken MDM satın almayın. “Servis temsilcisinin bu Salesforce müşterisinin çevrimiçi alışveriş yapan kişiyle aynı olduğunu görmesini istiyoruz” merkezî MDM’e değil, kimlik çözümlemeye ve birleştirilmiş bağlama ihtiyaç duyabilir. “ERP, Salesforce, e-ticaret ve faturalamanın hepsi aynı yönetilen yasal adı kullanmalı ve değişiklikler hepsine geri akmalı” farklıdır: bu ana veri yönetimidir. Birincisine sahipken ikincisini çözmeyin ve birincisinin ikincisini çözdüğünü varsaymayın.
Tek Kimlik Tek İzin Değildir
Bölüm başlığı “Tek Kimlik Tek İzin Değildir ”Kimlik çözümleme bu kayıtların tek bir kişi olduğunu söyler. Bu, bir kaynak kaydı görebilen herkesin birleşik kimliğe bağlı her şeyi görebileceği anlamına gelmez. Bir Perakende Ortağı gönderdiği teslimatları görebilir; başka bir ortağın aynı Alıcıya yaptığı teslimatlar, kimlik katmanı ilişkili olduklarını bilse bile onu ilgilendirmez. Kimlik grafiği doğru olabilirken erişim tasarımı yanlış olabilir. Kimliği birleştirmek güvenlik sınırlarını silmez. Aşırı eşleştirmenin bir gizlilik sorununa dönüşmesinin ve Steve Trucking kontrol noktasının Alıcıları birleştirmeyi bu kadar dikkatle ele almasının nedeni bu: kimin kim olduğunun haritası sahiplik ya da erişim vermez.
Sınavın ötesinde: yapay zekânın değiştirdikleri. Ajanların üzerinde işlem yapacakları tek bir kimliğe ihtiyacı vardır ve birleşik profil onu onlara verir. Bu riskleri iki yönde de artırır. Aşırı eşleştirme artık bir gizlilik olayıdır: bir kişi adına başka birinin verisine göre işlem yapan bir ajan. Ve “müşteriyi güncelleyen” bir ajan, birleşik profile değil, 1. modülün yetki haritasını kullanarak özniteliğin kayıt sistemine yazmalıdır. Harita ajana kişinin kim olduğunu söyler; yetki modeli de bir değişikliğin nereye ait olduğunu.
Mimarın Burada Karar Verdikleri
Bölüm başlığı “Mimarın Burada Karar Verdikleri ”- Profilleri birleştirmek için hangi kanıtın yeterli olduğu ve yanlış bir eşleşmenin bedelinin katılığı nasıl belirlediği.
- Birleşik profilin neyi göstereceğine hangi uzlaştırma kurallarının karar verdiği.
- İhtiyacın tek bir org’da yinelenen kayıt temizliği mi, kaynaklar genelinde kimlik mi yoksa gerçek kurumsal ana veri yönetimi mi olduğu.
- Data 360 uzlaştırılmış bir değer gösterse bile her öznitelik için hangi kaynağın esas kaldığı.
- Birleşik kimliğin güvenlik, gizlilik, kaynak bilgisi ve ajan eylemleriyle nasıl etkileştiği.
Data 360 bize bu profillerin birbirine ait olduğunu söyleyebilir, birleşik bir kimlik verebilir, gösterdiğini uzlaştırabilir ve her kaynağa geri bağlantıları tutabilir. Bu muazzam derecede değerlidir. Ama Salesforce bir şey, ERP başka bir şey diyorsa birinin yine de kurumsal doğruyu hangi sistemin değiştirebileceğine karar vermesi gerekir. Bu yüzden biri “birleşik bir profilimiz var, o halde altın kaydımız var” dediğinde sorun: veriyi birleştirdik mi, yoksa ana kaydını mı yönettik?
Daha Fazlası
Bölüm başlığı “Daha Fazlası ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (İngilizce), kontrol tarihi 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) ve Identity Resolution Reconciliation Rules (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.