Dealerlocaties staan zelden netjes in één centrale database. De ene fabrikant publiceert een overzichtelijke directory, de andere gebruikt een interactieve kaart, een derde verlangt een postcodezoekopdracht en een vierde verstopt dealerinformatie achter losse profielpagina’s.
Zodra je portfolio groeit naar honderden websites, is de klus niet meer simpelweg “een paar adressen scrapen”. Het echte eindproduct is een betrouwbare dealer-master die zakelijke vragen beantwoordt:
- Waar breidt distributie uit of krimpt die juist?
- Welke regio’s hebben dekkingstekorten?
- Welke dealers zijn toegevoegd, verhuisd of verwijderd?
- Welke locaties voeren een specifieke productlijn of dienst?
- Welke CRM-eigenaar moet een nieuw gevonden dealer krijgen?
- Hoe verandert de kanaalvoetafdruk van een concurrent in de loop van de tijd?
De praktische architectuur is rechttoe rechtaan: vind de bronnen, classificeer locatorpatronen, extraheer naar Ă©Ă©n canoniek schema, bewaar bronbewijs, los duplicaten op, detecteer relevante wijzigingen en stuur ze door naar het juiste team.
Het Doelsysteem
Een productieklare workflow voor dealertracking heeft zes lagen:
- Bronregister: De websites, locator-URL’s, landen, eigenaren, patronen, planningen en laatste run-status.
- Ontdekking: Een herhaalbare manier om directorypagina’s, sitemaps, API’s, zoekformulieren en detail-URL’s te vinden.
- Extractie: Browser- of API-jobs die dezelfde semantische velden verzamelen over verschillende layouts heen.
- Normalisatie: Consistente adressen, telefoonnummers, landen, categorieën en statuslabels zonder de ruwe waarden te verliezen.
- Entiteits- en wijzigingslaag: Canonieke dealeridentiteiten, merkrelaties, timestamps van eerste en laatste waarneming, en bevestigde toevoegingen of verwijderingen.
- Activatie: Alerts, CRM-routing, dekkingsanalyse, dashboards en review-queues.
Wie rechtstreeks van websites naar een CRM-import wil springen, eindigt meestal met een fragiele stapel losse scripts en dubbele records. Juist het bronregister en het canonieke model maken honderden sites beheersbaar.
Stap 1: Definieer het canonieke dealerschema
Begin bij de output, niet bij de eerste website. Een bruikbaar minimumschema is:
| Groep | Velden |
|---|---|
| Bronbewijs | source_domain, source_locator_url, source_dealer_url, source_dealer_id |
| Identiteit | dealer_name_raw, dealer_name_normalized, brand, manufacturer |
| Adres | street_address, address_locality, address_region, postal_code, address_country |
| Contact | phone_raw, phone_normalized, website |
| Locatie | latitude, longitude |
| Commerciële attributen | services, products, categories, authorized_status_raw |
| Waarneming | observed_at, first_seen, last_seen, record_status |
| Wijzigingsbeheer | source_hash, change_hash, parser_version |
Schema.org's PostalAddress biedt een handig uitgangspunt voor straatadres, plaats, regio, postcode en land. Gebruik bij genormaliseerde data bij voorkeur ISO-landcodes van twee letters, maar bewaar het land ook exact zoals de bron het publiceert.
Houd ruwe en genormaliseerde velden naast elkaar. Als een site St. John's, NL vermeldt en de normalisatielaag daar een gestandaardiseerde provincie- en telefoonaanduiding van maakt, blijven beide versies beschikbaar voor controle.
Stap 2: Bouw een bronregister
Het bronregister is het controlevlak van de operatie. Geef elke website Ă©Ă©n regel met:
- Domein en merk
- Land of markt
- Vermoedelijke locator-URL
- Locator-patroonfamilie
- Voorkeurs crawlmodus
- Parser- of templatesversie
- Runfrequentie
- Zakelijke eigenaar
- Laatste poging, geslaagde run, lege run en mislukte run
- Notities over zoekinputs of interactievereisten
Wacht niet tot elke locator volledig begrepen is. Maak eerst het register en laat de classificatie verbeteren terwijl de pilot vordert.
Hoe je locatorbronnen ontdekt
Controleer:
- Hoofdnavigatie en voettekstlinks zoals “Find a dealer”, “Where to buy” of “Store locator”
/sitemap.xmlen sitemap-indexen- Interne zoekfunctie van de site
- Zoekmachinequeries zoals
site:brand.example dealer locator - Paginabron en ingesloten gestructureerde data
- Netwerkverzoeken die door een locatorzoekopdracht worden getriggerd
- PDF- of distributeursdocumenten als terugvalbron
Het Sitemaps protocol vereist een <loc>-URL voor elke sitemap-entry en ondersteunt sitemap-indexen. Sitemaps kunnen het vinden versnellen, maar garanderen niet dat elk dynamisch locatorresultaat is opgenomen. Een <lastmod>-waarde mag je bovendien niet zien als bewijs dat dealerinformatie echt actueel is.
Stap 3: Classificeer elke locator vóór je opschaalt
De meeste dealerwebsites vallen in een kleine set patroonfamilies:
- Statische HTML-lijst of tabel — het eenvoudigste geval; records staan in de paginabron.
- Gepagineerde directory of infinite scroll — records herhalen zich, maar vereisen navigatie.
- Kaartkaarten met detaillinks — samenvattende kaarten hebben verrijking via subpagina’s nodig.
- Zoekformulier — de gebruiker moet een land, staat, stad of postcode invullen.
- Ingesloten JSON of netwerkrespons — de pagina is een visuele schil rond gestructureerde data.
- Dunne lijst plus dealerdetailpagina’s — de lijst bevat identiteit, terwijl adressen en services op subpagina’s staan.
- PDF- of documentdirectory — extractie en wijzigingscontrole vragen om een document-specifieke aanpak.
EĂ©n universele scraper kan honderden sites niet allemaal goed aan. De schaalbare aanpak is: bouw per patroonfamilie Ă©Ă©n herbruikbare workflow en pas daar configuratie per bron op toe.
Stap 4: Pilot de browserworkflow met Thunderbit
Thunderbit is handig om het schema op representatieve sites te bewijzen voordat je in bulkautomatisering investeert.
Pilotprocedure
- Open een representatieve dealerdirectory in Chrome.
- Start Thunderbit en gebruik AI Suggest Fields.
- Hernoem voorgestelde velden naar het canonieke schema.
- Voeg Field AI Prompts toe voor normalisatie of classificatie — bijvoorbeeld: map de zichtbare landnaam naar een ISO-code of classificeer services in een goedgekeurde categorielijst.
- Schakel paginering of infinite-scroll-afhandeling in voor lijstpagina’s.
- Gebruik subpage scraping wanneer afzonderlijke dealerpagina’s telefoonnummers, websites, services of bron-ID’s bevatten.
- Exporteer een kleine steekproef naar Sheets of Excel en valideer elke bron-URL.
Browsermodus is vooral nuttig wanneer een locator interactie vereist, een ingelogde sessie nodig heeft of rendering gebruikt die een simpele request niet nabootst. Gebruik uitsluitend bronnen en accounts waartoe de organisatie geautoriseerd is.
Kies representatieve sites, niet de makkelijkste sites
De eerste pilot moet 20 sites bevatten die de belangrijkste patronen, regio’s en paginatypes afdekken. Als elke pilotbron een simpele statische tabel is, lijkt de workflow perfect totdat de eerste kaartgebaseerde locator verschijnt.
Valideer voor elke patroonfamilie ten minste:
- EĂ©n schoon voorbeeld
- EĂ©n groot voorbeeld
- EĂ©n dynamisch of onregelmatig voorbeeld
- Eén site met dealerdetailpagina’s
- EĂ©n site met sparse of optionele velden
Stap 5: Schaal stabiele bronnen met de Batch Extract API
Voor herhaalbare openbare pagina’s verplaats je stabiele jobs van handmatige browserbediening naar de Thunderbit Web Scraper API.
Het Batch Extract endpoint accepteert tot 50 URL’s per request met één JSON Schema. Het geeft een job-ID terug, verwerkt URL’s parallel, ondersteunt fouten per URL, kan webhookmeldingen versturen en biedt renderMode-opties zoals none, basic en full.
Batchontwerp
- Groepeer URL’s die hetzelfde semantische outputschema delen.
- Houd batches op of onder de limiet van 50 URL’s per request.
- Kies de lichtste renderingmodus die de data betrouwbaar zichtbaar maakt.
- Bewaar job-ID en parserversie samen met de run.
- Leg succes-, lege- en foutstatus vast per URL — niet alleen één status voor de hele batch.
- Herprobeer alleen mislukte URL’s.
- Bewaar ruwe extractiewaarden en bronlinks vóór normalisatie.
EĂ©n schema kan websites met verschillende ontwerpen afdekken, zolang de zakelijke betekenis van de velden consistent is. Dat maakt het mogelijk dat een statische directory en een locator met kaartkaarten allebei dezelfde dealer-master voeden.
Stap 6: Normaliseer zonder bewijs te wissen
Normalisatie maakt records vergelijkbaar; het mag ze niet onauditbaar maken.
Aanbevolen transformaties zijn onder andere:
- Witruimte trimmen en interpunctie normaliseren
- Hoofd-/kleine letters standaardiseren terwijl
dealer_name_rawbehouden blijft - Telefoonnummers parseren met expliciete landcontext
- Land- en regiolanden toewijzen aan goedgekeurde codes
- Adrescomponenten consistent splitsen of samenvoegen
- URL’s normaliseren en waar passend trackingparameters verwijderen
- Vrije tekst voor services mappen naar gecontroleerde categorieën, terwijl de bronfrase behouden blijft
Overschrijf het autorisatielabel van de bron niet. Als de ene fabrikant “Authorized Dealer” zegt en een andere “Certified Reseller”, sla dan de exacte formulering op en voeg optioneel een genormaliseerde categorie toe in een apart veld.
Stap 7: Los dealers op over merken en bronnen heen
Alleen op dealernaam matchen is niet genoeg. “Smith Auto”, “Smith Automotive” en “Smith Auto LLC” kunnen één bedrijf zijn — of drie bedrijven in naburige steden.
Gebruik een samengestelde kandidaatsleutel zoals:
genormaliseerde naam + postcode + telefoon
of, wanneer coördinaten beschikbaar zijn:
genormaliseerde naam + geografische afstand + huisnummer
Scoor vervolgens het bewijs:
- Exacte of bijna-exacte genormaliseerde naam
- Exact telefoonnummer
- Dezelfde postcode
- Vergelijkbaar straatadres
- Coördinaten binnen een kleine straal
- Overeenkomend websitedomein
Maak een mappingtabel van bron naar canonieke entiteit in plaats van records meteen samen te voegen. Meerdere fabrikanten kunnen naar dezelfde fysieke dealer verwijzen, terwijl merkrelaties, services en statuslabels apart blijven bestaan.
Stap 8: Detecteer betekenisvolle wijzigingen
Elke run moet een waarneming zijn, geen destructieve overschrijving.
Sla het volgende op:
observed_atvoor de huidige runfirst_seenwanneer het bronrecord voor het eerst verscheenlast_seenvoor de meest recente geslaagde waarneming- Een source hash voor het ruwe record
- Een change hash voor de genormaliseerde bedrijfsvelden
Nuttige wijzigingstypen zijn onder andere:
- Dealer toegevoegd
- Dealer ontbreekt
- Naam, adres, telefoon of website gewijzigd
- Autorisatiestatus gewijzigd
- Service- of productcategorie gewijzigd
- Locatie verplaatst
- Bronpagina faalde of layout verschoof
Een ontbrekend record moet eerst missing_pending_review worden. Bevestig verwijdering pas na herhaalde afwezigheid of handmatige review. Een mislukte crawl, lege respons of kapotte selector is geen bewijs dat een dealer is gesloten.
Stap 9: Voeg Google Places toe als optionele validatie
Google Places Place Details kan een dealerrecord verrijken of valideren met een stabiele place ID, weergavenaam, opgemaakt adres, coördinaten, telefoon, website, bedrijfsstatus en verhuisinformatie, afhankelijk van het gevraagde field mask en de SKU.
Gebruik dit als secundair signaal, niet als autoriteit voor de vraag of een locatie onderdeel is van het dealerprogramma van een fabrikant. De bron van de fabrikant blijft leidend voor dat lidmaatschap. Bewaar de validatieprovider en timestamp en overschrijf de status van de fabrikant niet stilzwijgend.
Stap 10: Meet extractiekwaliteit per patroon en bron
Volg kwaliteit op run-, patroon- en domeinniveau.
Metrics per run
- Geregistreerde bron-URL’s
- Geprobeerde URL’s
- Geslaagde, lege en mislukte URL’s
- Geëxtraheerde records
- Toegevoegde, gewijzigde, ontbrekende en onveranderde records
- Volledigheid van kernvelden
- Aantal dubbelkandidaten
- Vermoedelijke verwijderingen in afwachting van review
- Schema-drift-incidenten
Steekproefsvalidatie
Voor elke patroonfamilie en belangrijke run:
- Vergelijk 20–50 steekproefrecords met hun bronpagina’s.
- Controleer het verwachte aantal URL’s versus geprobeerde en succesvolle aantallen.
- Bekijk ontbrekende kernvelden per domein.
- Inspecteer duplicaatclusters en entiteitsmatches met lage zekerheid.
- Controleer uitbijters in coördinaten en land/postcode-mismatches.
- Bekijk een steekproef van schijnbare verwijderingen opnieuw.
- Noteer de gebruikte extractor- of templateversie.
Het doel is niet één globale “accuracy”-score. Het doel is weten welke patronen en bronnen betrouwbaar zijn, welke velden zwak zijn en waar review-inspanning naartoe moet.
Stap 11: Routeer wijzigingen naar bedrijfsprocessen
Verschillende wijzigingen verdienen verschillende bestemmingen:
- Nieuwe dealer: Doorzetten naar sales operations voor CRM-aanmaak, eigenaarschap en territory-toewijzing.
- Verwijderde of gesloten locatie: Naar een review-queue sturen vóór accountstatuswijziging.
- Adres- of telefoonwijziging: Verrijking bijwerken en open kansen of service-dekking verifiëren.
- Wijziging in autorisatie: Channel management en klantgerichte teams informeren.
- Dekkingsgat: Voeden van territory planning en partnerwerving.
- Uitbreiding van een concurrent: Distributie-intelligence en regionale strategie bijwerken.
- Herhaalde bronfout: Naar de data-operations-queue sturen, niet naar het salesteam.
Elke melding moet de canonieke dealer, merkrelatie, wijzigingstype, oude en nieuwe waarden, bron-URL, waarnemingstijd en confidence- of reviewstatus bevatten.
Een 30/60/90-dagen uitrolplan
Dagen 1–30: Ontwerpen en bewijzen
- Rond het canonieke schema en de gecontroleerde categorieën af.
- Bouw het bronregister.
- Classificeer 20 representatieve websites.
- Bewijs 3–5 locator-patroonfamilies.
- Stel regels voor steekproefsvalidatie en runmetrics vast.
- Lever een eerste dealer-master op met bronbewijs.
Dagen 31–60: Uitbreiden en automatiseren
- Breid classificatie uit over het volledige portfolio.
- Verplaats stabiele openbare URL-groepen naar batch-extractie.
- Voeg planningen, jobtracking, retry-logica en foutendashboards toe.
- Introduceer de bron-naar-canonieke entiteitsmapping.
- Koppel beoordeelde toevoegingen en updates aan CRM-workflows.
Dagen 61–90: Wijzigingsintelligentie operationeel maken
- Voeg wijzigingsspecifieke alerts en review-queues toe.
- Introduceer first-seen, last-seen en bevestiging van verwijdering.
- Voeg optioneel Places-validatie toe waar dat de adreszekerheid verhoogt.
- Definieer serviceniveaus op runniveau.
- Beoordeel de prestaties van patronen en templates maandelijks.
- Wijs voor elke bronfamilie en businessactie een eigenaar toe.
Veelvoorkomende faalmodi
Voor elke website een eigen scraper bouwen. Dit creëert honderden onderhoudspaden. Classificeer patroonfamilies en scheid herbruikbare logica van bronconfiguratie.
Dedupliceren op dealernaam. Namen zijn inconsistent en worden vaak hergebruikt. Match op bewijs uit adres, postcode, telefoon, coördinaten en website.
Ruwe waarden overschrijven. Normalisatiefouten zijn niet meer te auditen wanneer de oorspronkelijke representatie verloren gaat.
Lege output zien als nul dealers. Lege output kan ook wijzen op een mislukte interactie, een renderingwijziging of een geblokkeerd request. Houd crawlgezondheid los van bedrijfsstatus.
Verwijdering verklaren na Ă©Ă©n miss. Vereis herhaalde afwezigheid of handmatige verificatie.
Een kaartprovider als dealerautoriteit gebruiken. Kaartdata kan een plek valideren, maar kan geen autorisatieregeling van een fabrikant bevestigen.
Opschalen voordat de patroonkwaliteit is gemeten. Een kleine extractiefout wordt een groot operationeel probleem zodra die wordt vermenigvuldigd over honderden sites.
FAQ's
Kan Ă©Ă©n schema werken voor honderden verschillende dealerwebsites?
Ja. Pagina-layouts verschillen, maar de semantische velden — dealernaam, adres, telefoon, website, merk, services, bron-URL en status — zijn grotendeels gelijk. Gebruik verschillende extractiepatronen om één canoniek schema te vullen.
Hoe automatiseer je locatorpagina’s die een postcodezoekopdracht vereisen?
Behandel het zoekformulier als een eigen patroonfamilie. Definieer een dekkingsraster van invoerlocaties, leg de resulterende ID’s of URL’s vast, dedupliceer overlappende zoekstralen en bewaar de input die elk resultaat opleverde voor debugging.
Hoe vaak moeten dealerlocaties ververst worden?
Laat de frequentie aansluiten op zakelijk gebruik en brongedrag. Waardevolle concurrentie- of service-dekkingbronnen kunnen wekelijks draaien; trager veranderende fabrikantsdirectories misschien maandelijks. Runfouten moeten apart van de dealerwijzigingsfrequentie een operationele review triggeren.
Hoe kan het systeem een verwijderde dealer onderscheiden van een mislukte scrape?
Volg brongezondheid en recordaanwezigheid afzonderlijk. Een mislukte of lege crawl werkt de last-seen-status van de dealer niet bij. Alleen geslaagde runs kunnen afwezigheidsbewijs leveren, en verwijdering moet herhaling of review vereisen.
Moet Google Places het adres en de bedrijfsstatus van de website vervangen?
Nee. Gebruik Places voor verrijking of validatie, sla timestamp en provider op, en behoud de locator van de fabrikant als autoriteit voor deelname aan het dealerprogramma.
Geautomatiseerde dealertracking slaagt wanneer het wordt behandeld als een dataproduct: een beheerd bronregister, herbruikbare patroonfamilies, bewaard bewijs, voorzichtige entiteitsoplossing en door het bedrijf gedragen wijzigingsworkflows. Die architectuur kan van 20 pilot-sites doorgroeien naar honderden zonder dat elke redesign een noodreparatie wordt.
Meer weten
