使用 Address Validation API 处理大量地址

目标

作为开发者，您经常使用包含客户地址的数据集 可能质量欠佳。您需要确保 从客户 ID 验证到送货等等。

地址验证 API是 可用于验证地址的 Google Maps Platform。不过，只有 一次处理一个地址。在本文档中，我们将介绍如何使用 不同场景下的大量地址验证（来自 API 测试） 到一次性和周期性地址验证

使用场景

现在，我们将了解大量地址验证 实用。

测试

您通常希望通过运行数千个 地址。您可能在逗号分隔值文件中包含了地址， 以验证地址的质量。

一次性验证地址

在开始使用 Address Validation API 时，您需要验证自己的 根据用户数据库共享现有地址数据库。

定期验证地址

在很多情况下，您需要定期验证地址：

  • 您可能已安排了任务来验证地址，以便查看捕获的详细信息 例如，从客户注册、订单详情到送货 时间表。
  • 您可能会收到包含来自不同部门、 例如从销售到营销接收 地址通常都希望在使用前对其进行验证。
  • 您可能会在问卷调查期间或各种推广活动及后续活动中收集地址 。您想要验证地址是否 正确。

技术层面的深入探讨

在本文档中，我们假设：

  • 您使用客户提供的地址调用 Address Validation API 数据库（即包含客户详细信息的数据库）
  • 您可以针对数据库中的各个地址缓存有效性标志。
  • 验证有效性标志时，系统会通过 Address Validation API 检索 单个客户登录
。 <ph type="x-smartling-placeholder">

用于生产环境的缓存

在使用 Address Validation API 时，您通常希望缓存 响应。虽然我们的 服务限额 可缓存哪些数据、可通过 Address Validation API 缓存的所有数据 必须针对用户账号进行缓存。这意味着在数据库中， 地址或地址元数据必须缓存到用户的电子邮件地址或 其他主要 ID。

对于大批量地址验证用例，数据缓存必须遵循 Address Validation API 服务专用 条款， 如第 11.3 节所述。根据这些信息，您将能够： 确定用户的地址是否无效，在这种情况下，您需要 在用户下一次与您的产品互动时，向其提供更正后的地址。 应用。

  • 来自 AddressComponent 的数据 对象
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

如果您想缓存有关实际地址的任何信息，那么从这些数据 只有在征得用户同意后才能缓存。这可以确保用户 特定服务存储其地址的原因，并且可以使用 共享其地址的条款。

例如，与电子商务地址直接互动就表示用户同意 表单。因此，您要了解 出于运送包裹的目的而处理地址。

征得用户同意后，您可以缓存 formattedAddress 和其他关键组件 。然而，在无头场景中，用户无法提供 同意，因为地址验证是从后端进行的。因此， 在这种无头场景中，您可以缓存非常有限的信息。

了解响应

如果 Address Validation API 响应包含以下标记，则您 可以确信输入地址具有可送达质量：

  • Verdict 中的 addressComplete 标记 对象为 true，
  • 判定中的 validationGranularity 对象为 PREMISE 或 SUB_PREMISE
  • 没有任何 AddressComponent 标记为：
    • Inferred（请注意，: inferred=true在以下情况下可能会发生 addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected和
  • confirmationLevel： 确认级别 AddressComponent 设置为CONFIRMED或UNCONFIRMED_BUT_PLAUSIBLE

如果 API 响应不包含上述标记，则输入地址 因此您可以在数据库中缓存标志 。缓存标记表示整个地址质量较差，而 “拼写更正”等更详细的标记会指明 解决质量问题。当客户下次与带有被标记的地址互动时 您可以使用现有的 地址。Address Validation API 会返回您更正的地址 可以使用界面提示进行显示在客户接受格式化的地址后 您可以从响应中缓存以下内容：

  • formattedAddress
  • postalAddress
  • addressComponent componentNames 或
  • UspsData standardizedAddress

实现无头地址验证

根据上述讨论：

  • 通常有必要缓存地址 用于业务用途的验证 API。
  • 不过， 服务 Google Maps Platform 会限制哪些数据可以缓存。

在下一部分中，我们将讨论通过两个步骤来遵循 并实施大量地址验证。

第 1 步：

首先，我们将探讨如何实现高流量的地址。 验证脚本。通过此流程，您可以 将 Address Validation API 响应中的特定字段存储为 服务合规。

图 A：下图显示了如何增强数据流水线 具有大量地址验证逻辑。

alt_text

根据服务条款的规定，您可以缓存以下数据： addressComponent:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

因此，在这一实现步骤中，我们将缓存上述内容。 与 UserID 相关联

有关详情，请参阅实际数据 结构。

第 2 步：

在第 1 步中，我们收集了反馈，指出输入数据集中的某些地址 质量欠佳。在下一步中，我们将把这些被标记的地址 将代码呈现给用户并征得其同意 地址。

图 B：此图显示了如何进行端到端的用户集成 意见征求流程：

alt_text

  1. 用户登录时，首先检查您是否缓存了任何验证标志 。
  2. 如果存在标记，则应向用户显示一个用于更正和 更新地址。
  3. 您可以使用更新后的或缓存版本再次调用 Address Validation API。 地址，并将更正后的地址显示给用户进行确认。
  4. 如果地址的质量较高，Address Validation API 会返回一个 formattedAddress。
  5. 如果更正了错误，您可以向用户显示该地址 或静默接受（如果没有更正）。
  6. 用户接受后，您可以在数据库中缓存 formattedAddress。
。

总结

大量地址验证是您可能会遇到的一种常见用例 应用场景。本文档将尝试演示一些场景和 如何实现符合 Google Maps 要求的解决方案的设计模式 平台服务条款。

我们进一步编写了大批量地址的参考实现 在 GitHub 上以开源库的形式进行验证。立即查看，开始使用 使用大量地址验证功能快速构建应用。另请访问 如何在不同场景中使用该库的设计模式。

后续步骤

下载使用可靠的地址改进结账、配送和运营 白皮书 并查看通过“地址”页面改善结账、送货和运营 验证 在线讲座。

建议深入阅读：

贡献者

本文由 Google 维护。它最初是由以下贡献者编写的。
主要作者：

Henrik 阀门 |解决方案工程师
Thomas Anglaret |解决方案 工程师
Sarthak Ganguly |解决方案 工程师