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

目標

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

前提条件

次の知識を習得することをおすすめします。

住所確認とは

Address Validation API は、住所を受け入れるサービスです。住所の構成要素を識別して検証します。また、郵送用の住所を標準化し、その住所に最適な緯度と経度の座標を検索します。必要に応じて、米国とプエルトリコの住所については Coding Accuracy Support System（CASS™）を有効にできます。

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

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

お客様が住所をすばやく正確に入力できるようにガイドする:
プレイス オートコンプリートを使用すると、住所の入力が速くなり、入力ミスが減るため、お客様は購入手続きを簡単に進めることができます。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 つのディスプレイに単一の入力フィールドを表示するかです。この単一の入力フィールドでは、住所の各要素を個別に入力するのではなく、入力しながら検索を開始するようユーザーに促します。住所が自動入力されると、ワークフローで住所データを含むフォーム フィールドが展開され、顧客は確認して編集できます（部屋番号の追加など）。

単一の入力フィールドを使用したこのフローの表示例を次に示します。

画像

ステップ 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 から返された住所データを注文に使用することをおすすめします。次のような軽微な修正や追加が含まれている可能性があります。

  • 大文字アルファベットの使用方法
  • 書式設定の修正（例:
    • ストリートから St
    • 住所の構成要素の順序を正しくする
  • ZIP+4（米国）

実装に関する注意事項

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

Google では、お客様が住所を入力できる機会を 2 回まで提供し、2 回目の試行で、確認できなくても入力を受け入れることをおすすめします。2 回目の試行では、検証に関係なくユーザーを続行させることを目標とします。

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

  • 強制続行: 住所が検証されていないことを説明するモーダルをお客様に表示しますが、入力した住所で続行するオプションを許可します。
  • サイレント承認: 住所が完全に検証されていない場合でも、確認手順なしで 2 回目の試行を自動的に承認します。

可能であれば、検証できない住所を報告するようにシステムを設計し、注文の発送前にカスタマー サービス担当者が確認できるようにします。この追加の対策により、間違いを検出できます。

新築の建物は、このチェックが推奨される理由を示す良い例です。新しい建物の建設が完了してから、その建物の住所が郵便番号データベースに入力されるまでには、時間差が生じる場合があります。入力した住所が検証されなくても、購入手続きページを強制的に進めることができるようにする必要があります。

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

まとめ

このドキュメントでは、Google マップでの自動入力、住所の検証、視覚的な確認を実装した購入手続きフローの概要について説明しました。このドキュメントを起点として、推奨される住所入力フローに沿って実装を設計してください。

次のステップ

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

関連情報:

寄稿者

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

  1. 米国郵政公社の非独占的なライセンシーです。CASS™、USPS®、DPV® の各商標は米国郵政公社が所有し、許諾を得て使用しています。↩