构建验证逻辑

本文档介绍了构建地址检查系统的流程， 处理来自 Address Validation API 的各种响应。其中介绍了如何 建立逻辑以正确使用响应，调查其他信号 以及何时以及如何向客户提示更多信息。

一般来说，API 响应决定了您的系统应该采取的下列方式 处理地址：

  • 修正 - 地址质量不佳。 您应提示您提供更多信息。
  • 确认 - 地址质量较高，但 更改。您可能会提示 确认。
  • 接受 - 地址质量较高。您可以 接受提供的地址。

密钥用途

本文档可帮助您修改系统，以便更好地分析 API 响应和 确定对所提供的地址执行的后续操作。以下 伪代码展示了可能的流。

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

具体逻辑取决于您的具体情况 - 请参阅实现指南 了解详情。您也可以使用此逻辑的开源实现， 它位于扩展组件库中。

工作流程概览

下表总结了针对您的系统的两项操作：

  1. 要使用的工作流程（基于修正、确认和接受行为）。
  2. 从响应中检查的第一个信号。信号 来自 verdict 属性，不是唯一的 但要提供地址的初始指示符 质量。每种行为类型都对应于本文档中的一个章节 来描述您可能还需要调查的更多信号。
您的系统行为
修正地址

verdict 的响应表明重要缺失 应该提供的信息。由 Address Validation API 可能不具有交付质量。

工作流程

  1. 必要时调查地址组成部分。
  2. 提示客户解决地址问题。
  3. 请求验证更新后的地址。
  4. （可选）向 API 的反馈端点发送请求。 请参阅处理更新后的地址。
  5. 输入地址。

判定信号

存在以下任一情况：
确认地址

来自 verdict 的响应表明可以交付 但对原始输入进行了更改： 或者是可以确认的数据。

工作流程

  1. 需要更正： <ph type="x-smartling-placeholder">
      </ph>
    1. 必要时调查地址组成部分。
    2. 请求验证更新后的地址。
    3. （可选）向 API 的反馈端点发送请求。 请参阅处理更新后的地址。
    4. 输入地址。
  2. 无需更正：
    1. （可选）向 API 的反馈端点发送请求。 请参阅处理更新后的地址。
    2. 输入地址。

判定信号

以下所有条件均适用：

  • validationGranularity包含“ROUTE” 或更好。请参阅粒度 值。
  • addressComplete 为 true。
  • “hasInferredComponents”字段为“true” 或 “hasReplacedComponents”字段为“true”。
接受地址

Address Validation API 响应表明地址的质量非常好。

工作流程

继续使用已退回的地址。

判定信号

以下所有条件均适用：

  • validationGranularity包含“PREMISE” 或更好。 请参阅粒度值。
  • addressComplete 为 true。
  • 没有推断的或被替换的组件。

实现方案指导

在设计系统如何响应来自 Address Validation API 的信号时， 以下建议可以帮助您建立更有效的应对 模型。不过，这些只是建议，请注意， 应适合您的业务模式。

指南 详细信息
风险等级

考虑级别 您遇到的情况 更正并接受输入的地址。

Address Validation API 会返回各种信号 您可以将其与风险级别结合起来，以优化验证 过程。

例如，如果某个地址包含未经确认的门牌号，您可以 也仍要接受它另一方面，如果您的业务运营需要 您可以提示用户举个例子， 可能属于上述任一类别，请参阅未经确认的非美国门牌号 （在接受地址 - 示例中）。
接受地址

最好让您的系统接受原始条目 如果客户没有回应提示。

在这些情况下，客户可能输入了 例如对于新搭建的系统
提供反馈

当您重新发送地址验证请求时，您可以 也会向 provideValidationFeedback 端点发送请求。

这样 Google 就可以了解您最终是如何处理最终响应的。 请参阅处理更新后的地址。
<ph type="x-smartling-placeholder">

修正地址

当结果清楚显示某个地址并非 交付。然后，您的系统可以提示用户提供必要的 之后，您需要重新发出工作流程，以获得可交付成果， 地址。

修正信号

Address Validation API 提供了大量信号，可让您了解 地址。

1. 验证粒度和缺失的组件

以下两个信号最准确地说明了有问题的地址：

  • 每当 validationGranularity 字段为 OTHER 时，您的系统都应 调查地址组成部分信号，详细了解错误所在 以及解决方法。
  • 每当后处理的 address 对象返回 missingComponentTypes 字段，系统应检查是否存在该组件。 如果缺少组件，也会导致地址不完整且无法送达。

2. 其他信号

Address Validation API 还提供了其他信号来帮助 诊断具体问题：

可疑组件 当组件的确认级枚举为 UNCOMFIRMED_AND_SUSPICIOUS 时，该组件很可能是 错误。
未解析的组成部分 unresolvedToken 是输入的一部分，但未被识别为地址的有效部分。

3. 美国地址信号

某些仅适用于美国地址的字段提供了有用的信号，表明 地址无法送达，应予以修正。对于要求 您应看到以下内容：

dpvConfirmation 值为 N、D 或为空。

如需详细了解 dpvConfirmation，请参阅 处理美国地址。

修正地址示例

确认地址

当判定结果显示 Address Validation API 时，您确认了某个地址 从而生成 验证过的地址。这种情况下，您会提供一个配送地址，但更希望 生成的地址是 客户。

为了向客户提供正确的提示，您的逻辑将确定 服务标记的组件，用于确定对 API 执行的操作或标记 应用于组件，例如 inferred、replaced 或 spellCorrected。 请参阅参考文档中的 AddressComponent。

确认信号

Address Validation API 提供了大量信号，可让您了解 地址。

1. 验证粒度

接受 ROUTE 或更高的 validationGranularity，但 “PREMISE”或“SUBPREMISE”可提供更强的交付信号。

2. 其他信号

在决定与客户确认输入的地址时，判定结果还会 以下各项可确定要调查的组件：

推断的数据 当 hasInferredComponents 字段为 true 时， 您知道 API 填写了它从其他地址收集的信息 组件。
已替换数据 当 hasReplacedComponents 字段为 true 时， API 将输入的数据替换为其认为使地址有效的数据。

3. 美国地址信号

某些仅适用于美国地址的字段表示您的逻辑应 向客户确认详细信息。可能出现以下任一情况：

dpvConfirmation S

如需详细了解 dpvConfirmation，请参阅 处理美国地址。
地址响应 包含值为“missingComponentType”的字段 subpremise。

确认地址示例

接受地址

如果判定结果高度可信，则表明您接受相应地址。 该地址可送达，并且无需客户进一步互动即可使用 在下游进程中发挥的作用。

接受信号

Address Validation API 提供了大量信号，可让您了解 地址。

1. 验证粒度

可以接受 PREMISE 或更高的 validationGranularity，但在某些 ROUTE 仍然表示可送达地址。

2. 其他信号

优质地址的判定结果还应提供以下内容：

  • 没有已替换的数据。在此示例中为 hasReplacedComponents: FALSE。
  • 没有推断的组成部分。在此示例中为 hasInferredComponents: FALSE。

3. 美国地址信号

某些仅适用于美国地址的字段表示地址质量较高 目标对象要查看可接受的美国地址，您应该看到 以下：

dpvConfirmation Y

如需详细了解 dpvConfirmation，请参阅 处理美国地址。

接受地址示例

上一页
了解基本回复