इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

यहां दिए गए उदाहरण में, एक जैसे नाम वाली सड़कों वाले महानगरों के बारे में बताया गया है. मान लीजिए कि किसी उपयोगकर्ता को 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,
  "possibleNextAction": "CONFIRM"
}

possibleNextAction से यह शुरुआती जानकारी मिलती है कि आपको खरीदार से पते की पुष्टि करनी चाहिए. फ़ैसले में मौजूद अन्य सिग्नल से, पते में मौजूद गड़बड़ी के बारे में ज़्यादा जानकारी मिलती है. 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 को दिए गए पते के आस-पास का पता मिला है. इसलिए, उसने ज़िप कोड को बदलकर, सिएटल का पता कर दिया. यह एक मान्य विकल्प हो सकता है, लेकिन पुष्टि न किए गए कॉम्पोनेंट के साथ-साथ, यह पक्का करना ज़रूरी है कि उपयोगकर्ता को सिएटल का पता डालना है, न कि कोई और पता, जैसे कि किर्कलैंड.

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

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

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

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

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

शहर
स्थिति
पिन कोड
देश

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

पता डाला गया	क्षेत्र
1402 Allen St, MA 01118	अमेरिका

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

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

कुछ मामलों में, 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 उसे आउटपुट से हटा देता है. ऐसे मामलों में, आपके पास पते को स्वीकार करने या ग्राहक से इसकी पुष्टि करने का विकल्प होता है. यह आपके जोखिम के लेवल और भरोसे के लेवल पर निर्भर करता है.

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

पता डाला गया	क्षेत्र
59 Cherrydown Avenue, Chingford, London E4 8DT	यूनाइटेड किंगडम

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

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

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

"formattedAddress": "59 Cherrydown Avenue, London E4 8DT, UK",

पुष्टि नहीं किए गए कॉम्पोनेंट के लिए किए गए स्कैन से पता चलता है कि एपीआई ने जवाब में मिले पते से Chingford को हटा दिया है:

{
  "componentName": {
    "text": "Chingford",
    "languageCode": "en"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

कार्रवाई: इस मामले में, हो सकता है कि उप-इलाके की जानकारी सही हो. उप-इलाका, रिहायशी ज़िला या आस-पास का इलाका हो सकता है. हालांकि, डाक विभाग इसे अनदेखा कर सकता है. हालांकि, इस जानकारी की पुष्टि Address Validation API से **नहीं** हुई है. इसलिए, आपको खरीदार से इसकी पुष्टि करनी पड़ सकती है. इस समय, आपके पास वीडियो को हटाने की कार्रवाई को अनदेखा करने या इसकी पुष्टि करने का विकल्प होता है.

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

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

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

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

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

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

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

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

यह कॉम्पोनेंट अनचाहा है और इसकी पुष्टि हो चुकी है. इसका मतलब यह है कि:

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

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