Blog · BL-06

Deduplicación de ubicaciones en Google Maps: el Place ID no es una identidad de negocio permanente

Un mismo lugar puede tener múltiples Place ID y los identificadores cambian. A partir de la documentación oficial de Google, se analizan la deduplicación de sucursales, el mapeo de entidades internas, el registro de mudanzas y la validación de falsas fusiones.

Para deduplicar datos de sucursales de Google Maps, no basta con comparar nombres de establecimientos ni asumir que cada entidad mantiene un único Place ID de por vida. Google especifica que una ubicación puede asociarse a distintos ID y que estos varían con el tiempo. En catálogos con mantenimiento a largo plazo, conviene conservar identificadores de entidad propios y registrar por separado la correspondencia con los identificadores externos.

Este caso apareció en una https://stackoverflow.com/questions/29751398/geocoding-google-maps-api-return-different-place-id de Stack Overflow: consultas con un mismo ID de lugar devolvieron identificadores de respuesta diferentes. Dicha referencia ayudó a identificar la casuística, pero no valida la permanencia de los ID antiguos. Este análisis toma como base la documentación oficial vigente a fecha de 2026 de septiembre de 5.

El alcance abarca identificación de entidades y calidad de datos; se excluyen tutoriales de rastreo masivo o declaraciones sobre despliegues automáticos de EveryInfra. Los métodos aplican a catálogos de sucursales propias y datos con permiso de tratamiento.

Por qué conviene conservar los Place ID a pesar de su cambio

La https://developers.google.com/maps/documentation/places/web-service/place-id de Google indica que los ID sirven para identificar ubicaciones, pero un lugar admite varios identificadores y estos cambian. Se recomienda actualizar los ID almacenados durante más de 12 meses y considerar que un identificador obsoleto puede devolver NOT_FOUND.

Esto no resta valor al Place ID: resulta más adecuado como identificador externo que nombres como «cafetería» o «sucursal central». El problema surge al ceder toda la semántica de negocio al identificador externo.

Por ejemplo, si una cadena reubica un local de la esquina al centro comercial contiguo, la entidad de negocio sigue siendo la misma, pero la coordenada física cambia. Inversamente, dos sucursales con idéntica marca no deben fusionarse a nivel operativo ni geográfico. Definir si la tabla registra «marca», «sucursal operativa» o «ubicación física» marca el criterio de deduplicación.

Fusionar estas tres capas en un único store_id ahorra trabajo inmediato, pero distorsiona el recuento de locales, la atribución de reseñas y la serie histórica. Un cambio de ID externo puede interpretarse como apertura nueva y una normalización de nombres puede unificar dos sucursales distintas.

Definir el maestro de negocio antes de mapear identificadores externos

Para sucursales propias, asigna un identificador interno independiente de plataformas de terceros. Almacena en la tabla de mapeo plataforma externa, Place ID, fecha de confirmación y rango de validez. Las descripciones como nombre o dirección deben regirse por el alcance de uso y almacenamiento permitido por su fuente.

No hace falta un sistema maestro complejo. Un equipo pequeño puede operar con dos listas: una con las sucursales administradas y otra con los identificadores externos asociados a cada una. Ante cambios de ID, actualiza el mapeo sin reconstruir el histórico completo.

Conserva el motivo del cambio. La confirmación manual de un nuevo ID para el mismo sitio y la asociación oficial por reubicación constituyen evidencias distintas; ambas pueden vincular registros antiguos y nuevos sin etiquetarse genéricamente como borrado de duplicados.

Permite revertir mapeos. Ante una fusión errónea, rastrea el motivo, restaura la atribución y recalcula métricas afectadas en lugar de inferir cambios sobre tablas sobrescritas. Se conservan identificadores y trazas permitidas, no copias íntegras de textos externos.

Usar nombre y distancia solo para filtrado candidato, nunca como decisión de fusión

Caso hipotético sin correspondencia real: un local con dos plantas (piso 1 y 4) del mismo centro comercial comparte marca, dirección principal y proximidad. Aplicar fusión automática por nombre y cercanía reduce erróneamente un punto de venta y asigna mal las reseñas.

Diferentes idiomas en el nombre de un local tampoco equivalen de forma automática a dos tiendas; requiere validar identificador de origen, ficha propia y fuentes autorizadas. El cruce multilingüe ayuda a proponer candidatos, pero no constituye la conclusión definitiva.

Clasifica los emparejamientos en tres niveles: confirmar mapeo con evidencia plena, rechazar con conflicto claro y derivar a revisión manual ante coincidencia parcial. El estado pendiente evita convertir coincidencias dudosas en contaminación de datos.

Ajusta las reglas de candidatos por entorno. Aeropuertos, centros comerciales y locales a pie de calle poseen dinámicas espaciales distintas; no existe un umbral de distancia universal. Etiqueta los umbrales basados en experiencia interna como regla propia, nunca como recomendación de Google.

Distinguir entre caducidad de ID, cierre definitivo y reubicación

Un NOT_FOUND por sí solo no prueba el cierre de un local. La documentación de ID de Google detalla obsolescencia de identificadores y actualizaciones de base de datos; verifica la necesidad de refrescar el ID antes de asumir estado operativo negativo o sumar fallos a métricas de cierre.

Place Details (New) aporta businessStatus e indica reubicaciones mediante movedPlace y movedPlaceId hacia la nueva ubicación. Revisa campos solicitados, permisos y modelo de costes antes de implementar; dichos campos pertenecen a Google y no garantizan disponibilidad en otras API.

Ante una reubicación, define si la sucursal mantiene el identificador interno y cómo segmentar datos pre y posmudanza. Al comparar reseñas entre periodos, especifica qué objeto de lugar aporta los comentarios; no des por sentado que el contenido anterior migra de forma automática.

Cambios de zona, equipo o formato de operación alteran la comparabilidad. Unir series temporales de reubicación sin anotación oculta variaciones operativas. Incluye notas de evento para contextualizar qué métricas conservan comparabilidad.

Conservar el Place ID no autoriza la retención indefinida de todo el detalle

La https://developers.google.com/maps/documentation/places/web-service/policies de Places API regula caché, almacenamiento y atribución de visualización, con excepciones acotadas para el Place ID. Permitir guardar el identificador no convierte reseñas, fotos o detalles devueltos en material de libre duplicación.

Segmenta por campo y finalidad: el maestro interno proviene de datos de operación propios; la tabla externa almacena los ID permitidos; los contenidos de terceros aplican actualización, almacenamiento y atribución según contrato. Valida condiciones por región y caso de uso.

Para análisis de reseñas, la https://everyinfra.com/build/google-maps-reviews-api de guías de reseñas de Google Maps diferencia puntos de acceso. Seleccionar vía de ingesta y deduplicar entidades son decisiones independientes: la primera define qué datos obtienes, la segunda a quién se asignan.

Validar fusiones erróneas con contraejemplos antes de producción

Una regla de deduplicación de sucursales debe probarse no solo con registros idénticos fusionables, sino con casos no fusionables y escenarios de recuperación ante errores.

Prepara cuatro muestras propias o sintéticas: misma marca y sucursales distintas; mismo lugar con nombres en idiomas distintos; ID obsoleto sin cierre confirmado; local reubicado con nuevo ID. Comprueba que el sistema no una sucursales, no separe entidades solo por idioma, no interprete errores como cierres ni diluya eventos de mudanza.

Audita la agregación diferenciando recuento de resultados externos, de lugares únicos y de sucursales de negocio. Divergencias naturales no deben forzarse en reportes. La https://everyinfra.com/build/multiplatform-reputation-monitoring de monitorización multicanal profundiza en el impacto de una atribución errónea en decisiones de negocio.

La complejidad real de los datos de sucursales radica en mantener la trazabilidad del objeto comparado. Conserva ID externos junto a vigencia y evidencia; mantén en estado pendiente las coincidencias sin soporte suficiente. El crecimiento de la ingesta aportará registros útiles en lugar de acoplamientos erróneos difíciles de revertir.