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

目的

このドキュメントでは、高品質の住所を取得する目的で、e コマースの購入手続きで Place Autocomplete、Address Validation API1、マップを組み合わせる方法について説明します。

前提条件

以下についてよく理解しておくことをおすすめします。

住所確認とは

Address Validation API は住所を受け付けるサービスです。住所コンポーネントを識別して検証します。また、郵送用の住所を標準化し、その住所に最適な既知の緯度と経度の座標を見つけます。米国とプエルトリコの住所の場合は、Coding Accuracy Support System（CASSTM）を有効にすることもできます。

購入手続き時の住所確認が必要な理由

注文プロセスで正確な住所を収集する:
これは、配達の成功を促進し、予定どおりのフルフィルメントを増やし、コストのかかる住所修正料金を削減するために重要なステップです。

ユーザーが迅速かつ正確に住所を入力できるようにする:
Place Autocomplete を使用すると、住所入力のスピードと入力エラーが減り、ユーザーは購入手続きを簡単に行うことができます。Address Validation は、住所の全体的な品質に関するフィードバックを提供し、標準化やスペルミスなどの修正を行い、住宅または商用インジケーター（一部のリージョンで利用可能）を提供するなど、メタデータを強化します。

実装の概要

このセクションでは、e コマースの購入手続きで推奨される住所入力のワークフローについて説明します。このプロセスは、次の 3 つのステップで構成されます。

  1. Place Autocomplete を使用して、最初に住所をキャプチャします。
  2. Address Validation API を使用して、入力された住所を確認します。
  3. 入力された住所の位置を地図上に表示し、お客様に確実な配送サービスを提供する。

次に、各ステップを詳しく説明します。

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

住所入力フォームの 1 行目に JavaScript API を使用して Place Autocomplete を実装します。

Place Autocomplete は、ユーザーが住所の詳細を入力すると候補を提示します。JavaScript API を使用して実装した場合、ユーザーが入力を開始すると、住所入力フォームのフィールドの下にプルダウンが表示され、キー入力ごとに更新される予測入力サービスの結果が表示されます。住所を見つけるのに十分な情報を入力したら、プルダウンから住所を選択します。このアクションにより、フォーム フィールドに住所データが自動的に入力されます。

Place Autocomplete を使用すると、ユーザーに 2 種類のフォーム入力スタイルを提供できます。1 つのディスプレイにすべての住所フィールドを表示するか、1 つのディスプレイに単一の入力フィールドを表示するかです。この 1 つの入力フィールドにより、住所コンポーネントを個別に入力するのではなく、入力時に検索を開始するよう求められます。予測入力によって住所が入力されると、ワークフローによってフォーム フィールドに住所データが入力され、お客様は確認や編集（アパートやマンション番号の追加など）を行うことができます。

このフローが 1 つの入力フィールドでどのように表示されるかの例を次に示します。

イメージ

ステップ 2: Address Validation API を使用して住所を検証する

ユーザーが住所を入力したら、購入手続き時に Address Validation API を呼び出して、住所が有効かつ完全であることを確認することをおすすめします。ユーザーが住所フォームの [次へ] または [続行] ボタンをクリックすると、Address Validation API の呼び出しをトリガーします。多くの場合、このボタンをクリックすると支払いページが表示されます。

トランザクションごとに Address Validation API を呼び出すことをおすすめします。

次のフロー図は、購入手続き内での Address Validation API のエンドツーエンドの統合の例を示しています。

イメージ

このドキュメントでは、アドレス承認のシナリオを後で説明します。

ステップ 3: 視覚的に確認する

住所の入力後、配達場所を地図上に表示して、ユーザーが視覚的に確認できるようにします。これにより、住所が正しいという確信が持てるようになり、配達や集荷の失敗が減少します。

この地図は、購入手続きの際に表示するか、トランザクション確認メール内で送信できます。どちらのユースケースも、次の API で実現できます。

Maps JavaScript API は、ユーザーの現在地を表示するためのインタラクティブな地図を提供します。 Maps Static API を使用すると、ウェブページ内やメール内の後続段階で画像を埋め込むことができます。

詳細 - 承認シナリオへの対応

Address Validation API のレスポンスは、主に次の 3 つのシナリオに分類できます。

  • 修正 - 住所が低品質です。 詳細情報の入力を求められます。
  • 確認 - 住所は高品質ですが、入力された住所と異なっています。確認を求めるメッセージが表示されることがあります。
  • 承認 - 高画質の住所です。指定されたアドレスを受け入れることができます。

このコンセプトについては、Address Validation API ドキュメントの検証ロジックの構築セクションで説明しています。このセクションでは各シナリオについて説明します。

解決方法

イメージ

このセクションでは、住所入力を修正する方法について説明します。Address Validation API が低品質の住所を示すために返す特定のシグナルについては、「検証ロジックの作成」ドキュメントの住所の修正をご覧ください。

Address Validation API からのレスポンスで無効な住所が示されている場合は、お客様を住所入力フォームにリダイレクトして、入力されたデータを確認します。住所が修正されたら、サービスは Address Validation API に再送信して、修正が有効であることを確認する必要があります。

addressComponents レベルで返されるシグナルを使用して、特定の住所行エラーをハイライト表示することもできます。右のスクリーンショットに例を示します

確定

イメージ

このセクションでは、住所を確認する方法について説明します。住所を確認する必要があることを示すために Address Validation API から返される特定のシグナルについては、「検証ロジックの作成」ドキュメントの住所を確認するをご覧ください。

システムでユーザーに住所の確認を求めることはよくあります。たとえば、都市名のスペルミスがあると、Address Validation API によって修正されます。この修正をお客様に確認する必要があります。これは、API によって行われた変更によって、最初に入力された内容が根本的に変わる可能性があるためです。

インタースティシャル モーダルを使用してユーザーに情報を表示し、次の 3 つのオプションを有効にします。

  1. API から返された住所を確認します。正しい住所を使用して購入手続きが続行されます。
  2. 最初に入力された住所を選択します。Address Validation API による修正は無視されます。購入手続きは通常どおり続行でき、処理が許す限り、注文は発送前に下流の審査対象にフラグされます。
  3. 顧客はモーダルをキャンセルするかキャンセルし、購入手続きの住所入力ステージに戻ります。住所をゼロから再入力し、手続きをやり直すことができます。

右側のスクリーンショットに、この例が示されています。

承認

このセクションでは、アドレスを受け入れる方法について説明します。Address Validation API が返す、住所の品質が良く、受け入れられるべきであることを示すシグナルについては、「検証ロジックの作成」ドキュメントの住所を受け入れるをご覧ください。

このシナリオでは、購入手続きを次のステージ（支払いの回収など）に進み、住所の品質に関するプロンプトをお客様に表示しないようにします。お客様が入力した住所の品質が高く、配送可能であることが API により確認されました。

次のような軽微な修正や追加が含まれる可能性があるため、Address Validation API から返された住所データを注文に対して使用することをおすすめします。

  • 大文字アルファベットの使用方法
  • 次のような書式の修正。
    • ストリートからストリート
    • 住所コンポーネントの正しい順序
  • ZIP+4（米国）

導入の際の留意事項（英語記事）

住所承認ロジックを作成する際は、無効な住所を入力してユーザーが購入手続きを妨げないように実装してください。無効なエントリが API で繰り返し示された場合に、無限ループが発生しないようにロジックを構築します。

Google では、お客様が住所を入力できる機会を 2 回まで提供し、2 回目の試行で、確認できなくても入力を承認することをおすすめします。2 回目の試行では、検証の結果にかかわらず続行することが目標です。

2 回目の試行を受け入れるには、次の 2 つの方法が推奨されます。

  • Force-proceed: 住所が検証されていないことを説明するモーダルをお客様に表示しますが、入力された住所を引き続き使用できるようにします。
  • Silent Acceptance: 住所が完全に検証されていなくても、確認手順なしで 2 回目の試行を自動的に受け入れます。

可能であれば、検証されていない住所にフラグを立て、注文が発送される前にカスタマー サービス担当者が住所を確認できるようにシステムを設計します。この追加手段により、ミスを確実に検出できます。

新しい建物の建設では、この確認が推奨される理由がよくわかります。新しい建物の建設が完了してから、その建物の住所が住所データベースに入力されるまでに時間差がある場合があります。住所が検証されていなくても、入力した住所で購入手続きを強制的に進めることができます。

購入手続きが完了したら、必要に応じて provideValidationFeedback メソッドを使用して、特定の住所確認の試行に関するフィードバックを送信します。

おわりに

このドキュメントでは、Google マップに予測入力、Address Validation、視覚的確認を実装する購入手続きフローの概要を説明します。このドキュメントを出発点として使用し、推奨される住所入力フローに沿って実装を設計してください。

次のステップ

信頼性の高い住所で購入手続き、配送、運用を改善する ホワイトペーパーをダウンロードし、Address Validation による購入手続き、配送、運用の改善 ウェブセミナーをご覧ください。

関連資料の候補:

協力者

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

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