本文档介绍了构建地址检查系统的流程, 处理来自 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.
具体逻辑取决于您的具体情况 - 请参阅实现指南 了解详情。您也可以使用此逻辑的开源实现, 它位于扩展组件库中。
工作流程概览
下表总结了针对您的系统的两项操作:
- 要使用的工作流程(基于修正、确认和接受行为)。
- 从响应中检查的第一个信号。信号
来自
verdict
属性,不是唯一的 但要提供地址的初始指示符 质量。每种行为类型都对应于本文档中的一个章节 来描述您可能还需要调查的更多信号。
您的系统行为 | |||
---|---|---|---|
修正地址 |
|
||
确认地址 |
来自
|
||
接受地址 |
Address Validation API 响应表明地址的质量非常好。
|
实现方案指导
在设计系统如何响应来自 Address Validation API 的信号时, 以下建议可以帮助您建立更有效的应对 模型。不过,这些只是建议,请注意, 应适合您的业务模式。
指南 | 详细信息 | |
---|---|---|
风险等级 |
考虑级别 您遇到的情况 更正并接受输入的地址。 |
Address Validation API 会返回各种信号 您可以将其与风险级别结合起来,以优化验证 过程。 例如,如果某个地址包含未经确认的门牌号,您可以 也仍要接受它另一方面,如果您的业务运营需要 您可以提示用户举个例子, 可能属于上述任一类别,请参阅未经确认的非美国门牌号 (在接受地址 - 示例中)。 |
接受地址 |
最好让您的系统接受原始条目 如果客户没有回应提示。 |
在这些情况下,客户可能输入了 例如对于新搭建的系统 |
提供反馈 |
当您重新发送地址验证请求时,您可以
也会向 |
这样 Google 就可以了解您最终是如何处理最终响应的。 请参阅处理更新后的地址。 |
修正地址
当结果清楚显示某个地址并非 交付。然后,您的系统可以提示用户提供必要的 之后,您需要重新发出工作流程,以获得可交付成果, 地址。
修正信号
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
如需详细了解 |
---|---|
地址响应 | 包含值为“missingComponentType ”的字段
subpremise 。
|
接受地址
如果判定结果高度可信,则表明您接受相应地址。 该地址可送达,并且无需客户进一步互动即可使用 在下游进程中发挥的作用。
接受信号
Address Validation API 提供了大量信号,可让您了解 地址。
1. 验证粒度
可以接受 PREMISE
或更高的 validationGranularity
,但在某些
ROUTE
仍然表示可送达地址。
2. 其他信号
优质地址的判定结果还应提供以下内容:
- 没有已替换的数据。在此示例中为
hasReplacedComponents: FALSE
。 - 没有推断的组成部分。在此示例中为
hasInferredComponents: FALSE
。
3. 美国地址信号
某些仅适用于美国地址的字段表示地址质量较高 目标对象要查看可接受的美国地址,您应该看到 以下:
dpvConfirmation
|
Y
如需详细了解 |
---|