Google Maps 门店数据怎么去重：Place ID 不是永久业务身份

Google Maps 门店数据去重，不能只判断店名是否相同，也不能假设一个实体永远只有一个 Place ID。Google 明确说明，同一地点可能有不同的 ID，ID 也可能随时间变化。对长期维护的门店清单，更稳妥的做法是保留自己的业务实体编号，再管理它与外部地点标识之间的对应关系。

这个问题在 Stack Overflow 的历史问答里出现过：Sergey Kuznetsov 用一个地点 ID 查询，却得到不同的响应 ID。旧回答帮助识别了问题，但不能据此认定旧 ID 永久有效。本文以截至 2026 年 9 月 5 日的官方文档为事实基础。

这里讨论的是实体识别和数据质量，不是全量门店抓取教程，也不是 EveryInfra 已部署自动合并功能的声明。文中的记录方法首先面向自有门店资料及有权处理的数据。

Place ID 会变，为什么仍然值得保留

Google 的 Place ID 文档说明，ID 用于识别地点，但同一地点可能有多个 ID，而且 ID 可能变化。文档建议刷新保存超过 12 个月的 ID，并解释过时 ID 可能返回 NOT_FOUND。

这不意味着 Place ID 没有价值。相反，它比“咖啡店”“中央店”这类名称更适合作为外部对象的标识。问题在于，不应让外部标识直接承担所有业务含义。

例如，连锁品牌把一家店从街角搬到隔壁商场，业务上可能仍视为同一家经营门店，地点上却发生了变化。反过来，两家分店使用完全相同的品牌名称，业务和地点都不应该被合并。先定义你的表在记录“品牌”“经营门店”还是“物理地点”，才能决定去重规则。

把这三层混成一个 store_id，短期看省事，长期会让门店数量、评论归属和历史趋势一起出错。一个外部 ID 变动可能被误记成新开店，一次名称规范化也可能把两家分店压成一行。

先有业务主档，再维护外部标识映射

对于自有门店，可以先给业务对象一个不依赖第三方平台的内部编号。外部平台、地点 ID、对应关系确认时间及有效区间放在映射记录中。名称、地址等描述信息的维护，则分别遵守其来源允许的使用与存储范围。

这不是要求建立庞大的主数据系统。一个小团队也可以先用两张清单：第一张说明自己在管理哪些门店，第二张说明每家门店当前对应哪些外部标识。遇到 ID 变化时，修改映射关系，不必重建全部业务历史。

关键是保留变化原因。人工确认是同一地点的新 ID，与官方返回了搬迁关联，是不同证据。它们可能都需要关联旧、新记录，却不应该被系统写成同一种“重复数据已删除”。

映射还应能撤销。如果两家门店被误合并，应能找到依据、恢复归属并重算受影响的汇总，而不是只能从一张已经覆盖原值的表里猜发生过什么。这里保留的是允许保存的标识和操作记录，不是要求复制全部平台正文。

店名和距离只能筛候选，不能单独决定合并

以下是假设案例，不对应任何真实门店。一个品牌在同一商场的一楼和四楼各有营业点：品牌名一致、地址主体一致、坐标可能很近。如果按“同名且相距很近”自动合并，就会少算一个营业点，也可能把评论分配错。

另一个例子是同一门店的中英文名称。名称不同并不自动意味着两家店；应结合来源地点标识、门店自己的资料及其他有权核对的信息判断。跨语言名称匹配可以帮助找到候选，但不要直接承担最终结论。

我们建议把判断分成三档：证据充分时确认映射；证据冲突时明确拒绝合并；只有名称或位置相似时进入待核对清单。未知状态不是系统失败，而是避免把可疑匹配变成永久数据污染的必要步骤。

候选规则也应按场景调整。机场柜台、购物中心、街边门店的空间关系不同，不存在一个适用于所有城市和业态的固定距离阈值。阈值若来自团队经验，就标明是自己的规则，不能包装成 Google 官方建议。

ID 失效、永久关闭与搬迁，不是一件事

NOT_FOUND 本身不足以证明门店已关闭。Google 的 ID 文档列出了 ID 过时和数据库更新等情形，所以应先检查标识是否需要刷新，再核对业务状态。不能把一次查询失败直接计入“本月关店数量”。

Place Details (New) 提供 businessStatus，并说明在适用的搬迁结果里，可通过 movedPlace 和 movedPlaceId 指向新地点。实际使用前仍要核对请求字段、权限和计费范围；这些是 Google 的字段，不代表另一套数据 API 必然返回它们。

如果发现搬迁，业务报告至少要决定两件事：经营门店是否延续原编号，旧址与新址的数据怎样分段展示。比较“搬迁前后的评论”时，还要说明可用评论来自哪个地点对象，不能默认旧地点全部内容已自动迁移。

即使业务上仍是同一家店，区位、服务团队或营业形态也可能变化。把迁址前后的数据直接连成一条没有标记的趋势线，会掩盖这种变化。更好的展示是保留事件注释，让读者知道发生了什么，再决定哪些指标具有可比性。

地点 ID 可保存，不等于全部详情都能长期留存

Places API 的政策说明对内容缓存、存储与展示署名设有要求，并单独说明 Place ID 的缓存例外。不能因为标识允许保存，就把评论、照片、详情等所有返回内容都视为可无限复制的资料。

设计时应按字段和用途区分。自有门店主档来自自己的经营资料；外部地点映射记录允许保存的 ID；需要展示外部内容时，再按相应条款处理更新、存储和署名。不同地区及具体使用场景可能有不同条件，本文不替代对实际项目的核对。

如果你的任务主要是分析评论，站内 Google Maps 评论 API 指南先区分了不同评论入口。选入口与实体去重是两个连续但独立的决定：前者决定能得到什么，后者决定把数据归到谁身上。

上线前，用反例检查误合并

一套门店去重规则，不能只测试“明显相同的两条记录能否合并”。更有价值的是测试不该合并的情况，以及后来发现错误能否恢复。

建议准备四组自有或合成样本：同品牌不同分店；同地点不同语言名称；旧 ID 失效但尚未确认关店；门店迁址后出现新地点 ID。分别确认系统不会误合并分店、不会仅按语言拆分实体、不会把失败算作关闭，也不会抹平搬迁事件。

然后抽查一次汇总：外部结果条数、唯一地点数、业务门店数应分别命名。它们本来就可能不同，不应为了让报表对得上而强行消除差异。站内多平台口碑监控蓝图进一步讨论了错误归属如何影响业务判断。

门店数据真正难的部分，是持续知道自己在比较哪个对象。保留外部 ID，也保留它的有效时间与对应依据；对缺少证据的匹配保持待定。这样，采集规模增加时，增长的是可用记录，而不是越来越难撤销的错误关联。