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

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

目標

Address Validation はさまざまなユースケースで価値を発揮します。テスト結果の品質以外にも、検討すべき重要な要素があります。たとえば、Place Autocomplete や Maps などのユーザーフローにおける対応製品の全体像、地域ごとの利用可能性、エンタープライズの信頼性などです。

住所確認 API の評価段階に達したら、テストの一環として使用することをおすすめするガイドラインを以下に示します。

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

  1. Address Validation API がユースケースに適していることを確認します。
  2. Address Validation API がソリューションの要件（次のようなもの）を満たしていることを確認します。
    • 質の高い住所を特定する。
    • 品質の低い入力に対処するためのアラート。
    • 推測、置換、スペル修正など、住所データの修正。
    • 配送用のフォーマットされた住所を提供します。
    • 番地以下のデータが不足しているか正しくない場合にアラートを表示します（米国のみ）。
  3. API の実装から測定可能なメリットが得られることを確認します。

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

データの準備

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

キャプチャ時のアドレスを使用します。たとえば、e コマースの購入手続きで住所の検証を実装する場合は、住所検証 API の実装によって置き換えられる可能性のある既存の処理が行われる前に、フォームに入力された住所を使用します。

テスト用に 5,000 ～ 10,000 件程度のサンプルサイズを用意します。

API を呼び出す

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

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

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

このステップの結果は、各アドレス レコードの API からのデータ出力になります。結果を分析して、ユースケースに対する API の適合性を判断できます。スプレッドシート、データベース、その他のツールを使用するかどうかは、ユーザーが決定します。

結果を確認する

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

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

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

レスポンス データ

概要

評価方法

どのようなメリットがあるか

verdict.inputGranularity

住所の入力粒度を説明します。

SUB_PREMISE

前提

PREMISE_PROXIMITY

ブロック

ROUTE

その他

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

verdict.validationGranularity

住所の出力検証の全体像について説明します。

SUB_PREMISE

前提

PREMISE_PROXIMITY

ブロック

ROUTE

その他

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

verdict.hasInferredComponents

API がコンポーネントを推論したかどうかを通知します。

True/False

API は、データを推測できる場合に、不足しているコンポーネントを追加できます。たとえば、州コードがありません。

verdict.hasReplacedComponents

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

True/False

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

verdict.addressComplete

住所が完全かどうかを示すシグナル。

True/False

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 から確認する主なシグナルは次のとおりです。

  • リスクレベルに応じて OTHER または ROUTE に設定された verdict.validationGranularity。
  • 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 が付加価値を生み出す方法の 1 つであり、テストの一部としてこれを把握することが重要です。

注意すべき主なシグナルは次のとおりです。

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

詳しくは、住所を確認するをご覧ください。

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

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

例: 修正を含む住所

入力された住所

リージョン

76 Bruckingm Palace Road, London SW1W 9TQ

英国

ルート addressComponent

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

[米国のみ] 建物名や部屋番号のデータが不足している、または正しくない住所を確認する

Address Validation API は、米国の住所について、サブプレミスが欠落しているか、間違っているかを判断できます。

注意すべき主なシグナルは次のとおりです。

  • Address オブジェクトで、次のようにします。
    • subpremise を含む unconfirmedComponentTypes
    • subpremise を含む missingComponentTypes
  • UspsData オブジェクトで、次のようにします。
    • dpvConfirmation は D です（サブプレミスがありません）
    • dpvConfirmation は S です（前提条件は未確認）

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

このテストでは、アパートの部屋番号などのサブプレミスが欠落しているか、正しくないデータがあるかどうかを確認できます。これにより、特に配信のユースケースで、ダウンストリームの問題が発生する可能性があります。Address Validation API は、この情報を早い段階で特定することでワークフローに付加価値をもたらし、修正されたデータを収集する手順を実装できるようにします。

例: Missing subpremise

入力された住所

リージョン

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