Le sedi dei dealer raramente si trovano in un unico database comodo da consultare. Un produttore pubblica un elenco pulito, un altro usa una mappa interattiva, un terzo richiede una ricerca per CAP, e un quarto nasconde i dettagli dei dealer dietro pagine profilo singole.
Quando il portfolio cresce fino a centinaia di siti, il lavoro non è più “estrarre qualche indirizzo”. Il vero prodotto è un archivio affidabile dei dealer che risponde a domande di business come:
- Dove la distribuzione sta crescendo o rallentando?
- Quali territori hanno lacune di copertura?
- Quali dealer sono stati aggiunti, spostati o rimossi?
- Quali sedi offrono una determinata linea di prodotto o servizio?
- Quale referente CRM dovrebbe ricevere un dealer appena individuato?
- Come cambia nel tempo la presenza di canale di un concorrente?
L’architettura pratica è lineare: individuare le fonti, classificare i pattern dei locator, estrarre i dati in uno schema canonico, conservare le prove della fonte, risolvere i duplicati, rilevare i cambiamenti significativi e indirizzarli al team giusto.
Il sistema di destinazione
Un workflow di monitoraggio dealer pronto per la produzione ha sei livelli:
- Registro delle fonti: siti web, URL dei locator, Paesi, owner, pattern, pianificazioni e stato dell’ultimo run.
- Discovery: un metodo ripetibile per trovare pagine directory, sitemap, API, form di ricerca e URL di dettaglio.
- Estrazione: job browser o API che raccolgono gli stessi campi semantici su layout diversi.
- Normalizzazione: indirizzi, numeri di telefono, Paesi, categorie e label di stato coerenti, senza perdere i valori originali.
- Livello entità e cambiamenti: identità canoniche dei dealer, appartenenze ai brand, timestamp di prima e ultima rilevazione, e aggiunte o rimozioni confermate.
- Attivazione: alert, instradamento CRM, analisi della copertura, dashboard e code di revisione.
Saltare direttamente dai siti web a un import CRM di solito produce un insieme fragile di script ad hoc e record duplicati. Il registro e il modello canonico sono ciò che rende gestibili centinaia di siti.
Passo 1: definire lo schema canonico dei dealer
Parti dall’output, non dal primo sito web. Uno schema minimo utile è il seguente:
| Gruppo | Campi |
|---|---|
| Prove della fonte | source_domain, source_locator_url, source_dealer_url, source_dealer_id |
| Identità | dealer_name_raw, dealer_name_normalized, brand, manufacturer |
| Indirizzo | street_address, address_locality, address_region, postal_code, address_country |
| Contatto | phone_raw, phone_normalized, website |
| Localizzazione | latitude, longitude |
| Attributi commerciali | services, products, categories, authorized_status_raw |
| Osservazione | observed_at, first_seen, last_seen, record_status |
| Controllo modifiche | source_hash, change_hash, parser_version |
PostalAddress di Schema.org offre una base utile per la nomenclatura di indirizzo, località, regione, CAP e Paese. Nei dati normalizzati, è preferibile usare i codici Paese ISO a due lettere, mantenendo però il Paese esattamente come pubblicato dalla fonte.
Tieni i campi grezzi e quelli normalizzati affiancati. Se un sito riporta St. John's, NL e il livello di normalizzazione produce una provincia e un prefisso telefonico standardizzati, entrambe le versioni devono restare disponibili per la revisione.
Passo 2: costruire un registro delle fonti
Il registro delle fonti è il piano di controllo dell’intera operazione. Assegna a ogni sito una riga con:
- Dominio e brand
- Paese o mercato
- URL del locator presunto
- Famiglia del pattern del locator
- Modalità di crawl preferita
- Versione del parser o del template
- Frequenza di esecuzione
- Responsabile business
- Ultimo tentativo, ultimo successo, ultimo run vuoto e ultimo run fallito
- Note su input di ricerca o requisiti di interazione
Non aspettare di aver capito ogni locator. Crea prima il registro e lascia che la classificazione migliori durante il pilot.
Come individuare le fonti dei locator
Controlla:
- Navigazione principale e link nel footer come “Trova un dealer”, “Dove acquistare” o “Store locator”
/sitemap.xmle gli indici sitemap- Ricerca interna del sito
- Query sui motori di ricerca come
site:brand.example dealer locator - Sorgente della pagina e dati strutturati incorporati
- Richieste di rete attivate da una ricerca nel locator
- PDF o documenti dei distributori come fonte di fallback
Il protocollo Sitemap richiede un URL <loc> per ogni voce della sitemap e supporta gli indici sitemap. Le sitemap possono velocizzare la discovery, ma non garantiscono che ogni risultato dinamico del locator sia incluso; inoltre, un valore <lastmod> non va considerato prova che le informazioni sui dealer siano aggiornate.
Passo 3: classificare ogni locator prima di scalare
La maggior parte dei siti dealer rientra in un piccolo insieme di famiglie di pattern:
- Elenco o tabella HTML statica — il caso più semplice; i record sono presenti nel sorgente della pagina.
- Directory paginata o infinite scroll — i record si ripetono ma richiedono navigazione.
- Card su mappa con link ai dettagli — le card riassuntive necessitano di arricchimento tramite sottopagine.
- Form di ricerca — l’utente deve inserire Paese, stato, città o CAP.
- JSON incorporato o risposta di rete — la pagina è una shell visiva attorno a dati strutturati.
- Elenco minimale più pagine dettaglio dealer — l’elenco contiene l’identità, mentre indirizzi e servizi stanno nelle sottopagine.
- Directory in PDF o documento — estrazione e revisione dei cambiamenti richiedono un percorso dedicato al documento.
Uno scraper universale non può gestire bene centinaia di siti diversi. L’approccio scalabile è costruire un workflow riutilizzabile per ogni famiglia di pattern e poi applicare la configurazione per singola fonte.
Passo 4: pilotare il workflow browser con Thunderbit
Thunderbit è utile per verificare lo schema su siti rappresentativi prima di investire nell’automazione su larga scala.
Procedura di pilot
- Apri una directory dealer rappresentativa in Chrome.
- Avvia Thunderbit e usa AI Suggest Fields.
- Rinomina i campi proposti in modo che corrispondano allo schema canonico.
- Aggiungi Field AI Prompts per normalizzazione o classificazione—for example, mappa il nome del Paese visibile a un codice ISO oppure classifica i servizi in un set di categorie approvato.
- Abilita la gestione della paginazione o dell’infinite scroll per le pagine elenco.
- Usa lo scraping delle sottopagine quando le pagine singole dei dealer contengono telefoni, siti web, servizi o ID sorgente.
- Esporta un piccolo campione in Sheets o Excel e valida ogni URL sorgente.
La modalità browser è particolarmente utile quando un locator richiede interazione, una sessione autenticata o un rendering che una semplice richiesta non riesce a riprodurre. Usa solo fonti e account a cui l’organizzazione è autorizzata ad accedere.
Scegli siti rappresentativi, non i più facili
Il primo pilot dovrebbe includere 20 siti che coprano i principali pattern, aree geografiche e tecnologie delle pagine. Se tutte le fonti del pilot sono semplici tabelle statiche, il workflow sembrerà perfetto finché non arriverà il primo locator basato su mappa.
Per ogni famiglia di pattern, valida almeno:
- Un esempio pulito
- Un esempio di grandi dimensioni
- Un esempio dinamico o irregolare
- Un sito con pagine dettaglio dealer
- Un sito con campi scarsi o opzionali
Passo 5: scalare le fonti stabili con la Batch Extract API
Per pagine pubbliche ripetibili, sposta i job stabili dall’operatività manuale nel browser alla Thunderbit Web Scraper API.
L’endpoint Batch Extract accetta fino a 50 URL in una sola richiesta con un unico JSON Schema. Restituisce un job ID, elabora gli URL in parallelo, supporta errori per singolo URL, può inviare notifiche webhook e offre opzioni renderMode come none, basic e full.
Progettazione del batch
- Raggruppa gli URL che condividono lo stesso schema di output semantico.
- Mantieni i batch entro il limite di 50 URL per richiesta.
- Scegli la modalità di rendering più leggera che espone i dati in modo affidabile.
- Salva job ID e versione del parser insieme al run.
- Registra per ogni URL lo stato di successo, vuoto o errore, non solo uno stato unico per tutto il batch.
- Riprova solo gli URL falliti.
- Conserva i valori grezzi estratti e i link alla fonte prima della normalizzazione.
Uno stesso schema può coprire siti web progettati in modo diverso, purché il significato di business dei campi sia coerente. È questo che consente a una directory statica e a un locator con card su mappa di alimentare lo stesso dealer master.
Passo 6: normalizzare senza cancellare le prove
La normalizzazione rende i record confrontabili; non deve però renderli non verificabili.
Le trasformazioni consigliate includono:
- Eliminare spazi superflui e normalizzare la punteggiatura
- Uniformare maiuscole e minuscole mantenendo
dealer_name_raw - Analizzare i numeri di telefono con un contesto esplicito del Paese
- Mappare nomi di Paese e regione su codici approvati
- Separare o unire i componenti dell’indirizzo in modo coerente
- Normalizzare gli URL e rimuovere, quando opportuno, i parametri di tracking
- Mappare i servizi in testo libero in categorie controllate, mantenendo la frase originale della fonte
Non sovrascrivere la label di autorizzazione della fonte. Se un produttore scrive “Authorized Dealer” e un altro “Certified Reseller”, salva la frase esatta e, facoltativamente, aggiungi una categoria normalizzata in un campo separato.
Passo 7: risolvere i dealer tra brand e fonti diverse
Il solo matching sul nome del dealer non basta. “Smith Auto”, “Smith Automotive” e “Smith Auto LLC” potrebbero essere un’unica azienda — oppure tre aziende in città vicine.
Usa una chiave candidata composita come:
nome normalizzato + CAP + telefono
oppure, quando sono disponibili le coordinate:
nome normalizzato + distanza geospaziale + numero civico
Poi assegna un punteggio alle prove:
- Nome normalizzato identico o quasi identico
- Numero di telefono identico
- Stesso CAP
- Indirizzo simile
- Coordinate entro un raggio ridotto
- Dominio del sito corrispondente
Crea una tabella di mapping fonte-to-canonico invece di collassare subito i record. Più produttori possono puntare allo stesso dealer fisico, mantenendo però appartenenze a brand, servizi e label di stato separate.
Passo 8: rilevare i cambiamenti significativi
Ogni run deve essere un’osservazione, non una sovrascrittura distruttiva.
Salva:
observed_atper il run correntefirst_seenquando il record della fonte appare per la prima voltalast_seenper l’osservazione riuscita più recente- Un hash della fonte per il record grezzo
- Un hash di cambiamento per i campi business normalizzati
Tipi di cambiamento utili includono:
- Dealer aggiunto
- Dealer mancante
- Cambio di nome, indirizzo, telefono o sito web
- Cambio dello stato di autorizzazione
- Cambio di servizio o categoria prodotto
- Spostamento della sede
- Fallimento della pagina sorgente o drift del layout
Un record mancante deve prima diventare missing_pending_review. Conferma la rimozione solo dopo assenza ripetuta o revisione manuale. Un crawl fallito, una risposta vuota o un selettore rotto non sono prova che un dealer abbia chiuso.
Passo 9: aggiungere Google Places come validazione opzionale
Google Places Place Details può arricchire o validare un record dealer con un place ID stabile, nome visualizzato, indirizzo formattato, coordinate, telefono, sito web, stato dell’attività e informazioni sul trasferimento di sede, a seconda del field mask e dello SKU richiesti.
Usalo come segnale secondario, non come autorità per stabilire se una sede appartiene al programma dealer di un produttore. La fonte del produttore resta l’autorità per quella membership. Salva il provider di validazione e il timestamp e non sovrascrivere silenziosamente lo stato del produttore.
Passo 10: misurare la qualità dell’estrazione per pattern e fonte
Monitora la qualità a livello di run, pattern e dominio.
Metriche per singolo run
- URL delle fonti registrate
- URL tentati
- URL riusciti, vuoti e falliti
- Record estratti
- Record aggiunti, modificati, mancanti e invariati
- Completezza dei campi core
- Numero di candidati duplicati
- Rimozioni sospette in attesa di revisione
- Incidenti di schema drift
Validazione su campione
Per ogni famiglia di pattern e per ogni run importante:
- Confronta 20–50 record campionati con le rispettive pagine sorgente.
- Verifica il numero di URL atteso rispetto ai conteggi di tentativo e successo.
- Esamina i campi core mancanti per dominio.
- Ispeziona i cluster di duplicati e i match entità a bassa confidenza.
- Controlla outlier di coordinate e incongruenze Paese/CAP.
- Rivaluta un campione di rimozioni apparenti.
- Registra la versione dell’extractor o del template utilizzato.
L’obiettivo non è una percentuale globale unica di “accuratezza”. È sapere quali pattern e fonti sono affidabili, quali campi sono deboli e dove concentrare l’attività di revisione.
Passo 11: instradare i cambiamenti nei workflow di business
Cambiamenti diversi meritano destinazioni diverse:
- Nuovo dealer: indirizza alle sales operations per creazione CRM, ownership e assegnazione territoriale.
- Sede rimossa o chiusa: invia a una coda di revisione prima di cambiare lo stato dell’account.
- Cambio di indirizzo o telefono: aggiorna l’enrichment e verifica opportunità aperte o copertura di servizio.
- Cambio di autorizzazione: avvisa il channel management e i team a contatto con i clienti.
- Gap di copertura: alimenta la pianificazione territoriale e il recruiting dei partner.
- Espansione del concorrente: aggiorna la business intelligence di distribuzione e la strategia regionale.
- Fallimento ripetuto della fonte: invia alla coda data operations, non al team sales.
Ogni notifica dovrebbe includere il dealer canonico, l’appartenenza al brand, il tipo di cambiamento, i valori prima/dopo, l’URL sorgente, il momento dell’osservazione e il livello di confidenza o lo stato di revisione.
Piano di rilascio 30/60/90 giorni
Giorni 1–30: progettare e validare
- Definire lo schema canonico e le categorie controllate.
- Costruire il registro delle fonti.
- Classificare 20 siti rappresentativi.
- Verificare 3–5 famiglie di pattern di locator.
- Stabilire le regole di sample validation e le metriche di run.
- Consegnare un dealer master iniziale con prove di fonte.
Giorni 31–60: espandere e automatizzare
- Estendere la classificazione all’intero portfolio.
- Spostare i gruppi di URL pubblici stabili all’extraction batch.
- Aggiungere pianificazioni, tracking dei job, logica di retry e dashboard errori.
- Introdurre il mapping da fonte a entità canonica.
- Collegare aggiunte e aggiornamenti revisionati ai workflow CRM.
Giorni 61–90: rendere operativo il change intelligence
- Aggiungere alert e code di revisione specifici per tipo di cambiamento.
- Introdurre prima rilevazione, ultima rilevazione e conferma di rimozione.
- Aggiungere, dove migliora l’affidabilità dell’indirizzo, la validazione opzionale di Places.
- Definire obiettivi di servizio a livello di run.
- Rivedere mensilmente le prestazioni di pattern e template.
- Assegnare un owner a ogni famiglia di fonti e a ogni azione di business.
Errori comuni
Creare uno scraper per ogni sito. Questo genera centinaia di percorsi di manutenzione. Classifica le famiglie di pattern e separa la logica riutilizzabile dalla configurazione specifica della fonte.
Deduplicare solo sul nome del dealer. I nomi sono incoerenti e spesso riutilizzati. Abbina indirizzo, CAP, telefono, coordinate ed evidenze del sito.
Sovrascrivere i valori grezzi. Gli errori di normalizzazione diventano impossibili da auditare quando la rappresentazione originale viene persa.
Trattare un output vuoto come zero dealer. Un output vuoto può indicare un’interazione fallita, un cambio di rendering o una richiesta bloccata. Tieni separati lo stato di salute del crawl e lo stato di business.
Dichiarare una rimozione dopo un solo mancato rilevamento. Richiedi assenza ripetuta o verifica manuale.
Usare un provider map come autorità sui dealer. I dati cartografici possono validare un luogo, ma non confermare il rapporto di autorizzazione di un produttore.
Scalare prima di misurare la qualità dei pattern. Un piccolo errore di estrazione diventa un grande problema operativo quando viene moltiplicato per centinaia di siti.
FAQ
Uno schema unico può funzionare su centinaia di siti dealer diversi?
Sì. I layout delle pagine cambiano, ma i campi semantici — nome dealer, indirizzo, telefono, sito web, brand, servizi, URL sorgente e stato — sono in gran parte coerenti. Usa pattern di estrazione diversi per popolare uno schema canonico unico.
Come si automatizzano le pagine locator che richiedono una ricerca per CAP?
Tratta il form di ricerca come una famiglia di pattern a sé. Definisci una griglia di copertura degli input, cattura gli ID o gli URL dei risultati, deduplica le aree di ricerca sovrapposte e conserva l’input che ha generato ogni risultato per il debugging.
Con quale frequenza vanno aggiornate le sedi dealer?
Allinea la frequenza all’uso di business e al comportamento della fonte. Le fonti competitive o di copertura servizio ad alto valore possono essere eseguite settimanalmente; directory manufacturer più lente possono essere aggiornate mensilmente. I fallimenti di run devono attivare una revisione operativa indipendentemente dalla frequenza di cambiamento dei dealer.
Come fa il sistema a distinguere un dealer rimosso da uno scrape fallito?
Traccia separatamente lo stato della fonte e la presenza del record. Un crawl fallito o vuoto non aggiorna lo stato di ultima rilevazione del dealer. Solo i run riusciti possono fornire evidenza di assenza, e la rimozione deve richiedere ripetizione o revisione.
Google Places dovrebbe sostituire indirizzo e stato di business del sito?
No. Usa Places per enrichment o validazione, salva timestamp e provider e conserva il locator del produttore come autorità per la membership nel programma dealer.
Il monitoraggio automatizzato dei dealer funziona quando viene trattato come un prodotto dati: un registro delle fonti governato, famiglie di pattern riutilizzabili, evidenze preservate, entity resolution prudente e workflow di cambiamento gestiti dal business. Questa architettura può crescere da 20 siti pilota a centinaia senza trasformare ogni redesign in una ricostruzione d’emergenza.
Scopri di più
