e コマース チェックアウトの住所検証

目的

e コマースでは、顧客の注文から正確な住所を取得することが不可欠です。これにより、商品を確実に配達し、時間どおりの配送を増やし、配送業者の住所修正料金を削減できます。

このドキュメントでは、正しい住所を暗黙的に受け入れる場合、お客様と一緒に Address Validation レスポンスを確認する場合、手動で修正するために住所入力フォームを返送する場合など、e コマースの購入手続きで Address Validation API を使用する際のベスト プラクティスについて説明します。

Google Maps Platform には、Place Autocomplete サービスを使用して購入手続きを改善する方法に関するチュートリアルがすでに用意されています。このドキュメントでは、Address Validation API の新機能を追加することで、このチュートリアルを拡張します。Address Validation API は、住所入力エラーを特定するように設計されているため、配達の精度を高め、購入手続きをより強力にするのに役立ちます。

住所確認とは

Address Validation(住所確認とも呼ばれます)は、入力された番地や郵便の宛先が存在するかどうかを特定するためのプロセスで、配達可能な品質です。

購入手続き時に住所確認が必要なのはなぜですか?

購入手続きの際に住所に気付かないうちに誤りがあると、配送に関する深刻な問題を引き起こす可能性があります。 購入手続き画面で住所を検証すると、お客様が配送先として入力した住所が正しいことを確認できます。そして、企業にとってコストのかかる配送の失敗やミスが減ります。

Places Autocomplete サービスと Address Validation API を使用すると、ユーザーは購入手続き時に正しいデータをすばやく簡単に入力できます。Address Validation API を購入手続きに不可欠な要素にする一般的なシナリオは次のとおりです。

誤字

特にモバイル デバイスでは、住所の入力ミスがよく発生します。たとえば、ブルックリンの住所の地域区分として「ニューヨーク」を入力します。

電話注文

電話注文を受ける人は、住所を誤解したり、住所の一部を取得したりする可能性があります。その結果、注文の配送に余分な時間がかかったり、完全に失敗したりすることがあります。

ギフトの購入

ユーザーは多くの場合、100% の確信を持って住所がわからない友人や家族への贈り物として商品を購入します。このような場合、Address Validation API は、入力された住所が有効であることの信頼性をさらに高めます。

お客様が追加の住所メタデータを必要としている

多くの場合、荷物の配送業者や配送業者は、住宅と商業施設の建物の種類、USPS DPV 値(米国のみ)など、配送を完了するために追加情報を必要とします。

運送業者の違いによる違い

多くの場合、地域の郵便サービスは小規模な配送業者よりも特定の近隣地域に関する知識が豊富です。そのため、アパートの番号や地域のランドマークがない場合でも、一部の運送業者(郵便局など)は荷物を配達でき、他の運送業者は配達できない可能性があります。

配送業者が配達地域の知識を持っていない場合、より多くの情報を得ることで配達を成功させることができます。Address Validation API が修正を提案すると、配送業者は荷物が配達可能であるという確信が高まります。

Address Validation API の実装

ユーザーが住所を入力すると、Place Autocomplete か手動入力かを問わず、入力された住所データを Address Validation API に送信できます。

Address Validation API を呼び出す推奨時間は、住所フォームの [Next/Continue] ボタンをクリックしたときです。多くの場合、支払い処理のページが表示されます。

購入手続きで Address Validation API を使用するエンドツーエンドのフローは次のようになります。

イメージ

では、各ステップを詳しく見てみましょう。

ステップ 1: 住所入力フロー - Place Autocomplete サービスの使用

住所入力フォームの 1 行目に Place Autocomplete サービスを実装し、ユーザーが住所の詳細を入力する際に候補を表示する必要があります。

オートコンプリートにより、アプリケーションでの住所入力が簡単になり、コンバージョン率の向上とシームレスなユーザー エクスペリエンスにつながります。「予測入力」による住所予測を備えた単一のクイック入力フィールドを提供し、これを使用して請求先住所フォームまたは配送先住所フォームを自動的に入力できます。

オンライン ショッピング カートにオートコンプリートを実装すると、次のことが可能になります。

  • 注文に必要なキー入力と合計時間を大幅に削減できます。
  • 住所の入力ミスが減る
  • カートの放棄を減らす。
  • モバイル デバイスとウェアラブル デバイスでの住所入力が簡単になる

このフェーズでのフロー画面の表示例をいくつか示します。

イメージ

ステップ 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 のレスポンスから定義できる主なシナリオは 3 つあります。住所の品質を確認するためのレスポンス内のコンポーネントがハイライト表示され、このドキュメントの前半のフローチャートには、これらのシナリオで推奨されるフロー全体が示されています。

シナリオ 1: 有効な住所

入力された住所が良質であるというシグナルが API から返された場合は、ユーザーに通知することなく、購入手続きは次のステージに進むことができます。
質の高い住所を示すシグナルは次のとおりです。

  • addressComplete マーカーは true
  • PREMISE または SUB_PREMISE, の validationGranularity、および
  • 次のマークが付けられた住所コンポーネントがない。
    • inferred
    • spellCorrected
    • replaced
    • unexpected

推奨される住所データを Address Validation API から取得することをおすすめします。これには、次のような軽微な修正や追加が含まれる可能性があるためです。

  • 大文字 / 小文字
  • 書式設定の修正。例:
    • 通りから通りへ
    • 住所コンポーネントの正しい順序
  • 米国では ZIP+4 です。

検証プロセスでこのフィードバックを使用する方法の例を以下に示します。

リクエスト 反応
  "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 は、住所に意味のある変更があることを通知できます。通常は個々のフィールドinferredspellCorrected、または replaced を含めることで、返される住所をお客様に確認する必要があります。これを行うには、ポップアップ モーダルを使用し、入力された住所または API による推奨を選択します。
  • Address Validation API は、住所の一致を見つけると(Place Autocomplete レスポンスの「候補一致」と類似)、一致の可能性が最も高い住所を返し、修正されたコンポーネントにフラグを付けます(Address Validation API レスポンス: "spellCorrected": true)。
"1600 amphiteatre parkway""1600 Amphitheatre Parkway, Mountain View, CA 94043-1351, USA" と一致します。
検証プロセスでこのフィードバックを使用する方法の例を以下に示します。
リクエスト 反応
  "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 は、住所の一致候補を見つけられない場合、住所の個々の構成要素を認定し、欠落しているデータまたは無効なデータをマークします。これにより、追加または修正が必要なフィールドにフラグを設定できます。
検証プロセスでこのフィードバックを使用する方法の例を以下に示します。
リクエスト 反応
  "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 がユーザーのエントリが無効な住所であることを一貫して示している場合、ユーザーを無限ループで送るようなロジックを構築しないでください。

住所の入力は 2 回までとし、2 回目の試行では検証できなかった場合でも受け付けることをおすすめします。これを行うには、API 候補のポップアップ モーダルが表示されたときにユーザーに「強制続行」を許可するか、住所が完全に検証されていなくても 2 回目の住所入力を暗黙的に承認します。完全に検証されていない住所入力は、製品の出荷前にカスタマー サービス部門によるダウンストリームの手動審査の対象となる可能性があります。

これが重要な理由の例として、新規構築があります。新しい建物の建設が完了してから、その建物の住所が郵便住所データベースに入力されるまでに時間差が生じる場合があります。顧客は入力された住所を使用して購入手続きページに強制的に進める必要がありますが、まだ確認が完了していない可能性があります。

必要に応じて、Address Validation API の provideValidationFeedback メソッドを使用して、特定の検証の試行に関するフィードバックを Google に送信できます。詳しくはこちらをご覧ください。

Address Validation API サービス固有の規約に準拠していれば、住所は UI に表示されるか、データベースにキャッシュされます。アドレスがデータベースでキャッシュに保存されている場合は、次のことを確認する必要があります。

  • あるユーザーに対してのみ、住所をキャッシュに保存できます。
  • フォーマット済み住所などのほとんどの属性は、ユーザーの同意を得た後にのみキャッシュに保存できます。

Autocomplete API や Address Validation API レスポンスの一部が部分的または不完全である場合があります。地域や特定のビジネスニーズに基づいて、Address Validation API で確認できない住所を受け入れるかどうかを決定するときは、より寛大なビジネス ロジックを実装することをおすすめします。

たとえば、米国にお住まいの場合、Address Validation API レスポンスで United States Postal Service®1CASSTM を有効にすることで、各住所の詳細な情報を取得できます。

多くのお客様は、次のような二次的なプロセスで住所を再検証します。

  • 規制上の理由により、キャッシュされる正確な住所を保証することがお客様に義務付けられています。
  • 住所検証の最初の呼び出しが失敗した場合は、オフラインで住所を再検証します。

Google では、バッチ処理で住所の再検証を実装するためのオープンソース ソフトウェア ツールとして High Volume Address Validation を提供しています。

おわりに

Address Validation API は、あらゆる e コマース プラットフォームの購入手続きを改善する強力なツールです。Address Validation API の詳細と試用については、こちらをご覧ください。

次のステップ

ホワイトペーパー「信頼できる住所で購入手続き、配達、業務を改善 」をダウンロードし、「Address Validation を使用して購入手続き、配達、業務を改善する 」ウェブセミナーをご覧ください。

関連資料:

協力者

Henrik Valve | ソリューション エンジニア
Thomas Anglaret | ソリューション エンジニア
Sarthak Ganguly | ソリューション エンジニア


  1. 米国郵便公社の非独占的なライセンシー米国郵便公社の商標は CASSTM、USPS®、DPV® が所有し、同社の許可を得て使用しています。