Zenginleştirme API'leriyle doğru kalan bir şirket veritabanı kurmak

Bir zenginleştirme API'sini ürününüze bağlamak bir öğleden sonra sürer. Ürettiği şirket kayıtlarını bir yıl boyunca doğru tutmak ise bambaşka bir projedir. Değerler eskir, iki kaynak birbirini tutmaz, bir bağlı ortaklık ana şirketin içine karışır ve birinin elle düzelttiği bir alan bir sonraki senkronizasyonda sessizce ezilir. Bu rehber, çoğu zaman bir ajanın ya da yapay zekâ özelliğinin okuduğu bu katmanı kuran geliştiriciler için yazıldı. API seçimini, verinin denetlenebilir biçimde saklanmasını, varlık eşleştirme ile çakışma çözümünü, iki kez ödemeden yenilemeyi ve insan incelemesinin yerini ele alıyor. Önce temelleri görmek isterseniz veri zenginleştirme nedir yazısıyla başlayın.

Zenginleştirilmiş şirket verisi neden gerçeklikten uzaklaşır

Zenginleştirme sorunlarının çoğu kötü bir sağlayıcıdan kaynaklanmaz. Doğru kalmak için gereken bilgiyi çöpe atan bir saklama tasarımından kaynaklanır. Aynı hata kalıpları tekrar tekrar karşımıza çıkar:

• Son yazan kazanır. Her senkronizasyon önceki değerin üzerine yazar; neyin, ne zaman ve neden değiştiğini bilemezsiniz.
• Kaynak bilgisi değer başına değil, kayıt başına. Kayıtta bir sağlayıcıyla zenginleştirildiği yazar; oysa ülke, çalışan sayısı ve sektör farklı yaşlarda, farklı yerlerden gelmiştir.
• Hatalı eşleştirme. Şirket adıyla yapılan bir sorgu, adı benzeyen başka bir şirketi döndürür ve ondan sonraki her alan kendinden emin biçimde yanlıştır.
• Boş değer üç anlama gelir. “Sağlayıcıda değer yok”, “hiç sormadık” ve “şirketin böyle bir şeyi yok” tek bir boş hücrede birleşir.
• Açıklanamayan skorlar. Bir niyet ya da uyum skoru hiçbir girdi göstermeden gelir; kimse onu açıklayamaz, itiraz da edemez.
• Hiç eskimeyen anlık görüntüler. Bir kez satın alınan veri, doğruluğunu yitirdikten çok sonra bile yaşını gösteren hiçbir işaret olmadan veritabanında durur.

Hangi sağlayıcıyı seçerseniz seçin, bunların her biri kendi şemanızda düzeltilebilir.

Entegrasyondan önce bir zenginleştirme API'sine sorulacaklar

Sağlayıcı karşılaştırmaları genellikle kapsamaya odaklanır. Doğru kalması gereken bir veritabanı için yanıtın biçimi de en az kapsama kadar önemlidir.

Ardından bir altın küme üzerinde deneme yapın: ekibinizin iyi tanıdığı; küçük şirketleri, bağlı ortaklıkları ve önem verdiğiniz bölgelerdeki şirketleri de içeren bir örneklem. Dönen her alanı elle kontrol edin; doğru, yanlış, eskimiş ve eksik olanları sayın. Dürüstçe “bilinmiyor” diyen bir sağlayıcı, her alanı dolduran bir sağlayıcıdan çoğu zaman daha işe yarar. Kaynak türlerine daha geniş bir bakış için şirket araştırması için veri kaynağı seçimi yazısına bakın.

Gözlemleri saklayın, yanıtı onlardan türetin

En işe yarayan tasarım kararı, bir alanın “asıl” değerini saklamayı bırakmaktır. Aldığınız her gözlemi yalnızca ekleme yapılan bir tabloda tutun ve güncel değeri bunlardan hesaplayın. Gözlem ucuzdur; kaybolan geçmiş pahalıdır.

companies
  id, primary_domain, legal_name, country, status, merged_into

company_identifiers
  company_id, kind (domain | registry | provider_id), value, verified_at

observations                       -- yalnızca ekleme
  id, company_id, field, value,
  source_type (provider | registry | website | person | agent),
  source_ref, observed_at, retrieved_at,
  evidence_text, confidence, ingest_job_id

resolved_values                    -- türetilmiş, yeniden üretilebilir
  company_id, field, value, chosen_observation_id,
  state (confirmed | inferred | unknown | in_review), resolved_at

Bu tasarımdan bazı yararlı özellikler kendiliğinden çıkar. Kurallarınız değiştiğinde çözümlenmiş değerleri baştan üretebilirsiniz. “Bu nereden geldi?” sorusunu tek bir yabancı anahtarı izleyerek yanıtlarsınız. Bir insanın yaptığı düzeltme de source_type = person olan bir gözlemden ibarettir ve kurallarınız onu her şeyin üstüne koyabilir.

observed_at ile retrieved_at alanlarını ayrı tutun. İlki, kaynağa göre bilginin doğru olduğu zamandır; ikincisi sizin onu çektiğiniz zaman. Bir sağlayıcı size bugün, en son çok uzun zaman önce gördüğü bir çalışan sayısını verebilir.

Varlık eşleştirme: önce anahtarı doğru kurun

Her alan şirket kimliğine bağlıdır; bu yüzden buradaki hatalar katlanarak büyür. Sahada işe yarayan kurallar:

• Eşleştirmeden önce alan adlarını normalleştirin: küçük harfe çevirin, www. önekini ve yolları atın, yönlendirmeleri izleyin; yönlendirme hedefini orijinalin yerine koymak yerine ayrı bir tanımlayıcı olarak kaydedin.
• Sicil numaralarını, bulundukları yerde en güçlü anahtar sayın ve yanlarında ülkeyi de saklayın; çünkü bir numara yalnızca kendi sicili içinde benzersizdir.
• İki kaydı yalnızca ad benzerliğine bakarak asla birleştirmeyin. Ortak bir alan adı ya da sicil numarası arayın; yoksa çifti incelemeye gönderin.
• Ana şirket ile bağlı ortaklıkları birleştirme olarak değil, ilişki olarak modelleyin. Kendi alan adı olan bölgesel bir şirket, çoğu zaman ekibinizin gerçekten satış yaptığı hesaptır.
• Birleştirmeleri geri alınabilir yapın. Birleştirilen kaydı bir merged_into işaretçisiyle saklayın; yanlış bir birleştirme veri kaybetmeden geri alınabilsin.

Açıklanabilir çakışma kuralları

Aynı alanı birden çok kaynak beslemeye başladığında, kaynaklar birbiriyle çelişecektir. Bunun nasıl çözüleceğine her alan için yazılı olarak karar verin. Okunabilecek kadar kısa bir kural seti, kimsenin açıklayamadığı akıllıca bir puanlama fonksiyonundan iyidir.

alan: hq_country
  1. kişinin girdiği değer; daha yeni sicil kanıtı onunla çelişirse -> inceleme
  2. resmî sicil
  3. şirket web sitesi (künye, iletişim sayfası)
  4. zenginleştirme sağlayıcısı
  2 ile 3 arasında eşitlik ya da çelişki -> inceleme

alan: headcount_range
  mevcut değere bir kademe yakınsa en yeni gözlem kazanır
  bir kademeden büyük sıçrama -> inceleme
  alanın tazelik penceresinden eski değerler -> state = unknown

İki alışkanlık çakışma yönetimini makul tutar. Birincisi, bir insanın girdiği değerin üzerine asla otomatik olarak yazılmaz; onunla çelişen bir gözlem bunun yerine bir inceleme kaydı açar. İkincisi, kaybeden gözlem de saklanır. Bir kuralın yanlış olduğu ortaya çıktığında alternatifin hâlâ elinizde olmasını istersiniz.

Aynı yanıt için iki kez ödemeden yenilemek

Zenginleştirme çağrıları genellikle para ya da kota harcar; bu yüzden yenileme, veri sorunu olduğu kadar bir zamanlama sorunudur.

• Alan sınıfına göre tazelik pencereleri. Kimlik alanları iki kontrol arasında uzun süre bekleyebilir; çalışan sayısı ve teknoloji daha kısa bir pencere ister; olaylar geldikçe eklenmeli, asla toplu olarak yenilenmemelidir.
• Kullanımda olanı yenileyin. Bir hesabı tüm tablo için takvime göre değil, aktif bir iş akışına girdiğinde yeniden zenginleştirin.
• Ham yanıtları alınma tarihleriyle önbelleğe alın; sağlayıcı koşullarının izin verdiği ölçüde. Böylece yeniden işlemek, yeniden satın almak anlamına gelmez.
• Toplu işlerde idempotency anahtarları ve iş kimlikleri kullanın; yeniden denenen bir iş mükerrer gözlem üretmesin.
• Hız sınırlarında geri çekilin ve “sağlayıcıya ulaşılamıyor” durumunu ayrı bir durum olarak ele alın. Bir çağrı başarısız oldu diye asla boş değer yazmayın.
• Sağlayıcı sunuyorsa değişiklik akışlarını tercih edin; tam bir yenilemeyi küçük bir farka dönüştürürler.

Her işe bir bütçe verin ve sınıra ulaşıldığında açık bir mesajla durun; geriye dönük doldurmanın nereye vardığını faturadan öğrenmeyin.

İncelemeyi sonucu değiştirdiği yere koyun

Her değeri incelemek ölçeklenmez; hiçbirini incelememek ise veritabanlarının çürüme biçimidir. Yalnızca hatanın pahalıya patladığı durumları yönlendirin: zayıf varlık eşleşmeleri, önerilen birleştirmeler, yetkili kaynaklar arasındaki çakışmalar, bir insanın girdiği değerlerdeki değişiklikler ve büyüklük alanlarındaki sert sıçramalar. İnceleme kaydı mevcut değeri, önerilen değeri, her birinin kanıtını ve onu işaretleyen kuralı göstermeli; böylece karar saniyeler sürer. Reddetmeler dahil kimin neye karar verdiğini kaydedin; aynı çakışma gelecek hafta yeniden önünüze gelmesin. Bu incelemenin satış tarafından nasıl göründüğünü CRM hesaplarını alan alan zenginleştirme rehberi anlatıyor.

Uzun kuyruk: kanıtlı ajan araştırması

Her sağlayıcının boşlukları vardır: küçük özel şirketler, yeni kurulanlar, iyi kapsamadığı bölgelerdeki firmalar. Birçok ekip bu uzun kuyruğu, şirketin kendi sayfalarını ve kamuya açık kayıtları okuyan bir ajana devreder. Ajan da gözlemleri diğer her şeyle aynı biçimde, her değer için bir kaynak ve destekleyen bir pasajla döndürüyor ve hiçbir şey bulamadığında “bilinmiyor” diyorsa bu yöntem işe yarar. Ajan, doğrulanmış veriden ayırt edilemeyen akıcı tahminler ürettiğinde ise başarısız olur.

GoCux'ın işe yaradığı yer burası; sınırlarının önemli olduğu yer de. GoCux açık webde arama yapmaz, webi taramaz ve bir zenginleştirme sağlayıcısı değildir. Web sayfaları ona yalnızca yetkilendirilmiş bir tarama ya da dışa aktarma adımıyla ulaşır ve içe aktarıldıktan sonra sayfa referansını ve alınma tarihini korur. Sağladığınız malzemeden Bilgi çıkarma, her değeri arkasındaki pasajla birlikte döndürür ve eksik bir değeri bilinmiyor olarak bırakır. FindAll, eşleşme ölçütlerini ve sütunları, her satırın kendi kanıtını taşıdığı bir tabloya dönüştürür ve kapsamanın nerede bittiğini raporlar. Bu verinin çalışma alanı dışına aktarılması, kapsamdaki dosyalar listelenerek bir insan kararı için durur. Çıktı bir gözlem tablosuna doğrudan oturur: değer, kaynak, kanıt, durum. Eksik bir yanıtın neden görünür kalması gerektiği için eksik kanıt açık bir sorudur yazısına bakın.

Hattı ölçeklemeden önce kontrol listesi

• Sağlayıcı, kendi şirketlerinizden oluşan bir altın kümede denendi ve her alan elle kontrol edildi.
• Gözlemler yalnızca eklenir; kaynak, gözlem tarihi, alınma tarihi ve kanıt taşır.
• Bilinmiyor, uygulanamaz ve istenmedi ayrı durumlardır; başarısız çağrılar asla boş değer yazmaz.
• Varlıklar alan adı ya da sicil numarasıyla eşleştirilir, birleştirmeler geri alınabilir, bağlı ortaklıklar ilişki olarak tutulur.
• Her alanın yazılı bir çakışma kuralı var; insanların girdiği değerlerin üzerine asla otomatik yazılmaz.
• Yenileme tazelik pencerelerine ve aktif kullanıma göre yapılır; her işin bir bütçesi vardır.
• İnceleme zayıf eşleşmeleri, birleştirmeleri, çakışmaları ve üzerine yazmaları kapsar; her karar kaydedilir.
• Sağlayıcının koşullarının neyi saklamanıza izin verdiğini ve sözleşme bittiğinde ne olacağını biliyorsunuz.