Дедупликация данных о магазинах из Google Maps: Place ID не является постоянным идентификатором бизнеса

Для дедупликации данных о магазинах из Google Maps мало проверить совпадение названий или предположить, что у одной сущности всегда один Place ID. Google поясняет, что у одного места могут быть разные ID и что ID со временем меняются. Для долгосрочных списков магазинов надёжнее вести собственные внутренние идентификаторы бизнес-сущностей и управлять их сопоставлением с внешними идентификаторами мест.

Эта проблема поднималась в вопросе на Stack Overflow https://stackoverflow.com/questions/29751398/geocoding-google-maps-api-return-different-place-id: Sergey Kuznetsov отправил запрос с одним ID места и получил в ответе другой ID. Старые ответы помогают понять проблему, но не доказывают, что старые ID остаются действительными навсегда. Статья основана на официальной документации по состоянию на 2026 год.

Речь идёт о распознавании сущностей и качестве данных, а не о массовом сборе данных о магазинах и не о функциях автоматического объединения в EveryInfra. Описанные способы учёта в первую очередь рассчитаны на собственные записи о магазинах и данные, которые вы вправе обрабатывать.

Place ID меняются: почему их всё равно стоит хранить

В документации Google по Place ID сказано, что ID идентифицируют места, но у одного места может быть несколько ID, и ID могут меняться. Документация рекомендует обновлять ID, сохранённые более 12 месяцев назад, и поясняет, что устаревшие ID могут возвращать NOT_FOUND. API поиска мест Google Maps от EveryInfra возвращает place_id для каждого результата. Храните его как внешний идентификатор, как описано в этой статье, а не как бизнес-ключ.

Это не значит, что Place ID бесполезны. Как внешние идентификаторы объектов они лучше общих названий вроде «кофейня» или «центральный филиал». Важно лишь не возлагать на внешние идентификаторы весь бизнес-смысл напрямую.

Например, если сетевой магазин переехал с угла улицы в соседний торговый центр, бизнес может по-прежнему считать его тем же действующим филиалом, хотя местоположение изменилось. И наоборот, два филиала с одинаковым названием бренда не следует объединять, если это разные торговые точки, расположенные в разных местах. Прежде чем задавать правила дедупликации, определите, что представляет запись в вашей таблице: «бренд», «действующий филиал» или «физическое местоположение».

Сведение этих трёх уровней в один store_id поначалу экономит время, но со временем искажает количество магазинов, привязку отзывов и исторические тренды. Изменение внешнего ID может быть ошибочно принято за открытие нового магазина, а нормализация названий может схлопнуть два разных филиала в одну строку.

Сначала заведите основную бизнес-запись, затем ведите сопоставление внешних идентификаторов

Для собственных данных о магазинах присваивайте бизнес-объектам внутренние идентификаторы, не зависящие от сторонних платформ. Внешние платформы, ID мест, время подтверждения и периоды действия храните в записях сопоставления. Описательные поля вроде названий и адресов ведите в соответствии с допустимыми рамками использования и хранения, установленными их источниками.

Для этого не нужна громоздкая система мастер-данных. Небольшой команде достаточно начать с двух списков: в одном — магазины, которыми вы управляете, в другом — текущие внешние идентификаторы каждого магазина. Когда ID меняется, обновляйте сопоставление, а не перестраивайте всю бизнес-историю.

Главное — сохранять причину изменения. Ручное подтверждение того, что новый ID относится к тому же месту, отличается от официальной ссылки о переезде. В обоих случаях может понадобиться связать старую и новую записи, но система не должна считать их простыми событиями «удалены дублирующиеся данные».

Сопоставления также должны быть обратимыми. Если два магазина объединили по ошибке, должна быть возможность проследить обоснование, восстановить принадлежность и пересчитать затронутые сводные показатели, а не гадать по перезаписанной таблице. При этом сохраняются допустимые идентификаторы и журнал операций без копирования всего текста платформы.

Название и близость магазинов — лишь повод для проверки, а не окончательный критерий объединения

Рассмотрим гипотетический пример, не связанный с реальными магазинами: у бренда две точки на первом и четвёртом этажах одного торгового центра с одинаковым названием бренда, основным адресом и близкими координатами. Если автоматически объединить их по совпадению названий и близости, действующих точек окажется меньше, чем есть, а отзывы будут привязаны не к тому месту.

Другой пример — английское и местное названия одного магазина. Разные названия не означают автоматически два разных магазина; решение должно учитывать идентификаторы мест в источнике, собственные данные о магазинах и другие проверенные источники. Сопоставление названий на разных языках помогает находить кандидатов, но не должно определять итоговый вывод.

Рекомендуем разделить решения на три уровня: подтверждать сопоставление при надёжных доказательствах, явно отклонять объединение при противоречивых доказательствах и отправлять записи в очередь на проверку, если названия или местоположения лишь похожи. Неопределённое состояние — не сбой системы, а необходимый шаг, который не даёт сомнительным совпадениям навсегда испортить данные.

Правила отбора кандидатов должны учитывать контекст. Стойки в аэропортах, магазины в торговых центрах и магазины с отдельным входом с улицы по-разному расположены в пространстве, и единого порога расстояния для всех городов и форматов нет. Если пороги основаны на опыте команды, оформите их как внутренние правила, а не выдавайте за рекомендации Google.

Устаревание ID, окончательное закрытие и переезд — разные события

Один лишь NOT_FOUND не доказывает, что магазин закрылся. В документации Google по ID перечислены такие сценарии, как устаревшие ID и обновления базы данных, поэтому прежде чем проверять статус бизнеса, выясните, не нужно ли обновить идентификатор. Ошибки запросов не следует напрямую засчитывать как закрытия магазинов за месяц.

Place Details (New) возвращает businessStatus и поясняет, что в соответствующих случаях результат для переехавшего места указывает на новое место через movedPlace и movedPlaceId. До внедрения проверьте поля запроса, права доступа и условия тарификации; это поля Google, и их наличие в других API данных не гарантировано.

При переезде в бизнес-отчётах нужно решить как минимум два вопроса: сохраняет ли действующий филиал прежний ID и как разделять данные по старому и новому адресам. Сравнивая отзывы до и после переезда, указывайте, от какого объекта места получены отзывы, и не считайте, что всё содержимое старого места перенеслось автоматически.

Даже если бизнес остаётся прежним, могут измениться район, команда обслуживания или формат работы. Если соединить данные до и после переезда в одну линию тренда без пометок, эти изменения скрываются. Лучше сохранять отметки событий, чтобы читатель понимал, что изменилось, прежде чем решать, какие метрики остаются сопоставимыми.

Хранение Place ID не означает возможности долгосрочно хранить все сведения о месте

Документация по политикам Places API описывает требования к кешированию, хранению и указанию авторства контента и отдельно предусматривает исключения для кеширования Place ID. Разрешение хранить идентификаторы не означает, что возвращаемые сведения, такие как отзывы, фотографии и атрибуты, можно копировать бессрочно.

Проектирование должно учитывать различия по полям и целям. Собственные основные записи о магазинах берутся из внутренних процессов; внешние сопоставления мест допускают хранение ID; для показа внешнего контента нужно соблюдать соответствующие условия обновления, хранения и указания авторства. Условия зависят от региона и сценария, и этот текст не заменяет проверку соответствия требованиям для конкретного проекта.

Если ваша задача — анализ отзывов, в руководстве по API отзывов Google Maps разобраны различия между эндпоинтами отзывов. Выбор точек получения данных и дедупликация сущностей — последовательные, но разные шаги: первый определяет, какие данные доступны, второй — к чему они привязываются.

Проверьте ложные объединения на граничных случаях до запуска

Правила дедупликации магазинов не стоит проверять только на том, правильно ли объединяются очевидно одинаковые записи. Больше пользы дают негативные случаи, когда объединения быть не должно, и проверка сценариев восстановления.

Подготовьте четыре группы собственных или синтетических примеров: разные филиалы одного бренда, одно и то же место с названиями на нескольких языках, устаревшие ID без подтверждённого закрытия и переехавшие магазины с новыми ID мест. Убедитесь, что система не объединяет разные филиалы по ошибке, не разделяет сущности только из-за языка, не засчитывает ошибки запросов как закрытия и не стирает события переезда.

При выборочной проверке сводок отдельно указывайте число внешних результатов, число уникальных мест и число магазинов бизнеса. Эти метрики естественно различаются, поэтому не подгоняйте их друг под друга ради отчётов. О том, как неверная привязка данных влияет на бизнес-решения, рассказывается в схеме мультиплатформенного мониторинга репутации.

Главная сложность в управлении данными о магазинах — в каждый момент понимать, какой объект вы сравниваете. Храните внешние ID вместе с периодами действия и доказательствами сопоставления, а непроверенные совпадения оставляйте в ожидании. По мере роста объёма сбора такой подход позволяет наращивать число пригодных записей, не создавая ошибочных связей, которые со временем всё труднее отменить.