Database di attività locali: come pulire, deduplicare e importare i dati nel CRM

Tempo di lettura: 11 minPubblicato il 23 settembre 2026A cura di BitHubSettore eCommerce

Raccogliere un elenco di attività locali è la parte facile. Il lavoro vero comincia quando quell'elenco deve entrare in un CRM senza riempirlo di doppioni, sedi confuse con aziende e contatti di cui nessuno ricorda la provenienza.

Succede spesso: si fanno alcune ricerche per zona, si esporta un CSV, lo si importa nel CRM. Dopo qualche settimana il commerciale trova la stessa azienda tre volte, con tre numeri diversi, e non sa quale sia quello giusto. Un altro collega ha già chiamato la sede sbagliata. Il report dice che ci sono 400 aziende in lista, ma quelle reali sono 310.

In questo articolo vediamo come trasformare un export di attività locali, per esempio quello prodotto dal nostro Local Business Finder, in un database pulito e utilizzabile: normalizzazione, regole di deduplica, struttura dei campi, import controllato e manutenzione nel tempo.

In breve

• Un export non è un database: prima di importarlo va normalizzato.
• La deduplica si fa con chiavi affidabili (ID sorgente, dominio, telefono), non solo con il nome.
• Azienda, sede e contatto sono tre cose diverse e vanno tenute separate.
• Ogni record deve portarsi dietro fonte, data di raccolta e data di verifica.
• L'import passa da una tabella di staging e da una prova, non direttamente dal CSV al CRM.
• Trovare un contatto non autorizza automaticamente a usarlo per marketing.

Perché un export non è ancora un database

Un CSV esportato da uno strumento di ricerca descrive quello che la ricerca ha trovato in quel momento. Un CRM invece deve descrivere le aziende con cui lavori o potresti lavorare, in modo stabile e condiviso da più persone.

Fra le due cose ci sono differenze concrete:

• lo stesso nome scritto in modi diversi ("Bar Centrale", "BAR CENTRALE SNC", "Bar Centrale di Rossi");
• telefoni con e senza prefisso internazionale, spazi, trattini;
• siti web con e senza www, http o percorsi interni;
• indirizzi abbreviati ("V. Roma", "Via Roma", "via roma snc");
• la stessa attività trovata in due ricerche su aree confinanti;
• catene e franchising con molte sedi che sembrano aziende diverse;
• campi vuoti che non significano "non esiste", ma "non disponibile nella fonte".

Se questi problemi entrano nel CRM, si moltiplicano: automazioni che partono due volte, commerciali che si pestano i piedi, report gonfiati.

Passo 1: normalizzare i campi

Normalizzare significa portare ogni campo a una forma standard, così che due valori che indicano la stessa cosa diventino identici. Il valore originale va conservato in una colonna a parte: serve per controlli e per capire cosa è stato modificato.

Un altro dettaglio: siti, telefoni ed email possono essere più di uno per la stessa attività. Nell'export arrivano spesso nello stesso campo; prima dell'import vanno separati, scegliendo quale valore è il principale e conservando gli altri come secondari.

Attenzione ai domini "non aziendali": se il campo sito contiene una pagina social, una piattaforma di prenotazione o un portale di annunci, il dominio non identifica l'azienda. Quei valori vanno spostati in un campo "profili" e non usati come chiave di deduplica.

Passo 2: decidere cosa significa "duplicato"

Il nome da solo è la chiave peggiore: ci sono decine di "Pizzeria Da Mario" in Italia, e la stessa pizzeria può comparire con tre nomi diversi. Conviene lavorare per livelli di affidabilità.

Corrispondenza certa

• stesso identificativo della fonte;
• stesso dominio aziendale e stesso telefono normalizzato;
• stessa partita IVA, quando il dato è disponibile e verificato.

Corrispondenza probabile

• stesso telefono ma nome leggermente diverso;
• nome molto simile e coordinate a poche decine di metri;
• stesso dominio ma indirizzi diversi (spesso è un'azienda con più sedi, non un doppione).

Da verificare

• nome simile nello stesso comune ma nessun altro dato in comune;
• stesso indirizzo ma categorie diverse (un centro commerciale, un palazzo di uffici).

La regola pratica è semplice: unire in automatico solo le corrispondenze certe. Le probabili vanno in una coda di revisione con i due record affiancati. Un duplicato si elimina in un minuto; due aziende diverse fuse per errore, con lo storico delle attività mescolato, richiedono ore per essere separate.

Per i nomi simili si usano misure di somiglianza tra stringhe (per esempio Jaro-Winkler o distanza di Levenshtein) dopo aver tolto forme giuridiche e parole generiche come "bar", "ristorante", "studio". Per la vicinanza si confrontano le coordinate con una soglia in metri. Nessuna delle due misure, da sola, basta a decidere.

Passo 3: separare aziende, sedi e contatti

Molti CRM nascono con un'unica scheda "azienda". Con i dati territoriali questo crea confusione, perché la ricerca per zona trova luoghi, non società.

Una struttura più robusta prevede tre livelli:

• Azienda: il soggetto con cui eventualmente lavori, identificato da dominio, partita IVA o nome normalizzato.
• Sede: il punto fisico trovato dalla ricerca, con indirizzo, coordinate, telefono e orari propri.
• Contatto: la persona o il recapito, quando esiste e quando è lecito conservarlo.

Con questa separazione una catena di dieci negozi diventa un'azienda con dieci sedi, non dieci aziende. E i conteggi per zona restano corretti, perché si contano le sedi.

Passo 4: conservare fonte, data e stato di verifica

Il campo che quasi tutti dimenticano è quello che risponde alla domanda "da dove arriva questo dato e quanto è vecchio?". Senza, dopo sei mesi nessuno sa se un telefono è stato controllato o se è rimasto quello dell'export iniziale.

Per ogni record conviene salvare almeno:

• fonte (strumento, ricerca, inserimento manuale, form del sito);
• ID nella fonte, per riconoscere il record ai futuri aggiornamenti;
• data di raccolta;
• data e autore dell'ultima verifica;
• stato: da verificare, verificato, non pertinente, chiuso, duplicato unito a…;
• valore originale dei campi normalizzati.

Questi campi servono anche per un motivo meno tecnico: se qualcuno chiede da dove hai preso i suoi dati, devi saperlo rispondere.

Passo 5: importare con uno staging, non direttamente

L'errore più costoso è importare il CSV direttamente nel CRM di produzione. Un flusso più sicuro è questo:

1. Staging: il file va in una tabella intermedia, fuori dal CRM.
2. Normalizzazione e deduplica interna al file.
3. Confronto con il CRM esistente: ogni record viene marcato come nuovo, aggiornamento di un record esistente o possibile duplicato.
4. Prova di import (dry run): si genera un riepilogo — quanti record nuovi, quanti aggiornati, quanti in revisione — senza scrivere nulla.
5. Revisione umana dei casi dubbi.
6. Import vero in modalità upsert: si crea il record se non esiste, lo si aggiorna se esiste, usando l'ID sorgente o la chiave certa.
7. Log di ogni operazione, per poter annullare un lotto se qualcosa va storto.

Una regola importante nell'aggiornamento: il dato verificato a mano vince sul dato importato. Se un commerciale ha corretto un telefono, il prossimo import non deve sovrascriverlo con quello vecchio della fonte.

È lo stesso principio che applichiamo alle integrazioni fra negozio online e gestionale, descritto nell'articolo su eCommerce, gestionale, API e magazzino: ID univoci, log, regole chiare su chi è la fonte autorevole di ogni campo.

Un esempio pratico: 480 record, 352 sedi, 318 aziende

Immagina di aver raccolto le palestre e i centri fitness di una provincia facendo dodici ricerche su aree confinanti. L'export contiene 480 righe.

• La deduplica per ID sorgente elimina 96 righe comparse in più ricerche: restano 384.
• Il confronto su dominio e telefono trova altri 21 doppioni certi: restano 363.
• La coda di revisione propone 27 coppie probabili; 11 sono davvero lo stesso posto: restano 352 sedi.
• Raggruppando per dominio aziendale, 352 sedi corrispondono a 318 aziende, perché alcune catene hanno più palestre.
• Il confronto con il CRM esistente mostra che 41 aziende erano già presenti: diventano aggiornamenti, non nuovi record.

Senza questi passaggi, nel CRM sarebbero entrati 480 "clienti potenziali". Con questi passaggi entrano 277 aziende nuove, 41 aggiornamenti e un elenco chiaro dei casi da controllare.

Checklist prima di importare

• Le colonne del file sono mappate sui campi del CRM, con nomi e formati concordati.
• Telefoni, domini, email e indirizzi sono normalizzati; gli originali sono conservati.
• I domini di social, portali e piattaforme di prenotazione non sono usati come chiave.
• Le regole di corrispondenza certa, probabile e da verificare sono scritte.
• Aziende e sedi sono separate.
• Ogni record ha fonte, ID sorgente, data di raccolta e stato.
• È stata fatta una prova di import con riepilogo.
• I campi verificati a mano sono protetti dalla sovrascrittura.
• C'è un log che permette di annullare il lotto.
• È stato deciso chi può usare i contatti, per quali finalità e con quali regole.

Cosa chiedere a chi ti prepara l'import

• Quale campo usate come chiave per riconoscere un'azienda già presente?
• Cosa succede se due record hanno lo stesso telefono ma nome diverso?
• Le sedi di una stessa azienda restano separate o vengono fuse?
• Un nuovo import può sovrascrivere un dato corretto a mano?
• Possiamo vedere il riepilogo prima che i dati entrino nel CRM?
• Se l'import va male, come si torna indietro?
• Dove è registrata la provenienza di ogni record?

Se le risposte sono vaghe, il rischio è importare in fretta e passare mesi a ripulire.

Mantenere il database pulito nel tempo

Un database di attività locali invecchia in fretta: attività che chiudono, cambiano nome, sede o telefono. Qualche abitudine aiuta:

• ripetere periodicamente la ricerca sulle stesse aree e confrontare per ID sorgente, per trovare novità e chiusure;
• segnalare i record non verificati da troppo tempo;
• far passare anche gli inserimenti manuali dalle stesse regole di deduplica;
• tenere uno stato "chiuso" invece di cancellare, così lo storico resta coerente.

Uso dei contatti: raccogliere non significa poter contattare

Un database ben fatto rende anche più semplice rispettare le regole, ma non le sostituisce. Se nei record ci sono dati riferiti a persone fisiche — il nome di un titolare, un'email nominativa, un cellulare — si applica il GDPR: serve una base giuridica, un'informativa (l'articolo 14 riguarda proprio i dati non raccolti presso l'interessato) e la possibilità di opporsi al marketing diretto.

Il legittimo interesse non è automatico: va valutato caso per caso, come spiegano le linee guida EDPB 1/2024 sull'articolo 6(1)(f). Per email, SMS e telefonate commerciali valgono inoltre regole specifiche sulle comunicazioni elettroniche e, in Italia, il Registro pubblico delle opposizioni. Per questo nel CRM conviene registrare la finalità per cui un contatto può essere usato e gestire le opposizioni in un campo che nessun import può sovrascrivere.

Non è una consulenza legale: per campagne vere e proprie è bene confrontarsi con chi segue la privacy dell'azienda. Sul lato tecnico, consenso e tracciamenti li trattiamo nella pagina sulla web compliance GDPR e cookie.

Come lo gestiamo in BitHub

Il Local Business Finder già deduplica i risultati all'interno della sessione e nell'export include per ogni record un identificativo, la fonte e un indice di confidenza: l'import parte quindi con meno rumore e con una chiave utile per gli aggiornamenti. Come spiegato nell'articolo su come trovare attività locali senza scraper, però, la ricerca è solo il primo passo.

Quando il database deve diventare parte di un processo commerciale, progettiamo il resto: tabella di staging, regole di normalizzazione, coda di revisione dei duplicati, import via API verso il CRM, log e sincronizzazioni periodiche. Se il CRM deve dialogare anche con sito, eCommerce o gestionale, lo integriamo come parte di un'unica architettura, come descritto nelle pagine sulle piattaforme CRM ed ERP e sull'eCommerce integrato con il gestionale.

Lo stesso rigore sui dati serve poi a valle: le liste pulite sono la base di segmenti affidabili, come raccontiamo nell'articolo sulle newsletter con segmenti dinamici e CRM.

FAQ

Qual è il modo più affidabile per riconoscere un duplicato?

Un identificativo stabile della fonte, quando esiste. In sua assenza funzionano bene dominio del sito e telefono normalizzato. Nome e indirizzo simili servono per segnalare possibili duplicati, non per unirli in automatico.

Conviene unire i duplicati in automatico?

Solo quando la corrispondenza è certa, per esempio stesso ID sorgente o stesso dominio e stesso telefono. I casi probabili vanno in una coda di revisione: un'unione sbagliata è molto più difficile da correggere di un duplicato.

Come si gestiscono aziende con più sedi?

Separando l'azienda dalle sedi. L'azienda ha un solo record, ogni punto vendita o filiale è una sede collegata con il proprio indirizzo, telefono e coordinate.

Si può importare direttamente il CSV nel CRM?

Tecnicamente sì, ma è sconsigliato. Meglio passare da una tabella di staging dove normalizzare, deduplicare e fare una prova di import, poi caricare nel CRM solo i record approvati.

Avere l'email di un'azienda significa poterle scrivere per marketing?

No. Trovare un dato e usarlo per comunicazioni commerciali sono passaggi diversi, con regole diverse. Serve valutare base giuridica, informativa, diritto di opposizione e le norme sulle comunicazioni elettroniche applicabili al caso.

Hai un CRM pieno di doppioni o un export da importare?

Possiamo analizzare i tuoi dati, definire le regole di deduplica e costruire un import ripetibile verso il tuo CRM, collegato se serve a sito, eCommerce e gestionale.

Parliamo del tuo database