住所検証ソリューションを選択する

テスト手順の概要を示すフロー図。

目標

Address Validation はさまざまなユースケースで価値を発揮します。テスト結果の生の品質以外にも、検討すべき重要な要素があります。 たとえば、 Place Autocomplete や Maps などのユーザーフローにおける互換性のあるプロダクトの全体像、地域ごとの利用可否、企業の 信頼性と信頼性などです。

Address Validation API の評価に進む場合は、テストの一環として次のガイドラインを使用することをおすすめします。

このテストの目的は次のとおりです。

  1. Address Validation API がユースケースに適していることを確認する。
  2. Address Validation API がソリューションの要件を満たしていることを確認する。たとえば、次のような要件です。
    • 高品質の住所を特定する。
    • 品質の低い住所入力について警告する。
    • 推論、置換、スペル修正など、住所データを修正する。
    • 配送用の書式設定された住所を提供する。
    • 建物内の部屋番号のデータが欠落しているか、正しくない場合に警告する（米国のみ）。
  3. API を実装することで測定可能なメリットが得られることを確認する。

テストを実施すると、上記の質問に回答し、API がビジネスに適しているかどうかを判断できます。

データの準備

テストは、既存の住所データのサンプルに対して実施する必要があります。テスト用のデータを手動で選択するのではなく、運用している地域を代表するランダムなサンプルを選択してください。たとえば、米国と英国の両方で事業を展開している場合、英国での事業が 70%、米国での事業が 30% である場合、サンプルはその割合を反映する必要があります。

取得時点の住所を使用します。たとえば、e コマースの購入手続きで住所の検証を実装する場合は、Address Validation API の実装によって置き換えられる可能性のある既存の処理が行われる前に、お客様がフォームに入力した住所を使用します。

テスト用に約 5,000 ～ 10,000 件のサンプル レコードを用意します。

API を呼び出す

セクションの前提条件: 住所検証リクエストを送信する方法を理解していること 。

データを準備したら、各住所レコードに対して API を実行する必要があります。

API の呼び出し方法については、Address Validation API のドキュメントをご覧ください。また、Address Validation API を使用して大量の住所を処理するためのベスト プラクティスについて説明した記事も用意しています。

このステップの結果は、各住所レコードの API からのデータ出力になります。その後、結果を分析して、API がユースケースに適しているかどうかを判断できます。スプレッドシート、データベース、その他のツールを使用するかどうかは、お客様次第です。

結果を確認します

セクションの前提条件: 検証レスポンスの処理方法、 特に修正、確認、承認のコンセプトを理解していること。

このセクションでは、ソリューションの適合性を評価するために分析できる出力シナリオについて説明します。

このドキュメントで説明する主な API フィールドの概要

レスポンス データ

これは

どのように評価するか

どう役立つのか

verdict.inputGranularity

住所の入力粒度を記述します。

SUB_PREMISE

PREMISE

PREMISE_PROXIMITY

BLOCK

ROUTE

OTHER

入力された住所に、有効である可能性のある十分なデータが含まれているかどうかを判断できます。

verdict.validationGranularity

住所の出力検証の全体像を記述します。

SUB_PREMISE

PREMISE

PREMISE_PROXIMITY

BLOCK

ROUTE

OTHER

API からの出力に基づいて、住所の全体的な品質を判断できます。

verdict.hasInferredComponents

API がコンポーネントを推測したかどうかを示します。

真偽値

API は、データを推測できる場合に、欠落しているコンポーネントを追加できます。たとえば、都道府県コードが欠落している場合などです。

verdict.hasReplacedComponents

API がコンポーネントを置き換えたかどうかを示します。

真偽値

API は、一部のシナリオで、正しくないコンポーネントを正しいデータに置き換えることができます。

verdict.addressComplete

住所が完全かどうかを示します。

真偽値

API が出力住所に必要なコンポーネントがすべて含まれていると判断した場合、これは true になります。

address.missingComponentTypes

住所にコンポーネントが欠落している場合に警告するシグナル。

値については、 表 2をご覧ください。

不完全な住所から欠落しているコンポーネントをハイライト表示します。

有効な住所を確認する

API から返されたデータを並べ替えて、システムが有効と見なす住所のセットを特定します。API から確認する主なシグナルは次のとおりです。

  • verdict.validationGranularity に PREMISE 以上が含まれている。
  • verdict.addressComplete が true である。
  • 推測されたコンポーネントや置き換えられたコンポーネントがない。

詳細については、住所を承認するをご覧ください。

この演習の出力は、システムで有効と見なされる住所データのサブセットになります。この時点で、次のことを判断できます。

  • 承認率が許容範囲内であるか。
  • 既存の住所検証ワークフローを使用している場合、承認率が同等以上であるか。

例: 有効な住所

入力された住所

リージョン

76 Buckingham Palace Road, London SW1W 9TQ

英国

Verdict

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true
}

無効な住所を確認する

このステップでは、無効とマークされた住所データの一部を手動で確認し、Address Validation API を使用せずに、その無効な住所がダウンストリームの問題を引き起こす可能性があるかどうかを確認します。

API から返されたデータを並べ替えて、システムが無効とマークする住所のセットを特定します。API から確認する主なシグナルは次のとおりです。

  • verdict.validationGranularity が、 リスクレベルに応じて OTHER または ROUTE に設定されている。
  • verdict.addressComplete が false である。

詳細については、住所を修正するをご覧ください。

この演習の出力は、システムが無効とマークする住所データのサブセットになります。この時点で、無効な割合が許容範囲内かどうかを判断できます。

住所を無効とマークすることは、Address Validation API のコア機能であり、無効とマークされた住所の割合が高いからといって、必ずしも API の品質が低いとは限りません。API は、住所に問題があることを通知します。これにより、ダウンストリームで問題が発生する前にエラーを検出できるため、ワークフローの効率化につながります。

例: 無効な住所

入力された住所

リージョン

21 45 40th street

米国

Verdict

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true
}

欠落しているコンポーネントまたは未確認のコンポーネントを確認する

この段階では、欠落しているコンポーネントや未確認のコンポーネントも確認できます。これは、返される Address オブジェクトの 一部です。2 つのフィールドは missingComponentTypes と unconfirmedComponentTypes です。

これらのフィールドを使用して、API が住所を無効とマークした理由を特定し、正しくない特定のフィールドをデータの収集ポイントにフィードバックすることで、住所を有効にするための正しい情報を収集します。これは、データの品質に関する具体的な情報を提供することで、API が価値を提供する方法の一つです。

例: 欠落しているコンポーネントと未確認のコンポーネント

入力された住所

リージョン

Fake St, New York, NY 10011

米国

Verdict

{
     "inputGranularity": "ROUTE",
     "validationGranularity": "OTHER",
     "geocodeGranularity": "OTHER",
     "hasUnconfirmedComponents": true
}

欠落しているコンポーネントと未確認のコンポーネント

"missingComponentTypes": [
    "street_number"
],
"unconfirmedComponentTypes": [
    "route"
]

修正された住所を確認する

Address Validation API は、入力データを修正し、無効な可能性のある住所入力を受け取り、有効な住所データを出力できます。これは API が価値を高める方法の一つであり、テストの一環としてこれを把握することが重要です。

確認する主なシグナルは次のとおりです。

  • いずれかの addressComponents で inferred、replaced、spellCorrected が true に設定されている。
  • verdict.hasInferredComponentsまたは verdict.hasReplacedComponents が true に設定されている。

詳細については、住所を確認するをご覧ください。

この演習の出力は、API によって修正が適用された住所データのサブセットになります。

このデータの一部を手動で確認して、API がダウンストリーム ワークフローの摩擦を軽減するような修正をデータに加えているかどうかを判断できます。

例: 訂正された住所

入力された住所

リージョン

76 Bruckingm Palace Road, London SW1W 9TQ

英国

Route addressComponent

{
    "componentName": {
        "text": "Buckingham Palace Road",
        "languageCode": "en"
    },
    "componentType": "route",
    "confirmationLevel": "CONFIRMED",
    "spellCorrected": true
}

[米国のみ] 建物内の部屋番号のデータが欠落しているか、正しくない住所を確認する

Address Validation API は、米国の住所について、建物内の部屋番号が欠落しているか、正しくないかどうかを判断できます。

確認する主なシグナルは次のとおりです。

  • Address オブジェクト内:
    • unconfirmedComponentTypes に subpremise が含まれている
    • missingComponentTypes に subpremise が含まれている
  • UspsData オブジェクト内:
    • dpvConfirmation が D である（建物内の部屋番号が欠落している）
    • dpvConfirmation が S である（建物内の部屋番号が未確認）

詳細については、米国の住所を処理するをご覧ください。

このテストでは、建物内の部屋番号などの欠落または誤りに関するデータの問題があるかどうかを確認します。これは、特に配送のユースケースでダウンストリームの問題を引き起こす可能性があります。Address Validation API は、これを早期に特定することでワークフローに価値をもたらし、修正されたデータを収集する手順を実装できます。

例: 建物内の部屋番号が欠落している

入力された住所

リージョン

111 8th Avenue, Manhattan, NY 10011

米国

欠落しているコンポーネント

"missingComponentTypes": [
    "subpremise"
]

USPS データ DPV 確認

"dpvConfirmation": "D"

[米国のみ] USPS standardizedAddress を確認する

Address Validation API は、米国の住所の USPS 標準化住所も返します。配送ラベルに USPS 形式の住所を印刷する必要がある場合は、特に重要です。

UspsAddress を確認してこのデータを表示し、ワークフローに 価値をもたらすかどうかを判断できます。

例: USPS 標準化住所

"standardizedAddress": {
    "firstAddressLine": "111 8TH AVE FL 11",
    "cityStateZipAddressLine": "NEW YORK NY 10011-5201",
    "city": "NEW YORK",
    "state": "NY",
    "zipCode": "10011",
    "zipCodeExtension": "5201"
}

まとめ

テストを開始する - Address Validation API のテストを今すぐ開始して、正確な住所データを確保し、顧客体験を向上させ、ビジネス オペレーションを効率化しましょう。上記のテスト シナリオに沿って進めると、Address Validation API がワークフローに価値をもたらすかどうかを判断するために必要な情報が得られます。

参考資料:

コントリビューター

Henrik Valve | DevX エンジニア