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

目的

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

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

ユースケース

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

テスト

多くの場合、何千もの住所を実行して Address Validation API をテストします。カンマ区切り値ファイル内のアドレスの品質を検証する必要がある場合があります。

住所の 1 回限りの検証

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

住所の定期的な検証

いくつかのシナリオでは、住所を定期的に検証する必要があります。

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

技術的な詳細

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

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

本番環境用のキャッシュ

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

大量の Address Validation のユースケースの場合、データ キャッシュは、Address Validation API のサービス固有の規約（セクション 11.3 で概説）に従う必要があります。この情報に基づいて、ユーザーの住所が無効かどうかを判断できます。無効の場合は、次にアプリを操作する際に、正しい住所の入力をユーザーに求めるようにします。

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

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

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

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

レスポンスの内容

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

  • 判定オブジェクトの addressComplete マーカーは true です。
  • 判定オブジェクトの 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 の利用規約により制限されています。

次のセクションでは、利用規約を遵守し、大量の住所検証を実装する方法に関する 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 をデータベースにキャッシュできます。

おわりに

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

さらに、GitHub にオープンソース ライブラリとして、High Volume Address Validation のリファレンス実装を作成しました。High Volume Address Validation を ぜひお試しくださいまた、さまざまなシナリオでライブラリを使用する方法の設計パターンについての記事もご覧ください。

次のステップ

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

関連資料の候補:

協力者

この記事は Google が管理します。以下の寄稿者が執筆しています。
プリンシパルの作成者:

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