电子商务结帐地址验证

目标

从客户订单中获取准确的地址对于电子商务至关重要，因为这有助于确保商品成功送达，提高准时送达率，并减少快递地址更正费用。

本文档介绍了在电子商务结账过程中使用 Address Validation API 的最佳做法，包括何时静默接受良好地址、与客户确认地址验证响应，或将客户返回到地址输入表单进行手动更正。

Google Maps Platform 已提供一个教程，介绍如何使用地点自动补全服务改进结账体验。本文扩展了该教程的内容，添加了 Address Validation API 的新功能，该 API 旨在识别地址输入错误，从而帮助您提高可送达率并使结账功能更强大。

什么是地址验证？

地址验证（也称为地址验证）流程旨在确定输入的街道和邮政地址是否存在，且具有可送达的质量。

为什么在结账时需要验证地址？

如果在结账时没有发现地址错误，可能会导致严重的送货问题。 结账屏幕上的地址验证可以帮助您确信客户输入的送货地址是有效的。进而减少失败和错误交付，给企业带来很高的成本。

借助地点自动补全服务和 Address Validation API，用户可以在结账时快速轻松地正确输入数据。导致 Address Validation API 成为结账流程重要组成部分的一些常见场景如下：

错别字

客户在输入地址时很容易输错，尤其是在移动设备上。例如，输入纽约作为布鲁克林地址的市行政区。

电话订单

电话订购者很容易误解地址或捕捉到部分地址信息。这进而会导致订单配送花费额外的时间或完全失败。

购买礼物

用户经常将产品作为礼物送给亲朋好友，而他们可能不知道地址是 100% 确定的。在此类情况下，Address Validation API 有助于为输入的地址有效提供额外的置信度。

客户需要其他地址元数据

包裹发货方或快递公司通常需要额外的信息才能完成送货，例如住宅与商业建筑类型或 USPS DPV 值（仅限美国）。

因配送公司不同而产生的差异

与小型快递公司相比，本地邮政服务通常更了解特定街区的情况。因此，即使缺少公寓编号或当地地标，一些运输公司（例如邮局）或许也能递送包裹，而其他运输公司可能会无法配送。

如果快递公司不了解送货区域的本地信息，则他们掌握的信息越多，就越有助于确保成功交付。Address Validation API 建议的更正有助于快递公司确认包裹是否可送达。

实现 Address Validation API

在客户输入地址后，无论是通过地点自动补全还是手动输入的地址，都可以将输入的地址数据发送到 Address Validation API。

建议在点击地址表单上的“下一步/继续”按钮时调用 Address Validation API，很有可能转到付款处理页面。

在结账过程中使用 Address Validation API 的端到端流程如下所示：

图片

现在，我们来详细了解每个步骤。

第 1 步：地址输入流程 - 使用地点自动补全服务

地点自动补全服务应在地址输入表单的第一行实现，以便在客户输入地址详情时为其提供建议。

自动补全功能可以简化您应用中的地址输入操作，从而提高转化率并为客户提供顺畅的使用体验。它提供了单个带有“提前输入”地址预测功能的快速输入字段，可用于自动填充结算或送货地址表单。

将自动补全功能添加到您的在线购物车后，您可以实现以下目的：

  • 大大减少下单所需的键盘操作和总时间。
  • 减少地址输入错误。
  • 减少放弃购物车的情况。
  • 简化移动设备或穿戴式设备上的地址输入体验。

此处提供了一些流屏幕在此阶段的显示效果示例。

图片

第 2 步：使用 Address Validation API 验证地址

我们建议您在结账时调用 Address Validation API，确认地址有效且完整。

但是，如果由于某种原因未在默认流程中调用 Address Validation API，建议至少在以下情况下调用它：

  1. 客户使用了浏览器自动填充功能，而不是自动补全。
  2. 客户忽略了自动补全输入。
  3. 已使用自动补全功能，但返回的地址已修改。
  4. 您正在处理一笔高价值交易，因此成功交付尤为重要。
  5. 出于法律原因，您需要存储消费者地址。

第 3 步：提供视觉确认

用户输入地址之后，通过一个简单的静态地图为用户提供确认送货地点的直观信息。此地图可进一步确保地址正确无误，并可减少送货/自提失败。
地图可以显示在客户输入地址的页面上，甚至可以在客户完成交易后发送到确认电子邮件中。这两个用例均可通过以下 API 实现：

Maps JavaScript API 提供了一个用于显示用户位置的交互式地图。 Maps Static API 允许在网页中或后续阶段嵌入图片。

深入探究 - 地址接受场景

Address Validation API 的响应可以定义三种主要场景。用于检查地址质量的响应中的各个组成部分会突出显示，本文档前面的流程图针对上述场景提供了总体的建议流程。

场景 1：有效地址

如果 API 返回信号表明输入的地址质量良好，则结账流程可以进入下一阶段，而无需向客户发出任何通知。
表明地址质量优异的信号如下：

  • addressComplete 标记是 true，
  • PREMISE 或 SUB_PREMISE, 上的验证 Granularity，以及
  • 所有地址组成部分均未标记为：
    • inferred
    • spellCorrected
    • replaced
    • unexpected

我们建议从 Address Validation API 中获取建议的地址数据，因为该地址数据可能包含细微的更正和补充，例如：

  • 大写字母
  • 格式更正，例如
    • 通往大街的街道
    • 地址组成部分的正确顺序
  • ZIP+4。

下面的示例展示了如何在验证流程中使用此反馈：

REQUEST 反应 
  "address": {
    "regionCode": "US",
    "locality": "Mountain View",
    "addressLines": ["1600 Amphitheatre Pkwy"]
  }
 
"verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "PREMISE",
      "geocodeGranularity": "PREMISE",
      "addressComplete": true,
      "hasInferredComponents": true
    } …
"addressComponents": [
        {
          "componentName": {
            "text": "1600",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Amphitheatre Parkway",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Mountain View",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED"
        }

场景 2：有问题的地址

Address Validation API 可能会指示地址发生了有意义的更改，通常通过在单个字段中添加 inferred、spellCorrected 或 replaced，应向客户确认返回的地址。为此，您可以使用弹出模式（提供用于选择输入的地址的选项）或 API 提供的建议选项。
  • 当 Address Validation API 找到地址匹配项（类似于地点自动补全响应的“候选匹配”）时，它会在响应时使用概率最高的一个地址，并标记所有经过更正的组成部分（Address Validation API 响应："spellCorrected": true）。例如：
"1600 amphiteatre parkway" 与 "1600 Amphitheatre Parkway, Mountain View, CA 94043-1351, USA" 匹配
下面的示例说明了如何在验证流程中使用此反馈：
REQUEST 反应 
  "address": {
    "regionCode": "US",
    "addressLines": ["1600 amphiteatre parkway"]
  }
 
      "verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "PREMISE",
      "geocodeGranularity": "PREMISE",
      "addressComplete": true,
      "hasInferredComponents": true
    } …
      "address": {
      "formattedAddress": "1600 Amphitheatre Parkway, Mountain View, CA 94043-1351, USA",
      …
      "addressComponents": [
        {
          "componentName": {
            "text": "1600",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Amphitheatre Parkway",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "CONFIRMED",
          "spellCorrected": true
        }
...
{ "componentName": {
            "text": "Mountain View",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED",
          "inferred": true
        }
注意：路线缺少“h”，缺少市行政区名称（山景城）

情形 3：地址无效

如果 Address Validation API 返回的响应指明地址无效，客户应重定向到地址输入表单以检查其输入的数据。 当 Address Validation API 无法找到地址的匹配候选对象时，它会对地址的各个组成部分进行限定，并标记数据缺失/无效，以便标记需要添加或更正的字段。
下面的示例说明了如何在验证流程中使用此反馈：
REQUEST 反应 
  "address": {
    "regionCode": "US",
    "addressLines": ["123 fake street new york"]
  }

"verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "ROUTE",
      "geocodeGranularity": "ROUTE",
      "hasUnconfirmedComponents": true,
      "hasInferredComponents": true
    } …
"addressComponents": [...
       {"componentName": {
            "text": "123",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
        },
        { "componentName": {
            "text": "fake street",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
        },
        {"componentName": {
            "text": "New York",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED"
        } …

上述逻辑可以在结账流程中实现，具体如以下流程图所示：

图片

进一步提升结账体验的技巧

请务必避免客户因输入的地址无效而无法结账。如果 API 始终指示客户的条目是无效地址，则相应逻辑的构建方式不应使客户进入无限循环。

我们建议客户最多提供两次输入地址的机会，第二次尝试时，即使未通过验证，也应接受其参评申请。这可以通过以下方式实现：在系统显示包含 API 建议的弹出模态窗口时，允许客户“强制继续”；或者静默接受地址输入的第二次尝试（即使地址未完全验证）。未完全验证的地址输入可以在产品发货之前，由客户服务部门标记以进行下游手动审核。

例如，新结构就是如此重要的原因。新建筑物的施工完成与将其地址填充到邮政地址数据库中之间可能存在时间差。客户应该能够通过输入的地址（可能尚未经过验证）强制进入结账页。

您可以选择使用 Address Validation API 的 provideValidationFeedback 方法向 Google 提供有关特定验证尝试的反馈。点击此处可了解详情。

如果符合 Address Validation API 服务专用条款，则地址可显示于界面中或缓存在数据库中。如果地址缓存在数据库中，我们需要确保：

  • 只能针对用户缓存地址。
  • 设置了格式的地址和大多数其他属性只能在征得用户同意后才能缓存。

您会发现，某些自动补全和/或 Address Validation API 响应不完整或不完整。根据您的地理位置和具体的业务需求，我们建议实现业务逻辑，在决定是否接受 Address Validation API 无法确认的地址时较为宽松。

例如，如果您在美国境内，可以选择在 Address Validation API 响应中启用美国邮政服务®1 的 CASSTM，从而提供每个地址的详细程度信息。

许多客户喜欢通过辅助流程重新验证地址，例如：

  • 法规原因迫使客户保证要缓存的确切地址。
  • 如果用于验证地址的初始调用失败，请离线重新验证地址。

我们提供大容量地址验证作为开源软件工具，用于在批处理中实现地址重新验证。

总结

Address Validation API 是一款功能强大的工具，可提升所有电子商务平台的结账体验。详细了解 Address Validation API 并在此处试用。

后续步骤

下载利用可靠地址改善结账、配送和运营 白皮书，并查看利用地址验证改进结账、配送和运营 在线讲座。

建议深入阅读：

贡献者

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

  1. 美国邮政服务的非独家被许可人。以下商标归美国邮政服务®所有，经许可后使用：CASSTM、USPS®、DPV®。↩