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

目標

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

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

ユースケース

次に、大容量アドレス検証が役立つユースケースについて説明します。

テスト

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

住所の 1 回限りの検証

Address Validation API にオンボーディングする際に、既存のアドレス データベースをユーザー データベースに対して検証する必要があります。

住所の定期的な検証

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

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

技術的な詳細

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

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

本番環境用のキャッシュ

アドレス検証 API を使用する場合、多くの場合、API 呼び出しからの応答の一部をキャッシュする必要があります。我々 の利用規約ではキャッシュできるデータが制限されていますが、Address Validation API からキャッシュできるデータはすべてユーザー アカウントに対してキャッシュされる必要があります。つまり、データベースでは、アドレスまたはアドレスのメタデータは、ユーザーのメールアドレスまたはその他のメイン ID に対してキャッシュに保存されている必要があります。

大量の住所検証のユースケースでは、データ キャッシュ保存は、セクション 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（addressComplete=true のときに : inferred=true が発生する可能性があることに注意）
    • spellCorrected
    • replaced
    • unexpected、および
  • confirmationLevel: AddressComponent の確認レベルが CONFIRMED または UNCONFIRMED_BUT_PLAUSIBLE に設定されている

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

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

ヘッドレスの住所確認を実装する

上記の議論に基づき、次のことが言えます。

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

次のセクションでは、利用規約に準拠し、大量のアドレス検証を実装する 2 つの手順について説明します。

ステップ 1:

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

図 A: 次の図は、大容量アドレス検証ロジックを使用してデータ パイプラインを強化する方法を示しています。

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 でオープンソース ライブラリとして、大容量住所検証のリファレンス実装を作成しました。Address Validation による大量の住所の処理をすばやく開始するには、こちらをご覧ください。さまざまなシナリオでライブラリを使用する方法については、デザイン パターンの記事もご覧ください。

次のステップ

確実な住所で購入手続き、配送、オペレーションを改善する ホワイトペーパーをダウンロードし、Address Validation で購入手続き、配送、オペレーションを改善する ウェビナーをご覧ください。

参考資料:

寄稿者

この記事は Google が管理しています。このコンテンツは、以下の投稿者が作成しました。
主な著者:

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