大量の住所確認ガイド

目標

デベロッパーは、品質が良くない可能性のある顧客の住所を含むデータセットを扱うことがよくあります。お客様の本人確認から配送まで、さまざまなユースケースで住所が正しいことを確認する必要があります。

Address Validation API は、住所の検証に使用できる Google Maps Platform のプロダクトです。ただし、一度に処理できるアドレスは 1 つだけです。このドキュメントでは、API テストから 1 回限りおよび繰り返し住所検証まで、さまざまなシナリオで High Volume Address Validation を使用する方法について説明します。

ユースケース

次に、High Volume Address Validation が役立つユースケースについて説明します。

テスト

Address Validation API をテストするために、数千件のアドレスを実行することがよくあります。カンマ区切り値ファイルに住所が保存されていて、住所の品質を検証したい場合。

住所の 1 回限りの検証

Address Validation API へのオンボーディング中に、既存の住所データベースをユーザー データベースと照合して検証します。

住所の定期的な検証

次のようなシナリオでは、住所を定期的に検証する必要があります。

  • たとえば、顧客の登録、注文の詳細、配送スケジュールなど、日中に取得した詳細情報の住所を検証するジョブをスケジュールしている場合があります。
  • たとえば、営業部門からマーケティング部門など、さまざまな部門からアドレスを含むデータダンプを受け取ることがあります。アドレスを受け取る新しい部門は、使用する前にアドレスを検証することがよくあります。
  • アンケートやさまざまなプロモーションで住所を収集し、後でオンライン システムで更新することがあります。システムに入力する際に、住所が正しいことを検証したいと考えています。

技術的な詳細

このドキュメントでは、次のことを前提としています。

  • 顧客データベース（顧客の詳細情報を含むデータベース）のアドレスを使用して Address Validation API を呼び出している
  • データベース内の個々のアドレスに対して有効性フラグをキャッシュできます。
  • 有効性フラグは、個々のお客様がログインしたときに Address Validation API から取得されます。

本番環境用のキャッシュ

Address Validation API を使用する場合、API 呼び出しからのレスポンスの一部をキャッシュに保存することがよくあります。利用規約では、キャッシュに保存できるデータが制限されていますが、Address Validation API からキャッシュに保存できるデータは、ユーザー アカウントに対してキャッシュに保存する必要があります。つまり、データベースでは、住所または住所のメタデータをユーザーのメールアドレスまたはその他のプライマリ ID に対してキャッシュに保存する必要があります。

High Volume Address Validation のユースケースでは、データ キャッシュは、セクション 11.3 に記載されている Address Validation API のサービス固有の利用規約に準拠する必要があります。この情報に基づいて、ユーザーの住所が無効かどうかを判断できます。無効な場合は、ユーザーが次にアプリを操作するときに、正しい住所を入力するよう求めることができます。

  • AddressComponent オブジェクトのデータ
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

実際の住所に関する情報をキャッシュに保存する場合は、ユーザーの同意を得たうえでキャッシュに保存する必要があります。これにより、特定のサービスが住所を保存する理由をユーザーが十分に認識し、住所の共有条件に同意していることを確認できます。

ユーザーの同意の例としては、購入手続きページの e コマースの住所フォームを直接操作することが挙げられます。荷物の発送を目的として、住所をキャッシュして処理することが理解されています。

ユーザーの同意を得たうえで、レスポンスから formattedAddress などの主要なコンポーネントをキャッシュに保存できます。ただし、ヘッドレス シナリオでは、Address Validation がバックエンドから行われるため、ユーザーは同意を提供できません。そのため、このヘッドレス シナリオでは、キャッシュに保存できる情報は非常に限られます。

レスポンスの内容

Address Validation API のレスポンスに次のマーカーが含まれている場合、入力された住所は配送可能な品質であると確信できます。

  • Verdict オブジェクトの addressComplete マーカーが true である。
  • Verdict オブジェクトの validationGranularity が PREMISE または SUB_PREMISE である
  • AddressComponent のいずれも、次のようにマークされていません。
    • Inferred（注: : inferred=true は addressComplete=true の場合に発生することがあります）
    • spellCorrected
    • replaced
    • unexpected、および
  • confirmationLevel: AddressComponent の確認レベルが CONFIRMED または UNCONFIRMED_BUT_PLAUSIBLE に設定されています。

API レスポンスに上記のマーカーが含まれていない場合、入力された住所の品質が低い可能性があります。その場合は、データベースにフラグをキャッシュして、そのことを反映できます。キャッシュに保存されたフラグは、住所全体の品質が低いことを示します。一方、スペル修正などのより詳細なフラグは、住所の品質に関する特定の問題の種類を示します。品質が低いとフラグが付けられた住所を使用するお客様との次のやり取りで、既存の住所を使用して Address Validation API を呼び出すことができます。Address Validation API は、UI プロンプトを使用して表示できる修正済みのアドレスを返します。お客様がフォーマットされた住所を受け入れたら、レスポンスから次の情報をキャッシュに保存できます。

  • formattedAddress
  • postalAddress
  • addressComponent componentNames または
  • UspsData standardizedAddress

ヘッドレス Address Validation を実装する

上記の説明に基づき、

  • ビジネス上の理由から、Address Validation API からのレスポンスの一部をキャッシュに保存する必要があることがよくあります。
  • ただし、Google Maps Platform の利用規約により、キャッシュに保存できるデータが制限されています。

次のセクションでは、利用規約に準拠し、大量の Address Validation を実装する方法について、2 段階のプロセスを説明します。

ステップ 1:

最初のステップでは、既存のデータ パイプラインから大量の住所検証スクリプトを実装する方法について説明します。このプロセスにより、Address Validation API レスポンスの特定のフィールドを、利用規約に準拠した方法で保存できます。

図 A: 次の図は、High Volume Address Validation ロジックを使用してデータ パイプラインを強化する方法を示しています。

alt_text

利用規約に基づき、addressComponent から次のデータをキャッシュに保存できます。

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

したがって、実装のこのステップでは、上記のフィールドを UserID に対してキャッシュします。

詳細については、実際のデータ構造をご覧ください。

ステップ 2:

ステップ 1 で、入力データセットの一部の住所の品質が低い可能性があるというフィードバックを収集しました。次のステップでは、これらのフラグ付きアドレスをユーザーに提示し、保存されているアドレスを修正することに同意してもらいます。

図 B: この図は、ユーザーの同意フローのエンドツーエンドの統合がどのように行われるかを示しています。

alt_text

  1. ユーザーがログインしたら、まず、システムにキャッシュされた検証フラグがあるかどうかを確認します。
  2. フラグがある場合は、住所を修正して更新するための UI をユーザーに表示する必要があります。
  3. 更新された住所またはキャッシュに保存された住所を使用して Address Validation API を再度呼び出し、修正された住所をユーザーに提示して確認を求めることができます。
  4. 住所の品質が良好な場合、Address Validation API は formattedAddress を返します。
  5. 修正が行われた場合は、その住所をユーザーに提示できます。修正がない場合は、そのまま受け入れます。
  6. ユーザーが同意したら、formattedAddress をデータベースにキャッシュできます。

まとめ

High Volume Address Validation は、多くのアプリケーションでよく見られるユースケースです。このドキュメントでは、Google Maps Platform の利用規約に準拠したソリューションを実装する方法について、いくつかのシナリオと設計パターンを紹介します。

さらに、GitHub でオープンソース ライブラリとして、High Volume Address Validation のリファレンス実装を作成しました。このチュートリアルを参考に、High Volume Address Validation を使った開発をすぐに始めましょう。また、さまざまなシナリオでライブラリを使用する方法に関するデザイン パターンの記事もご覧ください。

次のステップ

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

おすすめの関連情報:

寄稿者

この記事は Google が管理しています。このドキュメントは、以下のコントリビューターによって作成されました。
主な著者:

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