Bayi lokasyonları çoğu zaman tek bir düzenli veritabanında toplanmış halde bulunmaz. Bir üretici temiz bir dizin yayınlar, diğeri etkileşimli bir harita kullanır, üçüncüsü posta kodu araması ister, bir başkası ise bayi bilgilerini ayrı profil sayfalarının arkasına saklar.
Portföy yüzlerce web sitesine yayıldığında iş artık “birkaç adresi çekmek” olmaktan çıkar. Asıl ürün, şu iş sorularına güvenilir biçimde cevap veren bir bayi ana verisidir:
- Dağıtım nerede büyüyor, nerede daralıyor?
- Hangi bölgelerde kapsama boşluğu var?
- Hangi bayiler eklendi, taşındı ya da kaldırıldı?
- Hangi lokasyonlar belirli bir ürün grubunu veya hizmeti sunuyor?
- Yeni keşfedilen bir bayi hangi CRM sahibine yönlendirilmeli?
- Bir rakibin kanal ayak izi zaman içinde nasıl değişiyor?
Pratik mimari oldukça nettir: kaynakları keşfet, locator desenlerini sınıflandır, tek bir kanonik şemaya çıkar, kaynak kanıtını koru, tekrarları çöz, anlamlı değişiklikleri tespit et ve doğru ekibe yönlendir.
Hedef Sistem
Üretim seviyesinde bir bayi takibi iş akışı altı katmandan oluşur:
- Kaynak kaydı: Web siteleri, locator URL’leri, ülkeler, sahipler, desenler, zamanlamalar ve son çalıştırma durumu.
- Keşif: Dizin sayfalarını, site haritalarını, API’leri, arama formlarını ve detay URL’lerini bulmak için tekrarlanabilir bir yöntem.
- Çıkarma: Farklı düzenlerde aynı anlamsal alanları toplayan tarayıcı veya API işleri.
- Normalizasyon: Ham değerleri kaybetmeden tutarlı adresler, telefon numaraları, ülkeler, kategoriler ve durum etiketleri.
- Varlık ve değişim katmanı: Kanonik bayi kimlikleri, marka üyelikleri, ilk görülen ve son görülen zaman damgaları, doğrulanmış eklemeler veya kaldırmalar.
- Aktivasyon: Uyarılar, CRM yönlendirmesi, kapsama analizi, panolar ve inceleme kuyrukları.
Doğrudan web sitelerinden CRM aktarımına atlamak genellikle birbirinden kopuk, kırılgan betikler ve yinelenen kayıtlar yığını üretir. Yüzlerce siteyi yönetilebilir kılan şey, kaynak kaydı ve kanonik modeldir.
1. Adım: Kanonik Bayi Şemasını Tanımlayın
İlk web sitesinden değil, çıktılardan başlayın. İşe yarayan minimum bir şema şöyledir:
| Grup | Alanlar |
|---|---|
| Kaynak kanıtı | source_domain, source_locator_url, source_dealer_url, source_dealer_id |
| Kimlik | dealer_name_raw, dealer_name_normalized, brand, manufacturer |
| Adres | street_address, address_locality, address_region, postal_code, address_country |
| İletişim | phone_raw, phone_normalized, website |
| Konum | latitude, longitude |
| Ticari özellikler | services, products, categories, authorized_status_raw |
| Gözlem | observed_at, first_seen, last_seen, record_status |
| Değişim kontrolü | source_hash, change_hash, parser_version |
Schema.org’un PostalAddress sınıfı, sokak adresi, yerleşim, bölge, posta kodu ve ülke için faydalı bir adlandırma temeli sunar. Normalleştirilmiş veride ISO iki harfli ülke kodlarını tercih edin; buna karşılık ülkeyi, kaynağın yayınladığı biçimiyle de saklayın.
Ham ve normalleştirilmiş alanları yan yana tutun. Bir site St. John's, NL yazıyorsa ve normalizasyon katmanı standart bir eyalet/bölge ve telefon kodu üretiyorsa, her iki sürüm de inceleme için erişilebilir kalmalıdır.
2. Adım: Bir Kaynak Kaydı Oluşturun
Kaynak kaydı, operasyonun kontrol düzlemidir. Her web sitesi için bir satır açın ve şunları tutun:
- Alan adı ve marka
- Ülke veya pazar
- Tahmini locator URL’si
- Locator desen ailesi
- Tercih edilen tarama modu
- Ayrıştırıcı veya şablon sürümü
- Çalışma sıklığı
- İş sahibi
- Son denenen, başarılı, boş ve başarısız çalışma
- Arama girdileri veya etkileşim gereksinimleriyle ilgili notlar
Her locator tam olarak anlaşılana kadar beklemeyin. Önce kayıt yapın, pilot ilerledikçe sınıflandırmayı iyileştirin.
Locator Kaynakları Nasıl Keşfedilir
Şunları kontrol edin:
- “Find a dealer,” “Where to buy,” veya “Store locator” gibi ana menü ve alt bilgi bağlantıları
/sitemap.xmlve sitemap dizinleri- Site içi arama
site:brand.example dealer locatorgibi arama motoru sorguları- Sayfa kaynağı ve gömülü yapılandırılmış veri
- Locator aramasıyla tetiklenen ağ istekleri
- Yedek kaynak olarak PDF veya dağıtıcı belgeleri
Sitemaps protokolü, her sitemap girişi için bir <loc> URL’si gerektirir ve sitemap dizinlerini destekler. Site haritaları keşfi hızlandırabilir; ancak her dinamik locator sonucunun dahil edildiğini garanti etmez ve bir <lastmod> değeri, bayi bilgisinin güncel olduğunun kanıtı olarak kabul edilmemelidir.
3. Adım: Ölçeklemeden Önce Her Locator’ı Sınıflandırın
Bayi web sitelerinin çoğu küçük bir desen ailesi kümesine girer:
- Statik HTML liste veya tablo — en kolay durum; kayıtlar sayfa kaynağında bulunur.
- Sayfalandırılmış dizin veya sonsuz kaydırma — kayıtlar tekrar eder ama gezinme gerekir.
- Detay bağlantılı harita kartları — özet kartların alt sayfa ile zenginleştirilmesi gerekir.
- Arama formu — kullanıcı ülke, eyalet, şehir veya posta kodu girmelidir.
- Gömülü JSON veya ağ yanıtı — sayfa, yapılandırılmış verinin etrafına kurulmuş görsel bir kabuktur.
- İnce liste + bayi detay sayfaları — liste kimlik bilgisini taşır, adresler ve hizmetler alt sayfalarda yer alır.
- PDF veya belge dizini — çıkarım ve değişim incelemesi belgeye özel bir yol gerektirir.
Tüm yüzlerce siteyi tek bir evrensel scraper ile iyi yönetemezsiniz. Ölçeklenebilir yaklaşım, her desen ailesi için yeniden kullanılabilir bir iş akışı kurup bunu kaynak bazında yapılandırmaktır.
4. Adım: Thunderbit ile Tarayıcı İş Akışını Pilotlayın
Thunderbit, toplu otomasyona yatırım yapmadan önce örnek sitelerde şemayı doğrulamak için kullanışlıdır.
Pilot Süreci
- Chrome’da temsil edici bir bayi dizini açın.
- Thunderbit’i başlatın ve AI Suggest Fields özelliğini kullanın.
- Önerilen alanları kanonik şemaya göre yeniden adlandırın.
- Normalizasyon veya sınıflandırma için Field AI Prompts ekleyin — örneğin görünür ülke adını ISO koda eşleyin veya hizmetleri onaylı bir kategori setine ayırın.
- Liste sayfaları için sayfalama veya sonsuz kaydırma işlemeyi etkinleştirin.
- Tekil bayi sayfalarında telefon, web sitesi, hizmetler veya kaynak ID’leri varsa alt sayfa taramasını kullanın.
- Küçük bir örneği Sheets veya Excel’e aktarın ve her kaynak URL’sini doğrulayın.
Tarayıcı modu, bir locator etkileşim, giriş yapılmış oturum veya basit bir isteğin yeniden üretemediği bir render gerektirdiğinde özellikle faydalıdır. Yalnızca kuruluşun erişmeye yetkili olduğu kaynakları ve hesapları kullanın.
En Kolay Siteleri Değil, Temsil Edici Siteleri Seçin
İlk pilot; başlıca desenleri, bölgeleri ve sayfa teknolojilerini kapsayan 20 site içermelidir. Pilot kaynakların hepsi basit bir statik tabloysa, ilk harita tabanlı locator geldiğinde iş akışı kusursuz görünür ama gerçekte kırılgan olur.
Her desen ailesi için en az şunları doğrulayın:
- Bir temiz örnek
- Bir büyük örnek
- Bir dinamik veya düzensiz örnek
- Bayi detay sayfaları olan bir site
- Seyrek veya isteğe bağlı alanları olan bir site
5. Adım: Kararlı Kaynakları Batch Extract API ile Ölçeklendirin
Tekrarlanabilir herkese açık sayfalar için, kararlı işleri manuel tarayıcı kullanımından Thunderbit Web Scraper API üzerine taşıyın.
Batch Extract endpoint’i, tek bir JSON Schema ile bir istekte en fazla 50 URL kabul eder. Bir job ID döndürür, URL’leri paralel işler, URL bazında hata desteği sunar, webhook bildirimleri gönderebilir ve none, basic ve full gibi renderMode seçenekleri sunar.
Batch Tasarımı
- Aynı anlamsal çıktı şemasını paylaşan URL’leri gruplayın.
- Batch boyutunu 50 URL sınırının altında tutun.
- Veriyi güvenilir şekilde ortaya çıkaran en hafif render modunu seçin.
- Job ID ve parser sürümünü çalıştırma kaydıyla birlikte saklayın.
- Yalnızca batch için değil, her URL için başarı, boş ve hata durumunu kaydedin.
- Sadece başarısız URL’leri yeniden deneyin.
- Normalizasyondan önce ham çıkarılmış değerleri ve kaynak bağlantılarını koruyun.
Alanların iş anlamı tutarlı olduğu sürece tek bir şema, farklı tasarlanmış web sitelerini kapsayabilir. Statik bir dizin ile harita kartı locator’ının aynı bayi ana verisini besleyebilmesini sağlayan şey budur.
6. Adım: Kanıtı Yok Etmeden Normalleştirin
Normalizasyon, kayıtları karşılaştırılabilir hale getirir; ancak denetlenemez hale getirmemelidir.
Önerilen dönüşümler şunlardır:
- Fazla boşlukları ve noktalama tutarsızlıklarını temizleme
dealer_name_rawalanını korurken büyük/küçük harf standardizasyonu- Telefon numaralarını açık ülke bağlamıyla ayrıştırma
- Ülke ve bölge adlarını onaylı kodlara eşleme
- Adres bileşenlerini tutarlı şekilde ayırma veya birleştirme
- URL’leri normalleştirme ve gerektiğinde takip parametrelerini kaldırma
- Serbest metin hizmetlerini kontrollü kategorilere eşlerken kaynak ifadesini saklama
Kaynağın yetkilendirme etiketini üzerine yazmayın. Bir üretici “Authorized Dealer”, diğeri “Certified Reseller” diyorsa, tam ifadeyi saklayın ve isterseniz ayrı bir alanda normalleştirilmiş kategori ekleyin.
7. Adım: Bayileri Marka ve Kaynaklar Arasında Eşleştirin
Sadece bayi adı eşleşmesi yeterli değildir. “Smith Auto,” “Smith Automotive” ve “Smith Auto LLC” aynı işletme olabilir — ya da komşu şehirlerde üç ayrı işletme.
Şu tür birleşik bir aday anahtarı kullanın:
normalized name + postal code + phone
veya koordinatlar varsa:
normalized name + geospatial distance + address number
Ardından kanıtı puanlayın:
- Tam veya neredeyse tam normalleştirilmiş ad
- Tam telefon numarası
- Aynı posta kodu
- Benzer sokak adresi
- Küçük bir yarıçap içinde koordinatlar
- Eşleşen web sitesi alan adı
Kayıtları hemen birleştirmek yerine kaynaktan kanoniğe bir eşleme tablosu oluşturun. Birden fazla üretici aynı fiziksel bayiyi gösterebilir; buna rağmen ayrı marka üyelikleri, hizmetleri ve durum etiketlerini koruyabilirsiniz.
8. Adım: Anlamlı Değişiklikleri Tespit Edin
Her çalışma bir gözlem olmalı, yıkıcı bir üzerine yazma işlemi değil.
Şunları saklayın:
- Mevcut çalışma için
observed_at - Kaynak kaydı ilk kez göründüğünde
first_seen - En son başarılı gözlem için
last_seen - Ham kayıt için bir source hash
- Normalleştirilmiş iş alanları için bir change hash
Faydalı değişiklik türleri şunlardır:
- Bayi eklendi
- Bayi eksik
- Ad, adres, telefon veya web sitesi değişti
- Yetkilendirme durumu değişti
- Hizmet veya ürün kategorisi değişti
- Konum taşındı
- Kaynak sayfası başarısız oldu veya düzen kaydı oluştu
Eksik bir kayıt önce missing_pending_review olmalıdır. Kaldırmayı yalnızca tekrarlanan yokluk veya manuel inceleme sonrası doğrulayın. Başarısız bir tarama, boş yanıt veya bozuk seçici, bir bayinin kapandığına dair kanıt değildir.
9. Adım: Google Places’i İsteğe Bağlı Doğrulama Olarak Ekleyin
Google Places Place Details, istenen field mask ve SKU’ya bağlı olarak bir bayi kaydını sabit place ID, görünen ad, biçimlendirilmiş adres, koordinatlar, telefon, web sitesi, işletme durumu ve taşınmış yer bilgileriyle zenginleştirebilir veya doğrulayabilir.
Bunu ikincil bir sinyal olarak kullanın; bir lokasyonun üreticinin bayi programına ait olup olmadığı konusunda nihai otorite olarak değil. O üyelik için üretici kaynağı yetkilidir. Doğrulama sağlayıcısını ve zaman damgasını saklayın; üreticinin durumunu sessizce üzerine yazmayın.
10. Adım: Çıkarma Kalitesini Desen ve Kaynak Bazında Ölçün
Kaliteyi çalıştırma, desen ve alan adı düzeyinde izleyin.
Çalıştırma Bazlı Metrikler
- Kayıtlı kaynak URL’leri
- Denenen URL’ler
- Başarılı, boş ve başarısız URL’ler
- Çıkarılan kayıtlar
- Eklenen, değişen, eksik ve değişmeyen kayıtlar
- Temel alan tamlığı
- Yinelenen aday sayısı
- İnceleme bekleyen şüpheli kaldırmalar
- Şema kayması olayları
Örnek Doğrulama
Her desen ailesi ve büyük çalışma için:
- 20–50 örnek kaydı kaynak sayfalarıyla karşılaştırın.
- Beklenen URL sayısını denenen ve başarılı sayılarla doğrulayın.
- Alan adı bazında eksik temel alanları inceleyin.
- Yinelenen kümeleri ve düşük güvenli varlık eşleşmelerini kontrol edin.
- Koordinat aykırı değerleri ve ülke/posta kodu uyuşmazlıklarını inceleyin.
- Görünürde kaldırılmış kayıtların bir örneğine geri dönün.
- Kullanılan extractor veya şablon sürümünü kaydedin.
Amaç tek bir küresel “doğruluk” yüzdesi değildir. Hangi desenlerin ve kaynakların güvenilir olduğunu, hangi alanların zayıf kaldığını ve inceleme çabasının nereye yönelmesi gerektiğini bilmektir.
11. Adım: Değişiklikleri İş Akışlarına Yönlendirin
Farklı değişiklikler farklı hedefleri hak eder:
- Yeni bayi: CRM oluşturma, sahiplik ve bölge ataması için satış operasyonlarına yönlendirin.
- Kaldırılmış veya kapanmış lokasyon: Hesap durumunu değiştirmeden önce bir inceleme kuyruğuna gönderin.
- Adres veya telefon değişikliği: Zenginleştirmeyi güncelleyin ve açık fırsatları veya hizmet kapsamasını doğrulayın.
- Yetkilendirme değişikliği: Kanal yönetimi ve müşteriyle temas eden ekipleri bilgilendirin.
- Kapsama boşluğu: Bölge planlaması ve iş ortağı kazanımına besleyin.
- Rakip genişlemesi: Dağıtım istihbaratı ve bölgesel stratejiyi güncelleyin.
- Tekrarlanan kaynak hatası: Satış ekibine değil, veri operasyonları kuyruğuna gönderin.
Her bildirim; kanonik bayi, marka üyeliği, değişiklik türü, önce/sonra değerleri, kaynak URL’si, gözlem zamanı ve güven veya inceleme durumunu içermelidir.
30/60/90 Günlük Uygulama Planı
1–30. Günler: Tasarla ve Kanıtla
- Kanonik şemayı ve kontrollü kategorileri kesinleştirin.
- Kaynak kaydını oluşturun.
- 20 temsilci web sitesini sınıflandırın.
- 3–5 locator desen ailesini doğrulayın.
- Örnek doğrulama kuralları ve çalışma metrikleri oluşturun.
- Kaynak kanıtıyla birlikte ilk bayi ana verisini teslim edin.
31–60. Günler: Genişlet ve Otomatize Et
- Sınıflandırmayı tüm portföye yaygınlaştırın.
- Kararlı herkese açık URL gruplarını batch çıkarıma taşıyın.
- Zamanlamalar, iş takibi, yeniden deneme mantığı ve hata panoları ekleyin.
- Kaynak-kanonik varlık eşleme yapısını devreye alın.
- İncelenmiş eklemeleri ve güncellemeleri CRM iş akışlarına bağlayın.
61–90. Günler: Değişim Zekâsını Operasyonelleştir
- Değişime özel uyarılar ve inceleme kuyrukları ekleyin.
- İlk görülen, son görülen ve kaldırma doğrulamasını devreye alın.
- Adres güvenini artırıyorsa isteğe bağlı Places doğrulaması ekleyin.
- Çalıştırma düzeyi hizmet hedefleri tanımlayın.
- Desen ve şablon performansını aylık inceleyin.
- Her kaynak ailesi ve iş aksiyonu için bir sorumlu atayın.
Yaygın Başarısızlık Modları
Her web sitesi için ayrı bir scraper inşa etmek. Bu, yüzlerce bakım yolu oluşturur. Desen ailelerini sınıflandırın ve yeniden kullanılabilir mantığı kaynak yapılandırmasından ayırın.
Bayi adına göre deduplikasyon yapmak. İsimler tutarsızdır ve sıkça yeniden kullanılır. Adres, posta kodu, telefon, koordinatlar ve web sitesi kanıtıyla eşleştirin.
Ham değerlerin üzerine yazmak. Kaynak gösterimi kaybolduğunda normalizasyon hatalarını denetlemek imkânsız hale gelir.
Boş çıktıyı sıfır bayi olarak yorumlamak. Boş çıktı; başarısız etkileşim, render değişikliği veya engellenmiş istek anlamına gelebilir. Tarama sağlığını iş durumu ile karıştırmayın.
Tek bir kaçırmadan sonra kaldırma ilan etmek. Tekrarlanan yokluk veya manuel doğrulama şartı koyun.
Harita sağlayıcısını bayi otoritesi olarak kullanmak. Harita verisi bir konumu doğrulayabilir; ancak üreticinin yetkilendirme ilişkisini teyit edemez.
Desen kalitesini ölçmeden ölçeklemek. Küçük bir çıkarım hatası, yüzlerce siteye yayıldığında büyük bir operasyon sorununa dönüşür.
SSS
Tek bir şema yüzlerce farklı bayi web sitesinde çalışabilir mi?
Evet. Sayfa düzenleri farklıdır, ancak bayi adı, adres, telefon, web sitesi, marka, hizmetler, kaynak URL’si ve durum gibi anlamsal alanlar büyük ölçüde ortaktır. Tek bir kanonik şemayı doldurmak için farklı çıkarım desenleri kullanın.
Posta kodu araması gerektiren locator sayfaları nasıl otomatikleştirilmeli?
Arama formunu kendi desen ailesi olarak ele alın. Bir kapsama ızgarası tanımlayın, sonuç ID’lerini veya URL’lerini yakalayın, üst üste binen arama yarıçaplarını deduplikasyonla temizleyin ve hata ayıklama için her sonucu üreten girdiyi saklayın.
Bayi lokasyonları ne sıklıkla yenilenmeli?
Sıklığı iş kullanımına ve kaynak davranışına göre belirleyin. Yüksek değerli rekabet veya hizmet kapsama kaynakları haftalık çalışabilir; daha yavaş üretici dizinleri aylık çalışabilir. Çalışma hataları, bayi değişim sıklığından bağımsız olarak operasyonel inceleme tetiklemelidir.
Sistem kaldırılmış bir bayi ile başarısız bir taramayı nasıl ayırır?
Kaynak sağlığını ve kayıt varlığını ayrı izleyin. Başarısız veya boş bir tarama, bayinin son görülme durumunu güncellemez. Yokluk kanıtı yalnızca başarılı çalışmalardan gelir ve kaldırma için tekrar veya inceleme gerekir.
Google Places, web sitesindeki adres ve iş durumunun yerine geçmeli mi?
Hayır. Places’i zenginleştirme veya doğrulama için kullanın, zaman damgasını ve sağlayıcısını saklayın ve üretici locator’ını bayi programı üyeliği için yetkili kaynak olarak bırakın.
Otomatik bayi takibi, bir veri ürünü gibi ele alındığında başarılı olur: yönetilen bir kaynak kaydı, yeniden kullanılabilir desen aileleri, korunmuş kanıtlar, temkinli varlık eşleştirmesi ve iş sahipliğindeki değişim iş akışları. Bu mimari, her yeniden tasarımı acil bir yeniden inşaya dönüştürmeden 20 pilot siteden yüzlercesine büyüyebilir.
Daha Fazla Bilgi
