My Geocode

指南

对 CRM 导出的地址进行批量地理编码

· 阅读约 3 分钟 · My Geocode · #forward-geocoding#crm#batch#customer-data

CRM 导出文件通常是一个扁平的客户记录文件，其中只有一个地址字段，没有任何其他与位置相关的内容，没有坐标，也没有经过验证的地址组成部分。要把它变成可以在地图上展示或按地区细分的数据，就需要对整个导出文件进行地理编码。

准备导出文件

从 CRM 导出文件中提取地址列，作为一个普通数组，并按位置让客户 ID 与每个地址保持对应，因为之后您需要将结果匹配回各条记录。

POST /v1/forward
Content-Type: application/json

["1600 Pennsylvania Avenue, Washington", "221B Baker Street, London"]
{
  "status": "ok",
  "results": [
    {"formatted": "1600 Pennsylvania Avenue NW, Washington, DC 20500", "lat": 38.8977, "lon": -77.0365, "type": "address", "precision": "house", "confidence": 0.97, "place_id": "def456", "components": {}},
    {"formatted": "221B Baker Street, London, UK", "lat": 51.5237, "lon": -0.1585, "type": "address", "precision": "house", "confidence": 0.95, "place_id": "abc123", "components": {}}
  ]
}

将结果写回 CRM

根据发送请求前记录的位置，将每个结果匹配到对应的客户，然后根据您的 CRM 支持的方式，通过其自身的 API 或批量导入，将坐标和地址组成部分写回 CRM。同时保存 confidence 和 precision 字段，这样匹配较弱的记录就可以被标记出来等待清理，而不是被当作已验证的数据。

第二个示例：国际化的客户群

对于客户分布在多个国家的 CRM，在发送每个地区的批次时同时传入 countries 参数会很有帮助，它能将候选匹配限定在预期的国家内，减少在多个国家都常见的街道名称被解析到错误国家的少见情况。在发送之前将导出文件按国家拆分成多个批次，每个批次作为单独的批量请求发送，是应用这一做法的合理方式，而无需改变工作流程的其他任何部分。

需要避免的常见错误

如果没有另外保存一份指向原始客户 ID 的映射，请不要在发送前对地址数组去重或重新排序。结果按您发送的数组顺序返回，一旦这个顺序在没有保存索引的情况下与客户记录脱钩，之后就没有可靠的方法将一组坐标匹配回正确的客户。请在任务运行期间，将位置到 ID 的映射保存在内存中或一个临时列中。

只对新记录重新运行

初始导出文件完成地理编码后，之后就无需再重新处理整个客户群。记录哪些记录已经有了坐标，在后续运行中只将新记录或地址已更新的记录发送到端点，让持续的请求用量与新增活动成正比，而不是与客户总数成正比。

处理解析效果不佳的记录

置信度分数较低或缺少若干预期组成部分的记录，值得在审核队列中标记出来，而不是悄悄地与完全验证过的记录写在一起。这样可以防止一个错误地址悄无声息地污染基于回填数据生成的地区报告或地图视图。

成本是多少

对现有 CRM 进行一次性回填，每条带地址的客户记录消耗一个请求，可以作为一次批量调用或几个分块运行。一个拥有几千名客户的 CRM 一次运行可能会超过每天 2,500 次免费请求，这时比较合理的做法是把任务分散到几天内完成，或者为这次一次性处理改用预付额度。

回填完成后，为新客户进行的持续地理编码量小而稳定，而不是反复出现的批量任务。完整的请求和响应结构请参阅正向地理编码文档。

更多指南

· 阅读约 4 分钟

将地址与其邮政编码交叉核对

分别解析街道地址和邮政编码，并比较它们实际指向的位置，在订单发货前发现两者不匹配的情况。