このドキュメントでは、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 データには D の dpvConfirmation コードが提供されています。これは、サブプレミスが欠落していることも示しています。