本文档介绍了多种实际应用场景,在这些场景中,地址验证 API 会针对可能需要系统执行确认行为的地址提供响应信号。如需了解相关背景信息,请参阅构建验证逻辑中的工作流示例。
常见示例:确认
以下示例展示了街道名称相似的大都市区的情况。假设用户打算输入美国华盛顿州柯克兰 Google D 大楼的地址。不过,他们不小心输入了 Seattle,而不是 Kirkland 作为城市。
输入的地址 | 区域 |
---|---|
Building D, 451 7th Avenue South, Seattle, WA 98033 | 美国 |
替换数据的判决
以下示例重点展示了响应中的重要信号。
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true,
"possibleNextAction": "CONFIRM"
}
possibleNextAction
初步表明可能需要向客户确认地址。判决中的其他信号会提供有关地址可能存在的问题的更多详细信息。PREMISE_PROXIMITY
表示建筑物级地址的近似程度,但不如 SUB_PREMISE
详细,后者是输入时提供的粒度。
响应还包含未确认和已替换的组件。
对地址组成部分的查询显示了以下问题:
{
"componentName": {
"text": "451",
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
"componentName": {
"text": "98104",
},
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
}
...
{
"componentName": {
"text": "Building D",
"language_code": "en"
},
"componentType": "subpremise",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......
"unconfirmedComponentTypes": [
"street_number",
"subpremise"
]
在这种情况下,地址验证 API 在西雅图找到了与所提供地址非常接近的地址,并替换了邮政编码(一个更高级别的组成部分),以解析为西雅图地址。这可能是一个有效的替换项,但考虑到组件未经确认,因此有必要确保用户打算输入的是西雅图地址,而不是其他地址(例如柯克兰)。
边缘情况示例:确认
以下示例展示了以下边缘情况类型:
- 已确认的次要推理。 地址验证 API 会推断国家/地区、邮政编码或州/省,但其他所有信息都已提供并确认。粒度和确认级别的组合使得推理结果不一定需要确认操作。
- 意外的地址组成部分未确认。 未确认的地址组成部分会增加地址的风险等级。这可能需要确认。
- 已确认的意外地址组成部分。 此组成部分并非有效地址的必需组成部分,Address Validation API 会将其从输出中移除。格式问题通常不需要确认。
已确认的次要推理
如果输入仅缺少以下类型的一个组成部分,该 API 在与更精细级别的已确认数据结合使用时,仍可做出正确的推理:
- 城市
- 州
- 邮编
- 国家/地区
例如,某位客户提供了马萨诸塞州斯普林菲尔德一家麦当劳餐厅的有效街道地址,但忘记输入城市,并提供了一个没有 4 位数扩展码的邮政编码。
输入的地址 | 区域 |
---|---|
1402 Allen St, MA 01118 | 美国 |
针对缺少城市的判决
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true,
"possibleNextAction": "CONFIRM"
}
在 Address Validation API 推断出更高级别的地址组成部分以生成可投递的地址时,您可以更放心地相信系统提供的数据是正确的。这是因为,代表广阔地理区域的推断出的组成部分更容易与更精细的已确认地址组成部分相匹配。即使在城市名称重复的国家/地区(例如美国的斯普林菲尔德),与其他组成部分组合在一起也能提供唯一的地址。
以上面的示例为例,对所有地址组成部分的扫描显示,每个组成部分都已确认,这意味着它与 Address Validation API 存储的数据相匹配,并且该服务还推断出两个更高级别的组成部分。
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
意外的地址组成部分未确认
此场景说明了在组件未确认时进行检查的重要性。如果某个地址组成部分出乎意料,Address Validation API 会将其从输出中移除。在这种情况下,您可以接受该地址,也可以根据您的风险级别和信心级别与客户重新确认该地址。
例如,某个地址可能来自客户经常输入无害信息(邮政机关会忽略这些信息)的地区,在这种情况下,您会接受该地址。不过,在某些情况下,未确认的组件可能不是客户想要的。
输入的地址 | 区域 |
---|---|
59 Cherrydown Avenue, Chingford, London E4 8DT | 英国 |
未确认意外地址组成部分的判决
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true,
"possibleNextAction": "ACCEPT"
}
除了包含未确认组成部分的判决结果之外,Address Validation API 还会返回以下格式的地址:
"formattedAddress": "59 Cherrydown Avenue, London E4 8DT, UK",
扫描未确认的组件后发现,该 API 从返回的地址中移除了 Chingford:
{
"componentName": {
"text": "Chingford",
"languageCode": "en"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
已确认的意外地址组成部分
此示例展示了在提供的地址中包含英国郡的做法,这是一种常见做法。不过,英国邮政局并未要求这样做,因此基本上会忽略此信息。请参阅 postoffice.co.uk 和如何填写英国和国际邮件的地址。
因此,当客户在英国地址中提供郡时,该服务会将其评估为意外输入。
输入的地址 | 区域 |
---|---|
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | 英国 |
已确认的意外地址组成部分的判决
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"possibleNextAction": "ACCEPT"
}
在此示例中,address_complete
的计算结果为 false,对地址组件的分析显示了一个意外的标志。
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
虽然格洛斯特郡是所输入地址的正确县,但地址本身的格式不正确。请注意,Address Validation API 还会评估信息是否符合正确的格式。