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ış başlıklı makaleyi inceleyin.
Yaygın örnekler: onaylama
Aşağıdaki örnekte, benzer sokak adlarına sahip metropol alanlar gösterilmektedir. Bir kullanıcının ABD'nin Kirkland, Washington eyaletindeki 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 bu kombinasyon, ipucunu onayla kategorisine yönlendiriyor.
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, Adres Doğrulama API'si, sağlanan adrese Seattle'da yakın bir yaklaşım buldu ve daha üst düzey bir bileşen olan posta kodunu Seattle adresiyle 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.
Sıra dışı durum örnekleri: onaylama
Aşağıdaki örneklerde şu uç nokta türleri gösterilmektedir:
- ONAYLANAN küçük çıkarımlar. Adres Doğrulama API, ülke, posta kodu veya eyaleti tahmin eder ancak diğer tüm bilgiler hem sağlanır hem de onaylanır. Hem ayrıntı düzeyi 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 durumda onay gerekebilir.
- DOĞRULANAN beklenmedik adres bileşeni. Bileşen, doğru bir adres için kesinlikle gerekli değildir ve Adres Doğrulama 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üzeyde onaylanmış verilerle birleştirildiğinde, giriş yalnızca aşağıdaki türlerden bir bileşeni 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
}
Adres Doğrulama API'sinin, 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 fazla güven duyabilirsiniz. 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ı gösterir. Bu, bileşenlerin Adres Doğrulama API'si tarafından depolanan verilerle eşleştiği ve hizmetin iki üst düzey bileşeni de çıkardığı anlamına gelir.
{
"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 bunu çı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ğerlendirmeye ek olarak 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Ş olan beklenmedik adres bileşeni
Bu örnekte, sağlanan adrese Birleşik Krallık'taki bir ilçenin 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, bir müşteri Birleşik Krallık adresinde ilçe bilgisi verdiğinde hizmet bunu beklenmedik bir giriş olarak değerlendirir.
| Girilen adres | Bölge |
|---|---|
| 33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | Birleşik Krallık |
ONAYLANAN beklenmedik adres bileşeni için karar
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
Burada address_complete işlevinin sonucu yanlış (false) ve adres bileşeninin analizi beklenmedik bir işaret ortaya çıkarıyor.
{
"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.