Deduplicare i dati dei negozi su Google Maps: il Place ID non è un'identità aziendale permanente

Per deduplicare i dati dei negozi di Google Maps non basta controllare se i nomi coincidono o dare per scontato che un'entità mantenga sempre un solo Place ID. Google chiarisce che lo stesso luogo può avere ID diversi e che gli ID possono cambiare nel tempo. Per gli elenchi di negozi gestiti nel lungo periodo, l'approccio più sicuro è mantenere identificatori interni per le entità aziendali e gestirne la mappatura sugli identificatori di luogo esterni.

Il problema è emerso in una domanda su Stack Overflow https://stackoverflow.com/questions/29751398/geocoding-google-maps-api-return-different-place-id: Sergey Kuznetsov ha fatto una query con un ID di luogo e ha ricevuto nella risposta un ID diverso. Le risposte più vecchie aiutano a inquadrare il problema, ma non dimostrano che i vecchi ID restino validi per sempre. Questo articolo si basa sulla documentazione ufficiale aggiornata al 2026.

Questa discussione riguarda il riconoscimento delle entità e la qualità dei dati, non lo scraping massivo di negozi né un'affermazione su funzionalità di unione automatica di EveryInfra. I metodi di registrazione descritti sono pensati soprattutto per i record dei tuoi negozi e per i dati che sei autorizzato a trattare.

I Place ID cambiano: perché vale comunque la pena conservarli

La documentazione di Google sui Place ID spiega che gli ID identificano i luoghi, ma lo stesso luogo può avere più ID e gli ID possono cambiare. La documentazione consiglia di aggiornare gli ID salvati da più di 12 mesi e spiega che gli ID obsoleti possono restituire NOT_FOUND. L'API di ricerca dei luoghi di Google Maps di EveryInfra restituisce un place_id per ogni risultato. Conservalo come identificatore esterno, come descritto in questo articolo, e non come chiave di business.

Questo non significa che i Place ID siano privi di valore. Al contrario, identificano gli oggetti esterni meglio di nomi generici come "caffetteria" o "filiale centrale". L'importante è non attribuire direttamente agli identificatori esterni tutti i significati aziendali.

Se ad esempio un negozio di una catena si sposta dall'angolo della strada al centro commerciale accanto, l'azienda potrebbe considerarlo ancora lo stesso punto vendita operativo, ma il luogo è cambiato. Al contrario, due filiali con lo stesso nome di brand non vanno unite se attività e luoghi sono diversi. Prima di definire le regole di deduplicazione, stabilisci se la tua tabella registra un "brand", un "punto vendita operativo" o un "luogo fisico".

Riunire questi tre livelli in un unico store_id fa risparmiare tempo all'inizio, ma nel tempo genera errori nel numero di negozi, nell'attribuzione delle recensioni e nei trend storici. Un cambio di ID esterno potrebbe essere registrato per errore come una nuova apertura, e la normalizzazione dei nomi potrebbe fondere due filiali distinte in un'unica riga.

Crea prima un record anagrafico di business, poi gestisci la mappatura degli identificatori esterni

Per i dati dei tuoi negozi, assegna agli oggetti di business identificatori interni che non dipendano da piattaforme di terze parti. Nei record di mappatura salva la piattaforma esterna, gli ID di luogo, la data di conferma e il periodo di validità. Gestisci i campi descrittivi come nomi e indirizzi nel rispetto degli ambiti di utilizzo e conservazione consentiti dalle rispettive fonti.

Non serve costruire un enorme sistema di master data. I team piccoli possono partire da due elenchi: uno con i negozi che gestisci e un altro con gli identificatori esterni attuali di ciascun negozio. Quando un ID cambia, aggiorna la relazione di mappatura invece di ricostruire tutto lo storico di business.

L'importante è conservare il motivo della modifica. Una conferma manuale che un nuovo ID appartiene allo stesso luogo è diversa da un collegamento ufficiale di trasferimento. In entrambi i casi può essere necessario collegare il vecchio e il nuovo record, ma il sistema non deve trattarli come semplici eventi di "dati duplicati eliminati".

Le mappature devono anche essere reversibili. Se due negozi vengono uniti per errore, devi poter ricostruire il ragionamento, ripristinare l'attribuzione e ricalcolare gli aggregati interessati, invece di andare a intuito partendo da una tabella sovrascritta. In questo modo conservi gli identificatori consentiti e i log delle operazioni senza dover copiare tutti i testi della piattaforma.

Nomi e vicinanza dei negozi servono solo a individuare candidati, non sono criteri finali di unione

Considera questo esempio ipotetico, che non corrisponde a negozi reali: un brand gestisce due punti vendita al primo e al quarto piano dello stesso centro commerciale, con lo stesso nome, lo stesso indirizzo principale e coordinate vicine. Unirli automaticamente perché i nomi coincidono e sono vicini porta a sottostimare i punti vendita operativi e ad attribuire male le recensioni.

Un altro esempio riguarda il nome in inglese e quello nella lingua locale dello stesso negozio. Nomi diversi non indicano automaticamente due negozi distinti; la valutazione deve tenere conto degli identificatori di luogo della fonte, dei dati dei tuoi negozi e di altre fonti verificate. Il confronto dei nomi tra lingue diverse aiuta a individuare i candidati, ma non deve determinare la conclusione finale.

Consigliamo di suddividere le decisioni in tre livelli: confermare la mappatura quando le prove sono solide, rifiutare esplicitamente l'unione quando le prove sono in conflitto e inviare gli elementi a una coda di revisione quando nomi o luoghi sono solo simili. Uno stato sconosciuto non è un errore del sistema; è un passaggio necessario per evitare che corrispondenze dubbie inquinino i dati in modo permanente.

Le regole per i candidati devono adattarsi al contesto. Banchi in aeroporto, centri commerciali e negozi su strada hanno relazioni spaziali diverse, e nessuna soglia di distanza vale per tutte le città e tutti i formati. Se le soglie si basano sull'esperienza del team, documentale come regole interne invece di attribuirle a raccomandazioni di Google.

Scadenza degli ID, chiusure definitive e trasferimenti sono eventi distinti

NOT_FOUND da solo non dimostra che un negozio abbia chiuso. La documentazione di Google sugli ID elenca casi come ID obsoleti e aggiornamenti del database, quindi verifica se gli identificatori vanno aggiornati prima di controllare lo stato dell'attività. Le query non riuscite non vanno conteggiate direttamente come chiusure mensili.

Place Details (New) fornisce businessStatus e spiega che, nei casi di trasferimento applicabili, i risultati rimandano al nuovo luogo tramite movedPlace e movedPlaceId. Prima dell'implementazione verifica campi della richiesta, permessi e ambiti di fatturazione; si tratta di campi di Google e non è garantito che siano disponibili in altre API per i dati.

Quando avvengono trasferimenti, i report di business devono chiarire almeno due aspetti: se i punti vendita operativi mantengono gli ID originali e come segmentare i dati del vecchio e del nuovo indirizzo. Quando confronti le recensioni prima e dopo un trasferimento, specifica da quale oggetto relativo al luogo provengono, senza presumere che tutti i contenuti dei vecchi luoghi siano migrati automaticamente.

Anche quando l'attività resta la stessa, possono cambiare il quartiere, il team di servizio o il formato operativo. Collegare i dati di prima e dopo il trasferimento in un'unica linea di tendenza senza annotazioni nasconde questi cambiamenti. Una presentazione migliore conserva le annotazioni degli eventi, così chi legge capisce cosa è cambiato prima di stabilire quali metriche restano confrontabili.

Conservare i Place ID non significa poter archiviare a lungo tutti i dettagli

La documentazione sulle policy della Places API descrive i requisiti per caching, archiviazione e attribuzione dei contenuti, prevedendo eccezioni specifiche per il caching dei Place ID. Il fatto che sia consentito archiviare gli identificatori non implica che i dettagli restituiti, come recensioni, foto e attributi, si possano copiare a tempo indeterminato.

La progettazione deve distinguere per campo e finalità. I record anagrafici dei tuoi negozi nascono dalle operazioni interne; le mappature sui luoghi esterni consentono di archiviare gli ID; mostrare contenuti esterni richiede di rispettare i relativi termini su aggiornamento, archiviazione e attribuzione. Le condizioni variano per area geografica e caso d'uso, e questo testo non sostituisce una verifica di conformità specifica per il progetto.

Se il tuo task riguarda l'analisi delle recensioni, la Guida all'API per le recensioni di Google Maps distingue tra i vari endpoint per le recensioni. Scegliere i punti di acquisizione e deduplicare le entità sono passaggi consecutivi ma distinti: il primo determina quali dati sono disponibili, il secondo a cosa vengono attribuiti.

Prima del rilascio, testa le unioni errate con i casi limite

Le regole di deduplicazione dei negozi non vanno testate solo verificando che record palesemente identici vengano uniti correttamente. È più utile testare i casi negativi, cioè le situazioni che non devono portare a un'unione, e verificare i flussi di ripristino.

Prepara quattro gruppi di campioni propri o sintetici: filiali diverse dello stesso brand, uno stesso luogo con nomi in più lingue, ID scaduti senza conferma della chiusura e negozi trasferiti con un nuovo ID di luogo. Verifica che il sistema non unisca per errore filiali separate, non divida entità solo in base alla lingua, non conteggi le query non riuscite come chiusure e non cancelli gli eventi di trasferimento.

Verifica a campione gli aggregati indicando separatamente il numero di risultati esterni, il numero di luoghi unici e il numero di punti vendita aziendali. Poiché queste metriche sono per natura diverse, non forzare l'allineamento delle discrepanze solo per far quadrare i report. Il Blueprint per il monitoraggio della reputazione multipiattaforma spiega come i dati attribuiti male incidano sulle decisioni di business.

La sfida principale nella gestione dei dati dei negozi è sapere in ogni momento quale oggetto stai confrontando. Conserva gli ID esterni insieme ai periodi di validità e alle prove della mappatura, e lascia in sospeso le corrispondenze non verificate. Man mano che la raccolta cresce, questo approccio aumenta i record utilizzabili invece di generare collegamenti errati sempre più difficili da annullare.