Bu belgede, Address Validation API'nin sisteminizden onay davranışı gerektiren adresler için yanıt sinyalleri sağladığı çeşitli gerçek dünya senaryoları açıklanmaktadır. Buradaki örnekler açıklayıcıdır ancak olası her durumu kapsamaz. Bağlam için Doğrulama mantığınızı oluşturma bölümündeki İş akışına genel bakış konusuna bakın.
Yaygın örnekler: onaylama
Aşağıdaki örnekte, benzer sokak adlarına sahip metropol bölgeler gösterilmektedir. Bir kullanıcının ABD'nin Kirkland, WA şehrindeki Google Building D adresini girmek istediğini varsayalım. Ancak şehir olarak Kirkland yerine yanlışlıkla Seattle'ı giriyorlar.
| Girilen adres | Bölge |
|---|---|
| Building D, 451 7th Avenue South, Seattle, WA 98033 | ABD |
Değiştirilen veriler için karar
Aşağıdaki örnekte, karardaki önemli sinyaller vurgulanmaktadır.
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
PREMISE_PROXIMITY Ayrıntı
düzeyi, bina düzeyindeki bir adresin yaklaşık değerini gösterir ancak giriş sırasında sağlanan ayrıntı düzeyi olan SUB_PREMISE kadar ayrıntılı değildir. Yanıt, hem onaylanmamış hem de değiştirilmiş bileşenler içerdiğinden kombinasyon, onaylama kategorisine girer.
Adres bileşenleriyle ilgili bir sorgu, aşağıdaki endişe alanlarını ortaya çıkarır:
{
"componentName": {
"text": "451",
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
"componentName": {
"text": "98104",
},
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
}
...
{
"componentName": {
"text": "Building D",
"language_code": "en"
},
"componentType": "subpremise",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......
"unconfirmedComponentTypes": [
"street_number",
"subpremise"
]
Bu durumda, Address Validation API, sağlanan adrese Seattle'da yakın bir alternatif buldu ve daha üst düzey bir bileşen olan posta kodunu Seattle adresine çözmek için değiştirdi. Bu, geçerli bir değiştirme olabilir ancak bileşenlerin onaylanmamış olmasıyla birlikte kullanıcının Seattle adresi girmek istediğinden ve Kirkland gibi başka bir adres girmek istemediğinden emin olmak mantıklıdır.
Uç durum örnekleri: onaylama
Aşağıdaki örneklerde aşağıdaki uç nokta türleri gösterilmektedir:
- ONAYLANAN küçük çıkarımlar. Adres Doğrulama API'si ülke, posta kodu veya eyaleti çıkarır ancak diğer tüm bilgiler hem sağlanır hem de onaylanır. Hem ayrıntı düzeyinin hem de onay düzeyinin birleşimi, onay işlemi gerektirmeyen küçük bir çıkarım oluşturur.
- Beklenmeyen adres bileşeni ONAYLANMADI. Onaylanmamış adres bileşenleri, adresin risk düzeyini artırır. Bu, onay gerektirebilir.
- DOĞRULANAN beklenmeyen adres bileşeni. Bileşen, doğru bir adres için kesinlikle gerekli değildir ve Address Validation API'si bunu çıkıştan kaldırır. Biçimlendirme sorunları genellikle onay gerektirmez.
DOĞRULANAN küçük çıkarımlar
Daha ayrıntılı düzeydeki onaylanmış verilerle birleştirildiğinde, giriş yalnızca aşağıdaki türlerden birinin bileşenini içermiyorsa API yine de doğru çıkarım yapabilir:
- Şehir
- Eyalet
- Posta kodu
- Ülke
Örneğin, bir müşteri Springfield, Massachusetts'teki bir McDonald's restoranı için geçerli bir sokak adresi giriyor ancak şehri girmeyi unutuyor ve 4 haneli uzantısı olmayan bir posta kodu giriyor.
| Girilen adres | Bölge |
|---|---|
| 1402 Allen St, MA 01118 | ABD |
Eksik şehir için karar
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
Address Validation API'nin teslim edilebilir bir adres oluşturmak için daha üst düzey bileşenleri tahmin ettiği durumlarda, sistemdeki verilerin doğru olduğuna dair daha yüksek bir güven düzeyine sahip olabilirsiniz. Bunun nedeni, geniş bir coğrafi bölgeyi temsil eden çıkarılmış bileşenlerin, daha ayrıntılı olan onaylanmış adres bileşenleriyle daha kolay eşleştirilmesidir. ABD'deki Springfield gibi şehir adlarının tekrarlandığı ülkelerde bile, diğer bileşenler birleştirilerek benzersiz bir adres oluşturulabilir.
Yukarıdaki örneğimizi kullanarak tüm adres bileşenleri üzerinde yapılan bir tarama, her bileşenin onaylandığını (yani Adres Doğrulama API'si tarafından depolanan verilerle eşleştiğini) ve hizmetin iki üst düzey bileşeni de çıkardığını gösterir.
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
Beklenmeyen adres bileşeni DOĞRULANMADI
Bu senaryo, bileşenlerin onaylanmadığı zaman kontrol etmenin önemini gösterir. Bir adres bileşeni beklenmiyorsa Adres Doğrulama API'si bu bileşeni çıkıştan kaldırır. Bu durumlarda, risk seviyenize ve güven seviyenize bağlı olarak adresi kabul edebilir veya müşteriye yeniden onaylatabilirsiniz.
Örneğin, bir adres, müşterilerin genellikle posta idaresi tarafından göz ardı edilen zararsız bilgiler girdiği bir bölgeden olabilir. Bu durumda adresi kabul edersiniz. Ancak bazı durumlarda, onaylanmamış bir bileşen müşterinin istediği bileşen olmayabilir.
| Girilen adres | Bölge |
|---|---|
| 1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry | Fransa |
Beklenmeyen adres bileşeni için karar onaylanmadı
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
Adres Doğrulama API'si, doğrulanmamış bileşenler içeren bir değerlendirmenin yanı sıra aşağıdaki biçimlendirilmiş adresi de döndürür:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
Onaylanmamış bileşenler için yapılan taramada, API'nin döndürülen adresten la caritat 2'yi kaldırdığı gösteriliyor:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
DOĞRULANMIŞ beklenmeyen adres bileşeni
Bu örnekte, sağlanan adrese Birleşik Krallık'taki bir idari bölgenin dahil edilmesi gösterilmektedir. Bu, yaygın bir uygulamadır. Ancak bu, Birleşik Krallık posta idaresinin bir şartı değildir ve genellikle göz ardı edilir. postoffice.co.uk ve Birleşik Krallık ve uluslararası postaların nasıl adresleneceği başlıklı makaleleri inceleyin.
Bu nedenle, Birleşik Krallık adresinde ilçe bilgisi sağlayan müşteriler için hizmet, bu bilgiyi beklenmedik bir giriş olarak değerlendirir.
| Girilen adres | Bölge |
|---|---|
| 33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | Birleşik Krallık |
DOĞRULANAN beklenmedik adres bileşeni için karar
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
Burada address_complete yanlış olarak değerlendirilir ve adres bileşeninin analizi beklenmedik bir işaret ortaya çıkarır.
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
Gloucestershire, girilen adres için doğru ilçe olsa da adresin kendisi yanlış biçimlendirilmiş. Adres Doğrulama API'sinin bilgileri uygun biçimlendirme açısından da değerlendirdiğini unutmayın.