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

目標

デベロッパーは多くの場合、顧客の住所を含むデータセットを操作します。 質が悪いかもしれません住所が正しいことを確認する必要があります。 お客様 ID の確認から配送まで、さまざまなユースケースに対応できます。

Address Validation は API は、 住所の検証に使用できる Google Maps Platform。ただし、 一度に 1 つのアドレスを処理します。このドキュメントでは、Terraform を使用して API テスト、さまざまなシナリオでの大量の Address Validation のサポート 1 回限りおよび定期的な住所確認に移行できます

ユースケース

次に、大量の Address Validation や、 便利です。

テスト

何千ものサーバーを実行して Address Validation API をテストし、 あります。住所をカンマ区切りファイルで指定して、 住所の品質を検証します。

住所の 1 回限りの検証

Address Validation API のオンボーディング中に、Address Validation API を ユーザー データベースと照合します。

住所の定期的な検証

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

  • 詳細を取得するため住所を検証するジョブをスケジュールしている可能性があります 日中の検索（例: 顧客登録、注文の詳細、配送） できます。
  • さまざまな部門、 多岐にわたります。新しい部門に 使用する前に検証する必要があります。
  • アンケートや各種プロモーションの実施時などに住所を収集する 表示されます。アドレスが システムに入力する際の修正です。

技術的な詳細

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

  • お客様の住所を使用して Address Validation API を呼び出している データベース（顧客の詳細情報を含むデータベース）
  • データベース内の個々のアドレスに対して有効フラグをキャッシュに保存できます。
  • 有効フラグは、API 呼び出しで Address Validation API から 顧客がログインするたびに
で確認できます。 <ph type="x-smartling-placeholder">

本番環境用のキャッシュ

Address Validation API を使用する際は、しばしば IP アドレスの一部を レスポンスが返されます。Google の利用規約 Service の上限 キャッシュに保存できるデータ、Address Validation API からキャッシュに保存できるデータ ユーザー アカウントに対してキャッシュに保存される必要があります。つまり、データベース内では、 ユーザーのメール アドレスまたはアドレスに対してキャッシュに保存される必要があります。 他のプライマリ ID を指定します

High Volume Address Validation のユースケースでは、データ キャッシュは Address Validation API サービス固有 利用規約 概要をセクション 11.3 に記載します。この情報に基づいて、次のことができます。 ユーザーの住所が無効かどうかを判断します。その場合は、 次回の問い合わせ時に、正しい住所を入力したことをユーザーに知らせてください。 説明します。

  • AddressComponent からのデータ オブジェクト <ph type="x-smartling-placeholder">
      </ph>
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

実際の住所に関する情報をキャッシュに保存する場合は、 ユーザーの同意がある場合にのみキャッシュに保存する必要がある。これによりユーザーは 特定のサービスが住所を保存している理由を認識しており、 住所の共有に関する利用規約はありません。

ユーザーの同意の例として、e コマース アドレスへの直接のインタラクションが挙げられます。 購入手続きのページのフォームでCloud Storage のバケットをキャッシュに保存し、 荷物を配送する目的で住所を処理する。

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

レスポンスの内容

Address Validation API のレスポンスに次のマーカーが含まれている場合、 提供された住所が質の高いものであることを確信できる:

  • 判定結果の addressComplete マーカー オブジェクトが true の場合、
  • 判定結果の validationGranularity オブジェクトが PREMISE または SUB_PREMISE である
  • AddressComponent 以外 次のようにマークされます。 <ph type="x-smartling-placeholder">
      </ph>
    • 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 では、キャッシュに保存できるデータが制限されています。

次のセクションでは、Google Cloud リソースへの準拠を 大量の住所確認を実装できます。

ステップ 1:

最初のステップでは、大量のアドレスを実装する方法を説明します。 検証スクリプトを使用できます。このプロセスでは Address Validation API レスポンスの特定のフィールドを、 サービスに即した対応が可能です。

図 A: 次の図は、データ パイプラインの強化方法を示しています。 大量の住所確認ロジックで対応できます

alt_text

利用規約に基づき、 addressComponent:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

したがって、実装のこのステップでは、上記のデータをキャッシュに保存します。 UserID と照合します。

詳しくは、実際のデータ 構成します。

ステップ 2:

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

図 B: この図は、ユーザーのエンドツーエンドの統合を示しています。 同意フローは次のようになります。

alt_text

  1. ユーザーがログインしたら、まず検証フラグがキャッシュに保存されていないか確認します。 確認できます。
  2. フラグがある場合は、修正と修正を行うための UI をユーザーに提示する必要があります。 住所を更新したりできます。
  3. 更新された API またはキャッシュに保存された API を使用して Address Validation API を再度呼び出す 修正した住所をお客様に提示して確認します。
  4. 住所の品質が高い場合、Address Validation API は formattedAddress。
  5. 住所が修正された場合は、その住所をユーザーに提示することもできます。 修正がない場合は自動的に承認されます。
  6. ユーザーが承諾したら、formattedAddress をデータベースにキャッシュできます。
で確認できます。

まとめ

大量の Address Validation は、 多くのアプリケーションで使用されています。このドキュメントでは、いくつかのシナリオと、 実装方法に関する設計パターンを Google マップに準拠 プラットフォーム利用規約。

また、大量アドレスのリファレンス実装を作成しました。 GitHub のオープンソース ライブラリとしての検証。今すぐチェック 迅速に構築できます。また、次の記事をご覧ください。 さまざまなシナリオでのライブラリの使用方法について 考察します

次のステップ

「住所の信頼性を高めて購入手続き、配送、運用を改善する ホワイトペーパー Address による購入手続き、配送、運用の改善に関するページ 確認事項 ウェブセミナー。

関連資料の候補:

寄稿者

この記事は Google が管理します。以下の寄稿者が執筆しています。
主要な著者:

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