Address Validation API を使用して大量のアドレスを処理する

目的

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

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

ユースケース

次は、大量の住所確認が役立つユースケースを見ていきます。

テスト

多くの場合、何千ものアドレスを実行して Address Validation API のテストを行います。カンマ区切り値ファイルにアドレスが含まれている場合、アドレスの品質を検証できます。

アドレスの 1 回限りの検証

Address Validation API のオンボーディング中に、ユーザー データベースと照らし合わせて既存の住所データベースを検証する必要があります。

住所の定期的な確認

多くのシナリオでは、住所を繰り返し確認する必要があります。

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

技術的な詳細

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

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

本番環境用のキャッシュ

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

大量の Address Validation ユースケースの場合、データ キャッシュはセクション 11.3 に記載されている Address Validation API のサービス固有の規約に従う必要があります。この情報に基づいて、ユーザーの住所が無効であるかどうかを判断できます。その場合は、ユーザーが次にアプリを操作するときに住所の修正を求めるプロンプトを表示します。

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

実際の住所に関する情報をキャッシュに保存する場合は、ユーザーの同意がある場合にのみ、データをキャッシュに保存する必要があります。これにより、ユーザーは特定のサービスが住所を保存する理由を十分に理解でき、住所の共有に関する利用規約に同意できます。

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

ユーザーの同意を得て、レスポンスの formattedAddress とその他の主要コンポーネントをキャッシュに保存できます。ただし、ヘッドレスのシナリオでは、住所検証がバックエンドから行われるため、ユーザーが同意することはできません。したがって、このヘッドレスのシナリオでは、非常に限られた情報をキャッシュに保存できます。

レスポンスの内容

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 検証を実装する

上記の説明に基づくと、

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

次のセクションでは、利用規約を遵守し、大量の住所検証を実装する方法について、2 ステップのプロセスについて説明します。

ステップ 1:

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

図 A: 次の図は、大容量の 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 をデータベースにキャッシュできます。

おわりに

大量の住所確認は、多くのアプリケーションで遭遇する可能性が高い一般的なユースケースです。このドキュメントでは、Google Maps Platform の利用規約に準拠した、いくつかのシナリオと、そうしたソリューションの実装方法の設計パターンを示すことを目的としています。

さらに、GitHub にオープンソース ライブラリとして High Volume Address Validation のリファレンス実装を公開しています。大容量の Address Validation の使用をすぐに開始するには、こちらをご確認ください。また、さまざまなシナリオでライブラリを使用する方法に関する設計パターンに関する記事もご覧ください。

次のステップ

「信頼できる住所で購入手続き、配達、運用を改善する 」のホワイトペーパーをダウンロードし、Address Validation による購入手続き、配送、オペレーションの改善 のウェブセミナーを視聴する。

関連資料:

協力者

この記事は Google が管理しています。最初に書いたのは以下の寄稿者です。
主任執筆者:

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