このドキュメントでは、Address Validation API がレスポンス シグナルを返し、システムで修正動作が必要になる可能性のある、実際のシナリオをいくつか説明します。コンテキストについては、検証ロジックを構築するのワークフローの例をご覧ください。
一般的な例: 修正
このセクションでは、住所の品質が低いことを示すレスポンス シグナルが Address Validation API から返される一般的な例について説明します。
市区町村と郵便番号がありません
この例は、市区町村や郵便番号がなく、番地のみのエントリを示しています。
住所を入力済み | 地域 |
---|---|
21 45 40th street | 米国 |
市区町村と郵便番号が欠落している場合の判定
次の例では、レスポンスの重要なシグナルを強調しています。
{
"inputGranularity": "PREMISE",
"validationGranularity": "OTHER",
"geocodeGranularity": "OTHER",
"hasUnconfirmedComponents": true,
"possibleNextAction": "FIX"
}
possibleNextAction
は、住所に配達できない可能性があることを示す最初の指標となります。他のハイライト表示されたコンポーネントもこの可能性をサポートしているため、addressComponents
をクエリして詳細を確認できます。
{
"componentName": {
"text": "21",
"languageCode": "en"
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
"componentName": {
"text": "45 40th street",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
"componentName": {
"text": "United States",
"languageCode": "en"
},
"componentType": "country",
"confirmationLevel": "CONFIRMED"
}
Address Validation API は、国(米国)のみを CONFIRMED
として返します。他のすべてのアドレス コンポーネントは UNCONFIRMED_BUT_PLAUSIBLE
として返されます。ただし、地域や郵便番号など、データの一部は省略されます。
番地が未入力
この例では、番地が欠落している場合を示します。
住所を入力済み | 地域 |
---|---|
Buckingham Palace Road, SW1W 9TQ London | 英国 |
番地が未入力の場合の判定
{
"inputGranularity": "PREMISE_PROXIMITY",
"validationGranularity": "ROUTE",
"geocodeGranularity": "ROUTE",
"possibleNextAction": "FIX"
}
ここでも、possibleNextAction
は、アドレスが配信できない可能性があることを示す最初の兆候となります。また、validationGranularity
は ROUTE
であり、これは住所と一致しているものの、建物にたどり着くための情報が不足していることを示しています。また、addressComplete
プロパティが判定にないため、false
になります。address
オブジェクトをさらにクエリすると、コンポーネント タイプが欠落していることがわかります。
"missingComponentTypes": [
"street_number"
]
エッジケースの例: 修正
状況によっては、住所を修正、確認、承認するかどうかは、ビジネスの特定のシナリオによって異なります。次の例は、厳密には修正カテゴリに分類されないシナリオを示しています。
番地が未確認
このシナリオでは、Address Validation API は指定された番地を確認できませんが、住所は完全であると示しています。
住所を入力済み | 地域 |
---|---|
84 Buckingham Palace Road, SW1W 9TQ, London | 英国 |
未確認の番地の判定
次の例では、重要なシグナルを強調しています。
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete" : true,
"hasUnconfirmedComponents": true,
"possibleNextAction": "ACCEPT"
}
検証の粒度を区画レベルの近似値と未確認のコンポーネントのみに組み合わせることを検討する価値があります。addressComponents
プロパティのクエリでは、次の未確認の componentType
が表示されます。
{
"componentName": {
"text": "84",
"languageCode": "en"
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
}
ここでは、street_number
の confirmation_level
が UNCONFIRMED_BUT_PLAUSIBLE
に設定されています。[Unconfirmed] は、サービスがデータセット内の 84 の番地と一致させることができないことを意味します。[plausible] は、コンポーネント データがまだ有効である可能性があることを意味します。
サブ前提がありません
このシナリオでは、アパートや部屋番号など、建物内の場所のみが欠落している住所について説明します。それ以外の場合は、Address Validation API で住所を完全に検証できます。住所コンポーネントが欠落している場合と同様に、addressComplete
は false
になり、判定の手動検査には表示されません。
たとえば、サンフランシスコ市の評価事務所の有効な住所を入力したものの、部屋番号の入力を忘れたとします。
住所を入力済み | 地域 |
---|---|
1 Doctor Carlton B Goodlett Place, San Francisco, CA 94102 | 米国 |
サブプレミスがない場合の判定
この例では、判定に addressComplete
プロパティが表示されていないため、false
になります。このため、少なくとも 1 つのアドレス要素が予期しないもの、解決されていないもの、または欠落しているものであることがわかります。
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"hasInferredComponents": true,
"possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}
address
クエリを実行すると、次の結果が得られます。
"missingComponentTypes": [
"subpremise"
]
さらに問い合わせたところ、USPS のデータでは dpvConfirmation
コードが D
となっており、これも副住所がないことを示しています。