पते की पुष्टि करें - उदाहरण

इस दस्तावेज़ में, ऐसे कई उदाहरण दिए गए हैं जिनमें Address Validation API, ऐसे पतों के लिए जवाब के सिग्नल देता है जिनके लिए आपके सिस्टम को confirm व्यवहार की ज़रूरत होती है. यहां दिए गए उदाहरण सिर्फ़ जानकारी देने के लिए हैं. इनके अलावा, और भी उदाहरण हो सकते हैं. ज़्यादा जानकारी के लिए, पुष्टि करने का लॉजिक तैयार करना में वर्कफ़्लो की खास जानकारी देखें.

सामान्य उदाहरण: पुष्टि करें

यहां दिए गए उदाहरण में, एक जैसे नाम वाली सड़कों वाले महानगरों के बारे में बताया गया है. मान लीजिए कि किसी उपयोगकर्ता को Google Building D in Kirkland, WA, United States का पता डालना है. हालांकि, शहर के तौर पर किर्कलैंड की जगह, वे गलती से सिऐटल डाल देते हैं.

पता डाला गया क्षेत्र
Building D, 451 7th Avenue South, Seattle, WA 98033 अमेरिका

बदले गए डेटा के लिए फ़ैसला

नीचे दिए गए उदाहरण में, फ़ैसले से मिले अहम सिग्नल पर ज़ोर दिया गया है.

{
  "inputGranularity": "SUB_PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete": true,
  "hasUnconfirmedComponents": true
  "hasReplacedComponents": true
}

PREMISE_PROXIMITY बारीकी के लेवल से, इमारत के लेवल के पते की अनुमानित जानकारी मिलती है. हालांकि, यह SUB_PREMISE जितनी ज़्यादा जानकारी नहीं देता. SUB_PREMISE, इनपुट के आधार पर बारीकी से जानकारी देता है. जवाब में, पुष्टि नहीं किए गए और बदले गए दोनों कॉम्पोनेंट शामिल हैं. इसलिए, इन दोनों कॉम्पोनेंट के कॉम्बिनेशन की वजह से, इस जवाब को पुष्टि करें कैटगरी में रखा गया है.

पते के कॉम्पोनेंट की क्वेरी से, इन समस्याओं के बारे में पता चलता है:

{
  "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"
    ]

इस मामले में, Address Validation API को दिए गए पते सिऐटल के आस-पास का पता मिला. इसलिए, उसने ज़िप कोड को बदल दिया. ज़िप कोड, पते का एक बड़ा कॉम्पोनेंट होता है. ऐसा इसलिए किया गया, ताकि सिऐटल का पता मिल सके. यह एक मान्य बदलाव हो सकता है. हालांकि, कॉम्पोनेंट की पुष्टि नहीं हुई है. इसलिए, यह ज़रूरी है कि उपयोगकर्ता को सिएटल का पता डालना हो, न कि कोई और पता, जैसे कि किर्कलैंड.

कभी-कभार होने वाले मामलों के उदाहरण: पुष्टि करना

यहां दिए गए उदाहरणों में, इन तरह के मुश्किल मामलों के बारे में बताया गया है:

ऐसे छोटे-मोटे अनुमान जिनकी पुष्टि की गई है

ज़्यादा बारीकी से पुष्टि किए गए डेटा के साथ इस्तेमाल करने पर, एपीआई अब भी सही अनुमान लगा सकता है. ऐसा तब होता है, जब इनपुट में सिर्फ़ एक कॉम्पोनेंट मौजूद न हो:

  • शहर
  • राज्य
  • पिन कोड
  • देश

उदाहरण के लिए, किसी खरीदार ने स्प्रिंगफ़ील्ड, मैसाचुसेट्स में मौजूद McDonald's रेस्टोरेंट का मान्य सड़क पता दिया है. हालांकि, वह शहर का नाम डालना भूल गया है. साथ ही, उसने चार अंकों वाले एक्सटेंशन के बिना पिन कोड दिया है.

पता डाला गया क्षेत्र
1402 ऐलन स्ट्रीट, मैसाचुसेट्स 01118 अमेरिका

शहर की जानकारी मौजूद न होने पर फ़ैसला

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true,
  "hasInferredComponents": true
}

कुछ मामलों में, Address Validation API, डिलीवरी के लिए पते की जानकारी जनरेट करने के लिए, ज़्यादा सटीक कॉम्पोनेंट का अनुमान लगाता है. ऐसे में, आपको सिस्टम से मिले डेटा पर ज़्यादा भरोसा हो सकता है. ऐसा इसलिए होता है, क्योंकि अनुमानित पते के कॉम्पोनेंट, पुष्टि किए गए पते के कॉम्पोनेंट से ज़्यादा आसानी से मैच हो जाते हैं. अनुमानित पते के कॉम्पोनेंट, किसी बड़े भौगोलिक इलाके को दिखाते हैं, जबकि पुष्टि किए गए पते के कॉम्पोनेंट, किसी छोटे भौगोलिक इलाके को दिखाते हैं. जिन देशों में शहरों के नाम दोहराए जाते हैं वहां भी, पते के अन्य कॉम्पोनेंट के साथ शहर का नाम जोड़ने पर, एक यूनीक पता मिल सकता है. जैसे, अमेरिका में स्प्रिंगफ़ील्ड नाम के कई शहर हैं.

ऊपर दिए गए उदाहरण का इस्तेमाल करके, पते के सभी कॉम्पोनेंट को स्कैन करने पर पता चलता है कि हर कॉम्पोनेंट की पुष्टि हो गई है. इसका मतलब है कि यह Address Validation API में सेव किए गए डेटा से मेल खाता है. साथ ही, सेवा दो उच्च-स्तरीय कॉम्पोनेंट का भी अनुमान लगाती है.

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

पते के ऐसे कॉम्पोनेंट की पुष्टि नहीं हुई है जो उम्मीद के मुताबिक नहीं है

इस उदाहरण से पता चलता है कि कॉम्पोनेंट की पुष्टि नहीं होने पर, उसकी जांच करना कितना ज़रूरी है. अगर कोई पता कॉम्पोनेंट उम्मीद के मुताबिक नहीं है, तो Address Validation API उसे आउटपुट से हटा देता है. ऐसे मामलों में, आपके पास पते को स्वीकार करने या ग्राहक से इसकी पुष्टि करने का विकल्प होता है. यह आपके जोखिम के स्तर और भरोसे के स्तर पर निर्भर करता है.

उदाहरण के लिए, हो सकता है कि पता किसी ऐसे इलाके का हो जहां खरीदार अक्सर ऐसी जानकारी डालते हैं जिसे डाक विभाग अनदेखा कर देता है. ऐसे मामले में, आपको पता स्वीकार करना होगा. हालांकि, कुछ मामलों में ऐसा हो सकता है कि पुष्टि न किए गए कॉम्पोनेंट से ग्राहक को वह जानकारी न मिले जो उसे चाहिए.

पता डाला गया क्षेत्र
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry फ़्रांस

पते के अनपेक्षित कॉम्पोनेंट के लिए फ़ैसले की पुष्टि नहीं हुई

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "unconfirmedComponents": true
}

Address Validation API, पुष्टि नहीं किए गए कॉम्पोनेंट के साथ नतीजा देने के अलावा, इस फ़ॉर्मैट में पता भी दिखाता है:

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

पुष्टि न किए गए कॉम्पोनेंट के लिए किए गए स्कैन से पता चलता है कि एपीआई ने, लौटाए गए पते से la caritat 2 को हटा दिया है:

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

पते का ऐसा कॉम्पोनेंट जिसकी पुष्टि हो चुकी है, लेकिन वह अनचाहा है

इस उदाहरण में, दिए गए पते में यूके के काउंटी को शामिल किया गया है. ऐसा आम तौर पर किया जाता है. हालांकि, यूके की डाक सेवा के लिए यह ज़रूरी नहीं है और इसे अनदेखा कर दिया जाता है. postoffice.co.uk और यूके और अंतरराष्ट्रीय मेल को कैसे पता लिखा जाता है लेख पढ़ें.

इसलिए, जब कोई खरीदार यूनाइटेड किंगडम के पते में काउंटी की जानकारी देता है, तो सेवा इसे अनचाहे इनपुट के तौर पर देखती है.

पता डाला गया क्षेत्र
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP यूके

पुष्टि किए गए पते के अनपेक्षित कॉम्पोनेंट के लिए फ़ैसला

{
   "inputGranularity": "PREMISE",
   "validationGranularity": "PREMISE",
   "geocodeGranularity": "PREMISE"
}

यहां, address_complete की वैल्यू गलत है. साथ ही, पते के कॉम्पोनेंट का विश्लेषण करने पर, एक अनचाहा फ़्लैग दिखता है.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

डाला गया पता ग्लॉस्टरशायर का है, लेकिन इसका फ़ॉर्मैट सही नहीं है. याद रखें कि Address Validation API, सही फ़ॉर्मैट के लिए भी जानकारी का आकलन करता है.