Lokace dealerů málokdy existují v jedné pohodlné databázi. Jeden výrobce zveřejňuje přehledný adresář, další používá interaktivní mapu, třetí vyžaduje vyhledávání podle PSČ a čtvrtý schovává detaily dealerů na samostatných profilových stránkách.
Jakmile se portfolio rozroste na stovky webů, už nejde jen o prosté „stažení několika adres“. Skutečným cílem má být spolehlivý master dat dealerů, který odpovídá na byznysové otázky:
- Kde se distribuce rozšiřuje, nebo naopak zmenšuje?
- Která území mají mezery v pokrytí?
- Kteří dealeři byli přidáni, přemístěni nebo odstraněni?
- Které lokace nabízejí konkrétní produktovou řadu nebo službu?
- Který vlastník v CRM má dostat nově objeveného dealera?
- Jak se v čase mění distribuční stopa konkurence?
Praktická architektura je jednoduchá: najít zdroje, rozpoznat typy lokátorů, vytáhnout data do jednoho kanonického schématu, uchovat důkazy ze zdroje, řešit duplicity, odhalovat smysluplné změny a předat je správnému týmu.
Cílový systém
Produkční workflow pro sledování dealerů má šest vrstev:
- Registr zdrojů: Weby, URL lokátorů, země, vlastníci, vzory, harmonogramy a stav posledního běhu.
- Discovery: Opakovatelný způsob, jak najít stránky s adresáři, sitemapy, API, vyhledávacími formuláři a URL detailů.
- Extrakce: Browser nebo API úlohy, které sbírají stejná sémantická pole napříč různými rozvrženími.
- Normalizace: Konzistentní adresy, telefonní čísla, země, kategorie a stavové štítky bez zničení původních hodnot.
- Vrstva entit a změn: Kanonické identity dealerů, členství ve značkách, timestampy prvního a posledního výskytu a potvrzená přidání nebo odstranění.
- Aktivace: Upozornění, směrování do CRM, analýza pokrytí, dashboardy a fronty pro kontrolu.
Pokus přeskočit rovnou z webů do importu v CRM většinou skončí křehkou hromadou jednorázových skriptů a duplicitních záznamů. Právě registr a kanonický model dělají stovky webů zvládnutelnými.
Krok 1: Definujte kanonické schéma dealerů
Začněte u výstupu, ne u prvního webu. Užitečné minimální schéma vypadá takto:
| Skupina | Pole |
|---|---|
| Důkazy ze zdroje | source_domain, source_locator_url, source_dealer_url, source_dealer_id |
| Identita | dealer_name_raw, dealer_name_normalized, brand, manufacturer |
| Adresa | street_address, address_locality, address_region, postal_code, address_country |
| Kontakt | phone_raw, phone_normalized, website |
| Poloha | latitude, longitude |
| Obchodní atributy | services, products, categories, authorized_status_raw |
| Pozorování | observed_at, first_seen, last_seen, record_status |
| Řízení změn | source_hash, change_hash, parser_version |
Schema.org PostalAddress je užitečný základ pro názvy polí jako street address, locality, region, postal code a country. V normalizovaných datech preferujte dvoupísmenné kódy zemí podle ISO, ale zároveň uchovávejte zemi přesně tak, jak ji zdroj uvádí.
Udržujte surová i normalizovaná pole vedle sebe. Když web uvádí St. John's, NL a normalizační vrstva z toho vytvoří standardizovanou provincii a telefonní předvolbu, obě verze musí zůstat dostupné ke kontrole.
Krok 2: Vytvořte registr zdrojů
Registr zdrojů je řídicí vrstva celé operace. Každému webu dejte jeden řádek s:
- Doménou a značkou
- Zemí nebo trhem
- Pravděpodobnou URL lokátoru
- Rodinou vzoru lokátoru
- Preferovaným režimem pro crawling
- Verzí parseru nebo šablony
- Frekvencí běhu
- Byznysovým vlastníkem
- Posledním pokusem, úspěšným, prázdným a neúspěšným během
- Poznámkami k vyhledávacím vstupům nebo požadavkům na interakci
Nečekejte, až budete rozumět každému lokátoru. Vytvořte registr nejdřív a klasifikaci zpřesňujte během pilotu.
Jak objevit zdroje lokátorů
Zkontrolujte:
- Hlavní navigaci a patičku, kde bývá „Najít dealera“, „Kde koupit“ nebo „Vyhledávač prodejen“
/sitemap.xmla sitemap indexy- Interní vyhledávání na webu
- Dotazy ve vyhledávači jako
site:brand.example dealer locator - Zdroj stránky a vložená strukturovaná data
- Síťové požadavky spuštěné vyhledáním v lokátoru
- PDF nebo dokumenty distributora jako záložní zdroj
Protokol Sitemap vyžaduje pro každou položku sitemap URL v tagu <loc> a podporuje sitemap indexy. Sitemapy mohou urychlit discovery, ale nezaručují, že zahrnou všechny dynamické výsledky lokátoru, a hodnotu <lastmod> nelze brát jako důkaz, že jsou data dealerů čerstvá.
Krok 3: Klasifikujte každý lokátor před škálováním
Většina webů dealerů spadá do několika rodin vzorů:
- Statický HTML seznam nebo tabulka — nejjednodušší případ; záznamy jsou přímo v HTML zdroji stránky.
- Stránkovaný adresář nebo nekonečný scroll — záznamy se opakují, ale vyžadují navigaci.
- Mapové karty s odkazy na detaily — souhrnné karty potřebují obohacení z podstránek.
- Vyhledávací formulář — uživatel musí zadat zemi, stát, město nebo PSČ.
- Vložené JSON nebo síťová odpověď — stránka je vizuální „skořápka“ kolem strukturovaných dat.
- Úzký seznam plus detailní stránky dealerů — seznam obsahuje identitu, ale adresy a služby jsou na podstránkách.
- PDF nebo dokumentový adresář — extrakce i kontrola změn potřebují specifický dokumentový postup.
Jeden univerzální scraper nezvládne stovky webů stejně dobře. Škálovatelný přístup je postavit jeden znovupoužitelný workflow pro každou rodinu vzorů a potom ho pro každý zdroj nakonfigurovat.
Krok 4: Ověřte browser workflow pomocí Thunderbit
Thunderbit se hodí k ověření schématu na reprezentativních webech ještě před investicí do hromadné automatizace.
Postup pilotu
- Otevřete reprezentativní adresář dealerů v Chromu.
- Spusťte Thunderbit a použijte AI Suggest Fields.
- Přejmenujte navržená pole podle kanonického schématu.
- Přidejte AI prompty pro pole kvůli normalizaci nebo klasifikaci — například mapujte viditelný název země na ISO kód nebo zařaďte služby do schválené sady kategorií.
- Zapněte ošetření stránkování nebo nekonečného scrollu pro seznamové stránky.
- Použijte scraping podstránek tam, kde jednotlivé stránky dealerů obsahují telefon, web, služby nebo source ID.
- Exportujte malý vzorek do Sheets nebo Excelu a ověřte každou zdrojovou URL.
Browser režim je obzvlášť užitečný, když lokátor vyžaduje interakci, přihlášenou relaci nebo vykreslení, které jednoduchý request nedokáže reprodukovat. Používejte jen zdroje a účty, ke kterým má organizace oprávnění přístupu.
Nevybírejte nejjednodušší weby, ale reprezentativní vzorek
První pilot by měl zahrnovat 20 webů pokrývajících hlavní vzory, regiony a technologie stránek. Pokud budou všechny pilotní zdroje jednoduché statické tabulky, workflow bude vypadat perfektně — dokud nepřijde první lokátor založený na mapě.
Pro každou rodinu vzorů ověřte alespoň:
- Jeden čistý příklad
- Jeden velký příklad
- Jeden dynamický nebo nepravidelný příklad
- Jeden web s detailními stránkami dealerů
- Jeden web s řídkými nebo volitelnými poli
Krok 5: Stabilní zdroje škálujte pomocí Batch Extract API
U opakovatelných veřejných stránek přesuňte stabilní úlohy z ručního browserového provozu na Thunderbit Web Scraper API.
Batch Extract endpoint přijme až 50 URL v jednom requestu s jedním JSON Schema. Vrací job ID, zpracovává URL paralelně, podporuje chyby pro jednotlivé URL, umí posílat webhook notifikace a nabízí volby renderMode jako none, basic a full.
Návrh batchů
- Seskupujte URL, které mají stejný sémantický výstupní formát.
- Držte dávky na limitu 50 URL nebo pod ním.
- Zvolte nejlehčí renderovací režim, který data spolehlivě zpřístupní.
- Ukládejte job ID a verzi parseru spolu s během.
- Evidujte stav úspěchu, prázdného výstupu a chyby pro každou URL, ne jen jeden stav pro celou dávku.
- Znovu spouštějte pouze neúspěšné URL.
- Uchovávejte surové extrahované hodnoty a odkazy na zdroj ještě před normalizací.
Jedno schéma může pokrýt různě navržené weby, pokud je obchodní význam polí stejný. Právě to umožňuje, aby statický adresář i lokátor s mapovými kartami plnily stejný dealer master.
Krok 6: Normalizujte bez ztráty důkazů
Normalizace má dělat záznamy porovnatelné; nemá je ale udělat neauditovatelnými.
Doporučené transformace zahrnují:
- Ořezávání mezer a normalizaci interpunkce
- Sjednocení velikosti písmen při zachování
dealer_name_raw - Parsování telefonních čísel s explicitním kontextem země
- Mapování názvů zemí a regionů na schválené kódy
- Konzistentní rozdělování nebo spojování adresních komponent
- Normalizaci URL a odstranění sledovacích parametrů, kde je to vhodné
- Mapování volně psaných služeb do řízených kategorií při zachování původní fráze
Nepřepisujte autorizační štítek ze zdroje. Pokud jeden výrobce říká „Authorized Dealer“ a jiný „Certified Reseller“, uložte přesnou frázi a případně přidejte normalizovanou kategorii do samostatného pole.
Krok 7: Párujte dealery napříč značkami a zdroji
Shoda podle názvu dealera sama o sobě nestačí. „Smith Auto“, „Smith Automotive“ a „Smith Auto LLC“ mohou být jedna firma — nebo tři různé firmy v sousedních městech.
Použijte složený kandidátský klíč, například:
normalized name + postal code + phone
nebo, pokud jsou k dispozici souřadnice:
normalized name + geospatial distance + address number
Poté skórujte důkazy:
- Přesná nebo téměř přesná normalizovaná shoda názvu
- Shodné telefonní číslo
- Stejné PSČ
- Podobná ulice a číslo
- Souřadnice v malém okruhu
- Shodná doména webu
Vytvořte tabulku mapování zdroj → kanonická entita místo toho, abyste záznamy hned slučovali. Více výrobců může odkazovat na stejného fyzického dealera, přičemž si zachovávají samostatná členství ve značkách, služby i stavové štítky.
Krok 8: Detekujte smysluplné změny
Každý běh by měl být pozorování, ne destruktivní přepis.
Ukládejte:
observed_atpro aktuální běhfirst_seen, kdy se zdrojový záznam objevil poprvélast_seenpro nejnovější úspěšné pozorování- Source hash pro surový záznam
- Change hash pro normalizovaná obchodní pole
Užitečné typy změn zahrnují:
- Dealer přidán
- Dealer chybí
- Změna názvu, adresy, telefonu nebo webu
- Změna autorizačního statusu
- Změna služby nebo produktové kategorie
- Přesun lokace
- Selhání zdrojové stránky nebo posun layoutu
Chybějící záznam by se měl nejdřív stát missing_pending_review. Odstranění potvrďte až po opakované absenci nebo ruční kontrole. Selhaný crawl, prázdná odpověď nebo rozbitý selektor nejsou důkazem, že dealer zavřel.
Krok 9: Přidejte Google Places jako volitelnou validaci
Google Places Place Details může obohatit nebo ověřit záznam dealera pomocí stabilního place ID, zobrazovaného názvu, formátované adresy, souřadnic, telefonu, webu, business status a informace o přemístění místa — podle požadovaného field masku a SKU.
Používejte ho jako sekundární signál, ne jako autoritu pro to, jestli lokace patří do dealerského programu výrobce. Autoritativním zdrojem pro tohle členství zůstává zdroj výrobce. Ukládejte poskytovatele validace i timestamp a bez upozornění nepřepisujte status výrobce.
Krok 10: Měřte kvalitu extrakce podle vzoru i zdroje
Kvalitu sledujte na úrovni běhu, vzoru i domény.
Metriky na úrovni běhu
- Registrované URL zdrojů
- Pokusů o načtení URL
- Úspěšných, prázdných a neúspěšných URL
- Vytěžených záznamů
- Záznamů přidaných, změněných, chybějících a beze změny
- Kompletnost klíčových polí
- Počet kandidátů na duplicitu
- Podezřelé odstraněné záznamy čekající na kontrolu
- Případy driftu schématu
Ukázková validace
Pro každou rodinu vzorů a každý větší běh:
- Porovnejte 20–50 vzorků se zdrojovými stránkami.
- Ověřte očekávaný počet URL vůči počtu pokusů a úspěchů.
- Zkontrolujte chybějící klíčová pole podle domény.
- Prohlédněte si clustery duplicit a entity s nízkou mírou jistoty.
- Zkontrolujte odchylky souřadnic a nesoulad zemí/PSČ.
- Vraťte se k vzorku zdánlivě odstraněných záznamů.
- Zapište verzi extractoru nebo šablony, která byla použita.
Cílem není jedno globální procento „accuracy“. Jde o to vědět, které vzory a zdroje jsou spolehlivé, která pole jsou slabá a kam má směřovat kontrolní úsilí.
Krok 11: Směrujte změny do byznysových workflow
Různé změny patří do různých destinací:
- Nový dealer: Předat sales operations pro vytvoření záznamu v CRM, přiřazení vlastníka a rozdělení území.
- Odstraněná nebo uzavřená lokace: Poslat do fronty ke kontrole, než se změní stav účtu.
- Změna adresy nebo telefonu: Aktualizovat enrichment a ověřit otevřené příležitosti nebo servisní pokrytí.
- Změna autorizace: Upozornit channel management a týmy v kontaktu se zákazníky.
- Mezera v pokrytí: Předat do plánování území a partner recruitment.
- Expanze konkurenta: Aktualizovat distribuční intelligence a regionální strategii.
- Opakované selhání zdroje: Poslat do queue datových operací, ne do sales týmu.
Každé upozornění by mělo obsahovat kanonického dealera, členství ve značce, typ změny, hodnoty před/po, URL zdroje, čas pozorování a stav jistoty nebo kontroly.
Plán nasazení na 30/60/90 dní
Dny 1–30: Návrh a ověření
- Dokončit kanonické schéma a řízené kategorie.
- Vytvořit registr zdrojů.
- Klasifikovat 20 reprezentativních webů.
- Ověřit 3–5 rodin vzorů lokátorů.
- Zavést pravidla pro sample validaci a metriky běhu.
- Dodat první dealer master s důkazy ze zdrojů.
Dny 31–60: Rozšíření a automatizace
- Rozšířit klasifikaci napříč portfoliem.
- Přesunout stabilní skupiny veřejných URL do batch extrakce.
- Přidat harmonogramy, tracking jobů, retry logiku a error dashboardy.
- Zavést mapování zdroj → kanonická entita.
- Napojit kontrolovaná přidání a aktualizace do CRM workflow.
Dny 61–90: Zprovoznění intelligence pro změny
- Přidat upozornění specifická pro změny a kontrolní fronty.
- Zavést first-seen, last-seen a potvrzení odstranění.
- Přidat volitelnou validaci Places tam, kde zlepší jistotu adresy.
- Definovat servisní cíle na úrovni běhu.
- Měsíčně vyhodnocovat výkon vzorů a šablon.
- Přiřadit vlastníka pro každou rodinu zdrojů a každý byznysový krok.
Časté chyby
Jeden scraper na každý web. Tím vzniknou stovky údržbových cest. Klasifikujte rodiny vzorů a oddělte znovupoužitelnou logiku od konfigurace zdroje.
Dedup podle názvu dealera. Názvy jsou nekonzistentní a často se opakují. Párujte podle adresy, PSČ, telefonu, souřadnic a důkazů z webu.
Přepisování surových hodnot. Jakmile se ztratí původní podoba, chyby v normalizaci už nejdou auditovat.
Považování prázdného výstupu za nulové dealery. Prázdný výstup může znamenat chybnou interakci, změnu renderování nebo blokovaný request. Zdraví crawlů oddělujte od byznysového statusu.
Prohlášení odstranění po jednom výpadku. Vyžadujte opakovanou absenci nebo ruční ověření.
Použití mapového providera jako autority pro dealera. Mapová data mohou ověřit místo, ale nepotvrdí autorizační vztah s výrobcem.
Škálování před měřením kvality vzorů. Malá chyba v extrakci se při stovkách webů změní na velký provozní problém.
Nejčastější dotazy
Může jedno schéma fungovat napříč stovkami různých webů dealerů?
Ano. Rozložení stránek se liší, ale sémantická pole — název dealera, adresa, telefon, web, značka, služby, URL zdroje a status — jsou z velké části stejná. Pro naplnění jednoho kanonického schématu použijte různé extrakční vzory.
Jak automatizovat lokátorové stránky, které vyžadují vyhledávání podle PSČ?
Považujte vyhledávací formulář za samostatnou rodinu vzorů. Definujte pokryvnou mřížku vstupních lokalit, zachycujte ID nebo URL výsledků, deduplikujte překrývající se vyhledávací okruhy a uchovávejte vstup, který vedl k danému výsledku, pro debugging.
Jak často by se měly lokace dealerů obnovovat?
Frekvenci přizpůsobte využití byznysem a chování zdroje. Vysoce hodnotné konkurenční nebo servisně-pokryvné zdroje mohou běžet týdně; pomalejší adresáře výrobců měsíčně. Selhání běhu by měla spustit provozní kontrolu nezávisle na frekvenci změn dealerů.
Jak systém pozná, že dealer skutečně zmizel, a ne že jen selhal scraping?
Sledujte odděleně zdraví zdroje a přítomnost záznamu. Selhaný nebo prázdný crawl neaktualizuje status last-seen dealera. Důkaz absence mohou poskytnout jen úspěšné běhy a odstranění by mělo vyžadovat opakování nebo kontrolu.
Má Google Places nahradit adresu a business status z webu?
Ne. Používejte Places jako enrichment nebo validaci, ukládejte jeho timestamp a poskytovatele a jako autoritu pro členství v dealerském programu ponechte lokátor výrobce.
Automatizované sledování dealerů funguje tehdy, když se k němu přistupuje jako k datovému produktu: spravovaný registr zdrojů, znovupoužitelné rodiny vzorů, uchované důkazy, opatrné řešení entit a byznysově vlastněné workflow pro změny. Tahle architektura může vyrůst z 20 pilotních webů na stovky, aniž by každá redesignace znamenala krizový rebuild.
Další informace
