Lokasi dealer jarang sekali tersimpan rapi dalam satu database yang gampang diakses. Satu produsen mempublikasikan direktori yang bersih, yang lain pakai peta interaktif, ada yang mewajibkan pencarian berdasarkan kode pos, dan ada juga yang menyembunyikan detail dealer di halaman profil masing-masing.
Begitu portofolio sudah mencakup ratusan situs, pekerjaannya bukan lagi sekadar “mengambil beberapa alamat.” Produk utamanya adalah master dealer yang andal untuk menjawab pertanyaan bisnis:
- Di mana distribusi sedang berkembang atau menyusut?
- Wilayah mana yang masih kosong cakupannya?
- Dealer mana yang baru ditambahkan, pindah, atau dihapus?
- Lokasi mana yang menyediakan lini produk atau layanan tertentu?
- Pemilik CRM mana yang harus menerima dealer baru yang ditemukan?
- Bagaimana jejak jaringan kompetitor berubah dari waktu ke waktu?
Arsitektur yang praktis sebenarnya cukup jelas: temukan sumbernya, klasifikasikan pola locator, ekstrak ke satu skema kanonik, simpan bukti sumber, selesaikan duplikasi, deteksi perubahan yang berarti, lalu kirim ke tim yang tepat.
Sistem Target
Workflow pelacakan dealer untuk produksi punya enam lapisan:
- Registry sumber: Situs web, URL locator, negara, pemilik, pola, jadwal, dan status run terakhir.
- Discovery: Cara yang bisa diulang untuk menemukan halaman direktori, sitemap, API, form pencarian, dan URL detail.
- Ekstraksi: Job browser atau API yang mengambil field semantik yang sama dari berbagai layout.
- Normalisasi: Alamat, nomor telepon, negara, kategori, dan label status yang konsisten tanpa menghilangkan nilai mentahnya.
- Lapisan entitas dan perubahan: Identitas dealer kanonik, keanggotaan brand, timestamp first-seen dan last-seen, serta penambahan atau penghapusan yang terkonfirmasi.
- Aktivasi: Notifikasi, routing CRM, analisis cakupan, dashboard, dan antrean peninjauan.
Langsung lompat dari website ke impor CRM biasanya cuma berakhir jadi tumpukan skrip sekali pakai yang rapuh dan data duplikat. Registry dan model kanoniklah yang bikin ratusan situs tetap terkelola.
Langkah 1: Tentukan Skema Dealer Kanonik
Mulailah dari output, bukan dari website pertama. Skema minimum yang berguna adalah:
| Grup | Field |
|---|---|
| Bukti sumber | source_domain, source_locator_url, source_dealer_url, source_dealer_id |
| Identitas | dealer_name_raw, dealer_name_normalized, brand, manufacturer |
| Alamat | street_address, address_locality, address_region, postal_code, address_country |
| Kontak | phone_raw, phone_normalized, website |
| Lokasi | latitude, longitude |
| Atribut komersial | services, products, categories, authorized_status_raw |
| Observasi | observed_at, first_seen, last_seen, record_status |
| Kontrol perubahan | source_hash, change_hash, parser_version |
PostalAddress dari Schema.org menyediakan acuan penamaan yang berguna untuk street address, locality, region, postal code, dan country. Di data yang sudah dinormalisasi, sebaiknya pakai kode negara dua huruf ISO, tetapi nama negara persis seperti yang dipublikasikan sumber tetap perlu disimpan.
Simpan field mentah dan field yang sudah dinormalisasi berdampingan. Kalau sebuah situs menulis St. John's, NL dan lapisan normalisasi menghasilkan provinsi dan kode telepon standar, dua versi itu tetap harus tersedia untuk ditinjau.
Langkah 2: Bangun Registry Sumber
Registry sumber adalah control plane untuk operasinya. Beri tiap situs satu baris dengan:
- Domain dan brand
- Negara atau pasar
- URL locator yang diduga
- Keluarga pola locator
- Mode crawl yang dipilih
- Versi parser atau template
- Frekuensi run
- Pemilik bisnis
- Status run terakhir yang dicoba, berhasil, kosong, dan gagal
- Catatan tentang input pencarian atau kebutuhan interaksi
Jangan tunggu sampai semua locator benar-benar dipahami. Buat registry dulu, lalu biarkan klasifikasinya makin rapi seiring pilot berjalan.
Cara Menemukan Sumber Locator
Periksa:
- Navigasi utama dan tautan footer seperti “Find a dealer,” “Where to buy,” atau “Store locator”
/sitemap.xmldan sitemap index- Pencarian internal situs
- Query mesin pencari seperti
site:brand.example dealer locator - Source page dan structured data yang tertanam
- Request jaringan yang dipicu oleh pencarian locator
- Dokumen PDF atau distributor sebagai sumber cadangan
Protokol Sitemaps mewajibkan URL <loc> untuk setiap entri sitemap dan mendukung sitemap index. Sitemap memang bisa mempercepat discovery, tapi tidak menjamin semua hasil locator dinamis ikut tercantum, dan nilai <lastmod> tidak boleh dianggap sebagai bukti bahwa informasi dealer benar-benar paling baru.
Langkah 3: Klasifikasikan Setiap Locator Sebelum Diskalakan
Sebagian besar situs dealer masuk ke beberapa keluarga pola berikut:
- Daftar atau tabel HTML statis — kasus paling mudah; record sudah ada di source page.
- Direktori berhalaman atau infinite scroll — record berulang tetapi perlu navigasi.
- Kartu peta dengan tautan detail — kartu ringkasan perlu diperkaya lewat subpage.
- Form pencarian — pengguna harus memasukkan negara, provinsi, kota, atau kode pos.
- JSON tertanam atau response jaringan — halaman hanyalah shell visual untuk data terstruktur.
- Daftar tipis plus halaman detail dealer — daftar memuat identitas, sementara alamat dan layanan ada di subpage.
- Direktori PDF atau dokumen — ekstraksi dan review perubahan butuh jalur khusus dokumen.
Satu scraper universal tidak akan sanggup menangani ratusan situs dengan baik. Pendekatan yang scalable adalah membuat satu workflow reusable untuk tiap keluarga pola, lalu menerapkan konfigurasi per sumber.
Langkah 4: Uji Coba Workflow Browser dengan Thunderbit
Thunderbit berguna untuk membuktikan skema di situs perwakilan sebelum berinvestasi ke otomasi massal.
Prosedur Pilot
- Buka direktori dealer perwakilan di Chrome.
- Jalankan Thunderbit dan pakai AI Suggest Fields.
- Ubah nama field yang disarankan agar sesuai skema kanonik.
- Tambahkan Field AI Prompts untuk normalisasi atau klasifikasi—misalnya, petakan nama negara yang tampil ke kode ISO atau kelompokkan layanan ke set kategori yang disetujui.
- Aktifkan penanganan pagination atau infinite scroll untuk halaman daftar.
- Pakai subpage scraping saat halaman dealer individual memuat nomor telepon, website, layanan, atau ID sumber.
- Ekspor sampel kecil ke Sheets atau Excel dan validasi setiap URL sumber.
Mode browser sangat membantu saat locator butuh interaksi, sesi login, atau rendering yang tidak bisa direproduksi oleh request sederhana. Gunakan hanya sumber dan akun yang memang diizinkan organisasi untuk diakses.
Pilih Situs Perwakilan, Bukan Situs yang Paling Mudah
Pilot pertama sebaiknya mencakup 20 situs yang mewakili pola, wilayah, dan teknologi halaman utama. Kalau semua sumber pilot cuma tabel statis sederhana, workflow akan terlihat mulus sampai locator berbasis peta yang pertama muncul.
Untuk setiap keluarga pola, validasi setidaknya:
- Satu contoh yang bersih
- Satu contoh berukuran besar
- Satu contoh dinamis atau tidak teratur
- Satu situs dengan halaman detail dealer
- Satu situs dengan field yang jarang atau opsional
Langkah 5: Skalakan Sumber Stabil dengan Batch Extract API
Untuk halaman publik yang bisa diulang, pindahkan job stabil dari operasi browser manual ke Thunderbit Web Scraper API.
Batch Extract endpoint menerima hingga 50 URL dalam satu request dengan satu JSON Schema. Endpoint ini mengembalikan job ID, memproses URL secara paralel, mendukung error per URL, bisa kirim notifikasi webhook, dan menyediakan opsi renderMode seperti none, basic, dan full.
Desain Batch
- Kelompokkan URL yang punya skema output semantik yang sama.
- Jaga batch di bawah atau sama dengan batas 50 URL per request.
- Pilih mode rendering paling ringan yang tetap bisa menampilkan data secara andal.
- Simpan job ID dan versi parser bersama hasil run.
- Catat status berhasil, kosong, dan error per URL—bukan cuma satu status untuk seluruh batch.
- Ulangi hanya URL yang gagal.
- Simpan nilai mentah hasil ekstraksi dan tautan sumber sebelum normalisasi.
Satu skema bisa mencakup situs dengan desain berbeda selama makna bisnis dari field-fieldnya konsisten. Itulah yang bikin direktori statis dan locator berbasis kartu peta bisa mengisi master dealer yang sama.
Langkah 6: Normalisasi Tanpa Menghapus Bukti
Normalisasi membuat record bisa dibandingkan; tapi proses ini jangan sampai bikin datanya tak bisa diaudit.
Transformasi yang disarankan meliputi:
- Menghapus spasi berlebih dan menormalkan tanda baca
- Menyeragamkan huruf kapital sambil tetap menyimpan
dealer_name_raw - Mengurai nomor telepon dengan konteks negara yang jelas
- Memetakan nama negara dan wilayah ke kode yang disetujui
- Memisahkan atau menggabungkan komponen alamat secara konsisten
- Menormalkan URL dan menghapus parameter pelacakan kalau perlu
- Memetakan layanan bebas teks ke kategori terkontrol sambil tetap menyimpan frasa sumber
Jangan menimpa label otorisasi dari sumber. Kalau satu produsen menulis “Authorized Dealer” dan yang lain “Certified Reseller,” simpan frasa persisnya dan, bila perlu, tambahkan kategori ternormalisasi di field terpisah.
Langkah 7: Resolusi Dealer di Lintas Brand dan Sumber
Pencocokan berdasarkan nama dealer saja tidak cukup. “Smith Auto,” “Smith Automotive,” dan “Smith Auto LLC” bisa jadi satu bisnis—atau malah tiga bisnis di kota yang berdekatan.
Pakai candidate key komposit seperti:
nama ternormalisasi + kode pos + telepon
atau, kalau koordinat tersedia:
nama ternormalisasi + jarak geospasial + nomor alamat
Lalu beri skor pada buktinya:
- Nama ternormalisasi yang persis atau hampir persis
- Nomor telepon yang sama
- Kode pos yang sama
- Alamat jalan yang mirip
- Koordinat dalam radius kecil
- Domain website yang cocok
Buat tabel mapping sumber-ke-kanonik alih-alih langsung menggabungkan record. Beberapa produsen bisa mengarah ke dealer fisik yang sama sambil tetap mempertahankan keanggotaan brand, layanan, dan label status yang berbeda.
Langkah 8: Deteksi Perubahan yang Bermakna
Setiap run harus diperlakukan sebagai observasi, bukan overwrite yang merusak.
Simpan:
observed_atuntuk run saat inifirst_seensaat record sumber pertama kali muncullast_seenuntuk observasi sukses terbaru- Source hash untuk record mentah
- Change hash untuk field bisnis yang sudah dinormalisasi
Jenis perubahan yang berguna meliputi:
- Dealer ditambahkan
- Dealer hilang
- Nama, alamat, telepon, atau website berubah
- Status otorisasi berubah
- Kategori layanan atau produk berubah
- Lokasi berpindah
- Halaman sumber gagal atau layout berubah
Record yang hilang sebaiknya lebih dulu jadi missing_pending_review. Konfirmasi penghapusan setelah ketidakhadiran berulang atau peninjauan manual. Crawl yang gagal, respons kosong, atau selector yang rusak bukan bukti bahwa dealer sudah tutup.
Langkah 9: Tambahkan Google Places sebagai Validasi Opsional
Google Places Place Details bisa memperkaya atau memvalidasi record dealer dengan place ID yang stabil, display name, formatted address, koordinat, nomor telepon, website, status bisnis, dan informasi lokasi yang pindah, tergantung field mask dan SKU yang diminta.
Pakai ini sebagai sinyal sekunder, bukan sebagai otoritas untuk menentukan apakah suatu lokasi termasuk ke program dealer produsen. Sumber produsen tetap jadi otoritas untuk keanggotaan itu. Simpan penyedia validasi dan timestamp-nya, dan jangan diam-diam menimpa status dari produsen.
Langkah 10: Ukur Kualitas Ekstraksi Berdasarkan Pola dan Sumber
Lacak kualitas di level run, pola, dan domain.
Metrik per Run
- URL sumber yang terdaftar
- URL yang dicoba
- URL yang berhasil, kosong, dan gagal
- Record yang diekstrak
- Record yang ditambahkan, berubah, hilang, dan tidak berubah
- Kelengkapan field inti
- Jumlah kandidat duplikat
- Dugaan penghapusan yang menunggu review
- Insiden schema drift
Validasi Sampel
Untuk setiap keluarga pola dan run utama:
- Bandingkan 20–50 record sampel dengan halaman sumbernya.
- Cocokkan jumlah URL yang diharapkan dengan jumlah yang dicoba dan yang berhasil.
- Tinjau field inti yang hilang per domain.
- Periksa klaster duplikat dan kecocokan entitas dengan confidence rendah.
- Cek outlier koordinat serta ketidaksesuaian negara/kode pos.
- Tinjau kembali sampel penghapusan yang terlihat.
- Catat versi extractor atau template yang dipakai.
Tujuannya bukan satu angka global “akurasi.” Yang penting adalah tahu pola dan sumber mana yang andal, field mana yang lemah, dan ke mana upaya review harus diarahkan.
Langkah 11: Arahkan Perubahan ke Workflow Bisnis
Jenis perubahan yang berbeda, tujuan akhirnya juga berbeda:
- Dealer baru: Kirim ke sales operations untuk pembuatan CRM, kepemilikan, dan penentuan wilayah.
- Lokasi dihapus atau tutup: Masukkan ke antrean review sebelum mengubah status akun.
- Perubahan alamat atau telepon: Perbarui enrichment dan verifikasi peluang aktif atau cakupan layanan.
- Perubahan otorisasi: Beri tahu tim channel management dan tim yang berhadapan langsung dengan pelanggan.
- Kesenjangan cakupan: Masukkan ke perencanaan wilayah dan rekrutmen partner.
- Ekspansi kompetitor: Perbarui intelligence distribusi dan strategi regional.
- Kegagalan sumber berulang: Kirim ke antrean data-operations, bukan ke tim sales.
Setiap notifikasi harus menyertakan dealer kanonik, keanggotaan brand, jenis perubahan, nilai sebelum-sesudah, URL sumber, waktu observasi, dan confidence atau status review.
Rencana Implementasi 30/60/90 Hari
Hari 1–30: Desain dan Pembuktian
- Finalisasi skema kanonik dan kategori terkontrol.
- Bangun registry sumber.
- Klasifikasikan 20 situs perwakilan.
- Buktikan 3–5 keluarga pola locator.
- Tetapkan aturan validasi sampel dan metrik run.
- Hasilkan master dealer awal dengan bukti sumber.
Hari 31–60: Perluas dan Otomatiskan
- Perluas klasifikasi ke seluruh portofolio.
- Pindahkan kelompok URL publik yang stabil ke batch extraction.
- Tambahkan jadwal, pelacakan job, retry logic, dan dashboard error.
- Perkenalkan mapping entitas sumber-ke-kanonik.
- Hubungkan penambahan dan pembaruan yang sudah direview ke workflow CRM.
Hari 61–90: Operasionalisasi Intelijen Perubahan
- Tambahkan notifikasi dan antrean review yang spesifik untuk perubahan.
- Perkenalkan first-seen, last-seen, dan konfirmasi penghapusan.
- Tambahkan validasi Places opsional bila meningkatkan keyakinan alamat.
- Tetapkan target layanan di level run.
- Tinjau performa pola dan template setiap bulan.
- Tetapkan penanggung jawab untuk setiap keluarga sumber dan aksi bisnis.
Mode Kegagalan yang Sering Terjadi
Membangun satu scraper per situs. Ini bikin ratusan jalur maintenance. Klasifikasikan keluarga pola dan pisahkan logika reusable dari konfigurasi sumber.
Dedup berdasarkan nama dealer. Nama sering tidak konsisten dan kerap dipakai ulang. Cocokkan dengan alamat, kode pos, telepon, koordinat, dan bukti website.
Menimpa nilai mentah. Kesalahan normalisasi jadi mustahil diaudit kalau representasi sumber hilang.
Menganggap output kosong sebagai nol dealer. Output kosong bisa berarti interaksi gagal, perubahan rendering, atau request diblokir. Pisahkan kesehatan crawl dari status bisnis.
Menyatakan lokasi dihapus setelah satu kali tidak ditemukan. Harus ada ketidakhadiran berulang atau verifikasi manual.
Menggunakan penyedia peta sebagai otoritas dealer. Data pemetaan bisa memvalidasi tempat, tetapi tidak bisa mengonfirmasi hubungan otorisasi produsen.
Diskalakan sebelum mengukur kualitas pola. Kesalahan ekstraksi kecil jadi masalah operasional besar kalau dikali ratusan situs.
FAQ
Apakah satu skema bisa dipakai untuk ratusan website dealer yang berbeda?
Ya. Layout halaman memang berbeda, tetapi field semantiknya—nama dealer, alamat, telepon, website, brand, layanan, URL sumber, dan status—relatif konsisten. Gunakan pola ekstraksi yang berbeda untuk mengisi satu skema kanonik.
Bagaimana sebaiknya halaman locator yang memerlukan pencarian berdasarkan kode pos diotomatisasi?
Anggap form pencarian sebagai keluarga pola tersendiri. Tentukan grid cakupan lokasi input, tangkap ID atau URL hasil, deduplikasi radius pencarian yang tumpang tindih, dan simpan input yang menghasilkan setiap hasil untuk kebutuhan debugging.
Seberapa sering lokasi dealer harus diperbarui?
Sesuaikan frekuensinya dengan kebutuhan bisnis dan perilaku sumber. Sumber kompetitif atau cakupan layanan bernilai tinggi mungkin berjalan mingguan; direktori produsen yang lebih lambat mungkin bulanan. Kegagalan run harus memicu review operasional yang terpisah dari cadence perubahan dealer.
Bagaimana sistem membedakan dealer yang dihapus dari scrape yang gagal?
Lacak kesehatan sumber dan keberadaan record secara terpisah. Crawl yang gagal atau kosong tidak memperbarui status last-seen dealer. Hanya run yang berhasil yang bisa jadi bukti ketidakhadiran, dan penghapusan harus memerlukan pengulangan atau review.
Apakah Google Places harus menggantikan alamat dan status bisnis dari website?
Tidak. Pakai Places sebagai enrichment atau validasi, simpan timestamp dan providernya, dan pertahankan locator produsen sebagai otoritas untuk keanggotaan program dealer.
Pelacakan dealer otomatis berhasil saat diperlakukan sebagai produk data: registry sumber yang terkelola, keluarga pola yang reusable, bukti yang tersimpan, resolusi entitas yang hati-hati, dan workflow perubahan yang dimiliki bisnis. Arsitektur seperti ini bisa tumbuh dari 20 situs pilot menjadi ratusan tanpa bikin setiap redesign berubah jadi rebuild darurat.
Pelajari Lebih Lanjut
