Veri zenginleştirme: kaynağına kadar izlenebilen öznitelikler eklemek

İş kayıtlarının çoğu zayıf başlar. CRM’deki bir satırda şirket adı ve web sitesi vardır; tedarikçi listesinde ad ve vergi numarası; kayıt formunda ise yalnızca bir e-posta adresi. Veri zenginleştirme, kaydın geri kalanını başka kaynaklardan doldurma işidir; böylece kayıt yönlendirme, puanlama, araştırma ya da müşteri kabul kontrolleri için işe yarar hâle gelir. İyi yapıldığında insanları saatlerce süren elle aramalardan kurtarır. Özensiz yapıldığında ise sistemlerinizi kimsenin izini süremediği, akla yatkın değerlerle doldurur ve bu değerler, nereden geldiklerini hatırlayan herkesten daha uzun yaşar.

Zenginleştirme nedir, ne değildir

Zenginleştirme, elinizdeki bir kaydı alır, onun gerçek dünyada hangi varlığa karşılık geldiğini belirler ve o varlığa dair öznitelikleri başka bir kaynaktan ekler. Üç adımı vardır ve her biri kendine özgü biçimde ters gidebilir:

1. Belirleme. Anahtarı seçin: alan adı, sicil numarası, e-posta adresi, ürün kodu.
2. Eşleştirme. Aynı varlığı kaynakta bulun. Hataların çoğu burada doğar.
3. Ekleme. Yeni değerleri yazın; tercihen her birinin nereden geldiğine dair bir notla birlikte.

Zenginleştirmenin yanında, kolayca karıştırılan birkaç komşu iş durur. Veri temizleme, zaten elinizde olan değerleri düzeltir ya da standartlaştırır; ülke kodlarını düzeltmek ya da tekrarları ayıklamak gibi. Keşif ya da potansiyel müşteri bulma, henüz sahip olmadığınız kayıtları bulur; örneğin belirli bir profile uyan şirketleri. Bilgi çıkarma, değerleri dokümanların içinden çeker. Zenginleştirme çoğu zaman bilgi çıkarmayı kullanır ve keşfi besler, ama başlangıç noktası her zaman var olan bir kayıttır.

Yaygın zenginleştirme türleri

Türü, desteklediği karara göre seçin. Zenginleştirilen alan gelen bir potansiyel müşteriyi doğru ekibe yönlendirecekse büyüklük ve bölge yetebilir. Bir kredi ya da müşteri kabul kontrolünü besleyecekse bir sağlayıcının tahmini değil, sicil kaydının kendisi gerekir.

Değerler nereden gelir

Kaynaklar biçimden çok, bir değer hakkında sonradan neler söyleyebileceğinizle ayrışır.

• Kendi materyaliniz. Sözleşmeler, faturalar, müşteri kabul formları ve yazışmalar çoğu zaman yanıtı zaten içerir. Değerin tam olarak nereden geldiğini bildiğiniz için savunması en kolay kaynaktır.
• Resmî siciller ve bildirimler. Hukuki olgular için yetkili kaynaktır; ancak kapsam, biçim ve erişim kuralları ülkeden ülkeye değişir.
• Şirketin kendi yayımladığı sayfalar. Güncel ve özgüldür, ama şirketin kendini anlatışıdır ve zaman zaman olandan çok olunmak istenene işaret eder.
• Ticari veri sağlayıcılar. Tek bir arayüzden geniş kapsam sunar. Her alanın nasıl elde edildiğini, ne sıklıkla yenilendiğini ve lisansın onunla ne yapmanıza izin verdiğini kontrol edin; seçim soruları veri zenginleştirme API’leri yazısında.
• Ajanların yürüttüğü web araştırması. Kimsenin satmadığı alanlar için esnektir, kayıt başına daha yavaştır ve ancak sakladığı kanıt kadar iyidir. Bu iş akışını satış verisi için web zenginleştirme yazısı ele alıyor.

Kişilere dair zenginleştirme ek yükümlülükler getirir. Kişisel öznitelikler eklemeden önce, size uygulanan veri koruma kuralları çerçevesinde işlemenin hukuki dayanağını ve kaynağın şartlarının aklınızdaki kullanıma izin verip vermediğini kontrol edin.

Kaliteyi eşleştirme belirler

Yanlış bir eşleşme, eksik bir değerden daha çok zarar verir; çünkü veri gibi görünür. CRM’nizdeki “Acme Ltd”, benzer adlı birkaç şirketten biri, bir grubun içindeki bağlı şirket ya da o zamandan beri adını değiştirmiş bir işletme olabilir. Yalnızca ada göre eşleştirmek klasik hatadır.

Savunulabilir bir eşleştirme kuralı, hangi kanıtı aradığını açıkça söyler:

eşleşmeyi yalnızca şu durumda kabul et:
  - sicil numarası eşleşiyorsa, YA DA
  - web sitesi alan adı VE ülke eşleşiyorsa
"olası eşleşme, inceleme gerekli" olarak işaretle:
  - ad VE şehir eşleşiyor ama alan adı ya da numara yoksa
asla şunlara dayanarak birleştirme:
  - yalnızca ad benzerliği
  - bir barındırma ya da park hizmetinin ortak kullandığı alan adı

Eşleştirme kararını kayıtta saklayın. Biri sonradan bir şirketin neden 500 çalışanlı göründüğünü sorduğunda “example.com alan adı üzerinden eşleşti” bir yanıttır; “sağlayıcı öyle dedi” değildir.

Kaynak kaydı: her değerin bir kaynağı olmalı

Kaynak kaydı (provenance), zenginleştirilmiş her değerin yanında onu yeniden kontrol etmeye yetecek bilgiyi saklamak demektir. Alan düzeyinde kaynak kaydı düz bir sütundan daha ağır görünür, ama veriye sonradan güvenmenizi, onu yenilemenizi ve düzeltmenizi sağlayan tam olarak budur.

{
  "field": "merkez_sehir",
  "value": "Rotterdam",
  "source": "ticaret sicili kaydı",
  "source_ref": "sicil kaydının URL'si ya da doküman kimliği",
  "retrieved": "YYYY-MM-DD",
  "method": "extracted",          // extracted | provider | inferred | human-verified
  "supporting_text": "Kayıtlı merkez: ... Rotterdam",
  "status": "confirmed"           // confirmed | unknown | conflicting
}

Örnekteki iki alan ayrıca vurgulanmayı hak ediyor. Yöntem, bir dokümandan okunan değeri bir modelin çıkarsadığı değerden ayırır; bu ikisi asla aynı ağırlığı taşımamalıdır. Durum ise “bilinmiyor”u meşru bir sonuç hâline getirir. “Bilinmiyor” diyemeyen bir zenginleştirme süreci boşlukları tahminle doldurur ve tahminler bir tabloya ulaştığında olgulardan ayırt edilemez. Bu noktayı eksik kanıt açık bir sorudur yazısı ayrıntılı biçimde savunuyor; bir kaynak referansını saklamaya değer kılan şeyleri ise dayanıklı atıflar yazısı ele alıyor.

Zenginleştirilmiş veriyi doğru tutmak

Zenginleştirilmiş veri, yazıldığı gün eskimeye başlar. Birkaç alışkanlık onu dürüst tutar:

• Tabloya göre değil, alana göre yenileyin. Sicil numaraları nadiren değişir; unvanlar sürekli değişir. Her alan türüne ayrı bir yenileme aralığı verin.
• Tetikleyicilerle de yenileyin. Tespit edilen bir birleşme, isim ya da adres değişikliği, takvimi beklemeden ilgili alanları yeniden açmalıdır.
• Kaynaklarınızı sıralayın. İki kaynak çeliştiğinde yazılı bir öncelik sırası (önce sicil, sonra sağlayıcı, en son çıkarım) her seferinde aynı sonuca götürür. Çelişkiyi gizlemek yerine kaydedin.
• İnsan düzeltmelerini koruyun. Bir kişinin doğruladığı değer, bir sonraki otomatik geçişte üzerine yazılmamalıdır. Değerleri silip yeniden yazmak yerine sürümleri saklayın.
• Geri yazmadan önce inceleyin. Zenginleştirilmiş değerleri bir CRM’e ya da dışarıya ulaşan bir iletişim aracına aktarmak, onları o aracı kullanan herkese yayar; toplu güncellemeden önce bir örneklemi kontrol edin.

GoCux kanıt tarafını nasıl ele alır

GoCux, her değeri dayanağına bağlı tutmak üzerine kuruludur. Bilgi çıkarma, sağladığınız materyali okur ve her değeri arkasındaki pasajla birlikte döner; materyalde bir değer yoksa tahminle doldurulmaz, bilinmiyor olarak bırakılır. FindAll, eşleşme ölçütlerinden ve istediğiniz sütunlardan bir tablo kurar; her satır kendi kanıtını taşır ve kapsamın sınırları yuvarlanıp gizlenmek yerine raporlanır, çünkü sonuç sayısı listenin eksiksiz olduğunu kanıtlamaz. Değişen değerler için Pulse, seçtiğiniz kaynaklar üzerinde tekrarlanan bir soru sorar ve her değişikliği bir gözden geçirenin önüne koyar; tespit edilen bir değişiklik sizin adınıza hiçbir şeyi güncellemez. Çalışma alanından veri dışa aktarmak ise kapsamdaki dosyalar listelenmiş olarak bir insanın kararını bekler. Her biri için Bilgi çıkarma, FindAll ve Pulse sayfalarına bakabilirsiniz.

Zenginleştirme kontrol listesi

• Zenginleştirilen her alan, adı konmuş bir karar ona ihtiyaç duyduğu için var.
• Eşleştirme kuralı yazılı ve asla yalnızca ad benzerliğini kabul etmiyor.
• Her değer kaynağını, erişim tarihini, yöntemini ve dayanak metnini saklıyor.
• “Bilinmiyor” ve “çelişkili” izin verilen durumlar ve raporlanıyorlar.
• Her alan türünün bir yenileme aralığı ve onu yeniden açan en az bir tetikleyicisi var.
• Bir kişinin doğruladığı değerler otomatik üzerine yazmaya karşı korunuyor.
• Kişisel veri zenginleştirmesinin hukuki dayanağı kontrol edilmiş, kaynak şartları buna izin veriyor.
• Zenginleştirilmiş değerler başka sistemlere yazılmadan önce bir örneklem inceleniyor.