पुष्टि करने का लॉजिक बनाना

इस दस्तावेज़ में, पते की जांच करने वाला सिस्टम बनाने का तरीका बताया गया है. इससे Address Validation API से मिलने वाले अलग-अलग जवाबों को मैनेज किया जा सकता है. इसमें बताया गया है कि जवाब का सही तरीके से इस्तेमाल करने के लिए, लॉजिक कैसे बनाया जाए. साथ ही, एपीआई से मिलने वाले अन्य सिग्नल की जांच कैसे की जाए. इसके अलावा, इसमें यह भी बताया गया है कि ग्राहकों से ज़्यादा जानकारी कब और कैसे मांगी जाए.

आम तौर पर, एपीआई से मिले जवाब के आधार पर यह तय होता है कि आपका सिस्टम किसी पते को इन तरीकों से हैंडल करे:

• ठीक करें—पता खराब क्वालिटी का है. आपको ज़्यादा जानकारी के लिए प्रॉम्प्ट करना चाहिए.
• पुष्टि करें—पता अच्छी क्वालिटी का है, लेकिन इसमें इनपुट किए गए पते से कुछ बदलाव किए गए हैं. पुष्टि करने के लिए कहा जा सकता है.
• स्वीकार करें—पता अच्छी क्वालिटी का है. आपके पास दिए गए पते को स्वीकार करने का विकल्प होता है.

मुख्य मकसद

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

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

सटीक लॉजिक आपकी स्थिति पर निर्भर करता है. ज़्यादा जानकारी के लिए, लागू करने के बारे में दिशा-निर्देश देखें. इस लॉजिक के ओपन सोर्स वर्शन का भी इस्तेमाल किया जा सकता है. यह Extended Component Library में मौजूद है.

वर्कफ़्लो के बारे में खास जानकारी

नीचे दी गई टेबल में, आपके सिस्टम के लिए दो कार्रवाइयों की खास जानकारी दी गई है:

1. इस्तेमाल करने का वर्कफ़्लो, गड़बड़ी ठीक करने, पुष्टि करने, और स्वीकार करने के तरीके पर आधारित होता है.
2. जवाब से, पहले सिग्नल की जांच करना. यहां बताए गए सिग्नल, verdict प्रॉपर्टी से मिलते हैं. ये सिर्फ़ सिग्नल नहीं हैं, बल्कि इनसे पते की क्वालिटी का शुरुआती इंडिकेटर मिलता है. हर तरह के व्यवहार के लिए, इस दस्तावेज़ में एक सेक्शन दिया गया है. इसमें ऐसे अन्य सिग्नल के बारे में बताया गया है जिनकी आपको जांच करनी पड़ सकती है.

आपके सिस्टम का व्यवहार
पता ठीक करें	verdict से मिले जवाब में, ज़रूरी जानकारी मौजूद नहीं है. यह जानकारी दी जानी चाहिए. ऐसा हो सकता है कि एपीआई से मिला पता, डिलीवरी के लिए सही न हो. वर्कफ़्लो अगर ज़रूरी हो, तो पते के कॉम्पोनेंट की जांच करें. ग्राहक को पते से जुड़ी समस्याएं ठीक करने के लिए प्रॉम्प्ट करें. अपडेट किए गए पते की पुष्टि करने का अनुरोध करें. पते की पुष्टि करने की प्रोसेस जारी रखें. नतीजे के सिग्नल इनमें से कोई भी स्थिति लागू होती हो: validationGranularity को OTHER पर सेट करें. addressComplete false है.
पते की पुष्टि करें	verdict से मिले जवाब में, डिलीवरी का पता दिया गया है. हालांकि, इसमें ओरिजनल इनपुट में बदलाव किया गया है. जैसे, स्पेलिंग ठीक करके या पुष्टि किए जा सकने वाले डेटा का अनुमान लगाकर. वर्कफ़्लो बदलाव ज़रूरी हैं: अगर ज़रूरी हो, तो पते के कॉम्पोनेंट की जांच करें. अपडेट किए गए पते की पुष्टि करने का अनुरोध करें. पते की पुष्टि करने की प्रोसेस जारी रखें. कोई सुधार करने की ज़रूरत नहीं है: पते की पुष्टि करने की प्रोसेस जारी रखें. नतीजे के सिग्नल ये सभी शर्तें लागू होती हैं: validationGranularity में ROUTE शामिल है addressComplete true है. hasInferredComponents फ़ील्ड true है या hasReplacedComponents फ़ील्ड true है.
पता स्वीकार करें	Address Validation API से मिले जवाब में, पते को बहुत अच्छी क्वालिटी वाला बताया गया है. वर्कफ़्लो सामान लौटाने के पते का इस्तेमाल करें. नतीजे के सिग्नल ये सभी शर्तें लागू होती हैं: validationGranularity में PREMISE या इससे बेहतर क्वालिटी का कॉन्टेंट शामिल हो. addressComplete true है. नहीं, कोई भी कॉम्पोनेंट नहीं बदला गया है.

लागू करने के लिए दिशा-निर्देश

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

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

डेमो आज़माएं. इस दस्तावेज़ में आगे, कई उदाहरण दिए गए हैं. इनसे आपको ऊपर बताई गई समस्या को ठीक करने, पुष्टि करने, और स्वीकार करने की प्रोसेस को समझने में मदद मिलेगी. इन उदाहरणों के नतीजे देखने के लिए, उन्हें Maps JavaScript API के पते की पुष्टि करने वाले डेमो में डालें.

किसी पते को ठीक करना

अगर नतीजों से साफ़ तौर पर पता चलता है कि पते पर डिलीवरी नहीं की जा सकती, तो पते को ठीक करें. इसके बाद, आपका सिस्टम खरीदार को ज़रूरी जानकारी देने के लिए कहेगा. इसके बाद, आपको अपना वर्कफ़्लो फिर से जारी करना होगा, ताकि डिलीवरी का पता मिल सके.

सिग्नल ठीक करना

Address Validation API कई सिग्नल देता है. इनसे आपको यह पता चलता है कि किसी पते में सुधार करने की ज़रूरत है या नहीं.

1. पुष्टि करने की बारीकी और कॉम्पोनेंट मौजूद न होना

ये दो सिग्नल, किसी पते के गलत होने की सबसे सही जानकारी देते हैं:

• जब भी validationGranularity फ़ील्ड OTHER हो, तब आपके सिस्टम को पते के कॉम्पोनेंट के सिग्नल की जांच करनी चाहिए. इससे यह पता चलेगा कि गड़बड़ी कहां हुई है और उसे कैसे ठीक किया जा सकता है.
• जब भी पोस्ट-प्रोसेस किए गए address ऑब्जेक्ट से missingComponentTypes फ़ील्ड मिलता है, तब आपके सिस्टम को उस कॉम्पोनेंट की जांच करनी चाहिए. पते में ज़रूरी कॉम्पोनेंट न होने पर, उसे अधूरा माना जाता है. साथ ही, उस पते पर डिलीवरी नहीं की जा सकती.

2. पेज के लिए सही ऑडियंस तय करने के दूसरे तरीके

Address Validation API, कुछ खास समस्याओं का पता लगाने में मदद करने के लिए अन्य सिग्नल भी उपलब्ध कराता है:

संदिग्ध कॉम्पोनेंट	जब किसी कॉम्पोनेंट के लिए पुष्टि करने का लेवल enum UNCOMFIRMED_AND_SUSPICIOUS होता है, तो हो सकता है कि कॉम्पोनेंट गलत हो.
अनसुलझा कॉम्पोनेंट	unresolvedToken इनपुट का वह हिस्सा होता है जिसे पते के मान्य हिस्से के तौर पर नहीं पहचाना जाता.

3. अमेरिका के पते के सिग्नल

अमेरिका के पतों के लिए लागू होने वाले कुछ फ़ील्ड, यह अहम सिग्नल देते हैं कि पते पर सामान डिलीवर नहीं किया जा सकता. इसलिए, इसे ठीक किया जाना चाहिए. जिस पते को ठीक करने की ज़रूरत है उसके लिए, आपको यह दिखेगा:

dpvConfirmation	N, D या खाली होना चाहिए.

dpvConfirmation के बारे में ज़्यादा जानने के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.

पते ठीक करने के उदाहरण

किसी पते की पुष्टि करना

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

ग्राहक को सही प्रॉम्प्ट देने के लिए, आपका लॉजिक उन कॉम्पोनेंट की पहचान करेगा जिन्हें सेवा ने फ़्लैग किया है. इससे यह तय किया जा सकेगा कि एपीआई ने कॉम्पोनेंट पर कौनसी कार्रवाई की है या उसे फ़्लैग किया है. जैसे, inferred, replaced या spellCorrected. रेफ़रंस में AddressComponent देखें.

ध्यान दें: यह तय करते समय कि आपको खरीदार से पते की पुष्टि करनी है या उसे मान्य के तौर पर स्वीकार करना है, अपने जोखिम के लेवल को ध्यान में रखें.

सिग्नल की पुष्टि करना

Address Validation API कई सिग्नल देता है. इनसे आपको यह पता चलता है कि किसी पते की पुष्टि की जानी चाहिए या नहीं.

1. पुष्टि करने की बारीकी

ROUTE या इससे बेहतर validationGranularity स्वीकार किया जाता है. हालांकि, PREMISE या SUBPREMISE से डिलीवरी की संभावना का बेहतर सिग्नल मिलता है.

2. पेज के लिए सही ऑडियंस तय करने के दूसरे तरीके

ग्राहक से पते की पुष्टि करने का फ़ैसला करते समय, फ़ैसले में यह जानकारी भी दी जाती है. इससे यह तय करने में मदद मिलती है कि किन कॉम्पोनेंट की जांच करनी है:

अनुमानित डेटा	जब hasInferredComponents फ़ील्ड true होता है, तो इसका मतलब है कि एपीआई ने पते के अन्य कॉम्पोनेंट से मिली जानकारी को भरा है.
बदला गया डेटा	जब hasReplacedComponents फ़ील्ड true होता है, तब एपीआई, डाले गए डेटा को उस डेटा से बदल देता है जिसे वह पते को मान्य बनाने के लिए ज़रूरी मानता है.

3. अमेरिका के पते के सिग्नल

अमेरिका के पतों के लिए लागू होने वाले कुछ फ़ील्ड से पता चलता है कि आपके लॉजिक को खरीदार से जानकारी की पुष्टि करनी चाहिए. इनमें से कोई एक शर्त लागू होती है:

dpvConfirmation	S dpvConfirmation के बारे में ज़्यादा जानने के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.
पते की जानकारी	इसमें missingComponentTypes फ़ील्ड में subpremise वैल्यू शामिल है. ध्यान दें: अगर फ़ील्ड में subpremise के अलावा अन्य टाइप शामिल हैं, तो कार्रवाई को पते में सुधार करने की कैटगरी में रखा जाएगा. जियोकोडिंग के दस्तावेज़ में, पते के टाइप की पूरी सूची देखें.

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

पता स्वीकार करना

किसी पते को तब स्वीकार किया जाता है, जब यह पक्का हो कि उस पते पर सामान डिलीवर किया जा सकता है. साथ ही, डाउनस्ट्रीम प्रोसेस में ग्राहक से संपर्क किए बिना उस पते का इस्तेमाल किया जा सकता है.

सिग्नल स्वीकार करना

Address Validation API कई सिग्नल देता है. इनसे आपको यह पता चलता है कि किसी पते की पुष्टि की जानी चाहिए या नहीं.

1. पुष्टि करने की बारीकी

PREMISE या इससे बेहतर validationGranularity स्वीकार किया जाता है. हालांकि, कुछ मामलों में ROUTE का मतलब अब भी यह होता है कि पते पर डिलीवरी की जा सकती है.

2. पेज के लिए सही ऑडियंस तय करने के दूसरे तरीके

अच्छी क्वालिटी वाले पते के लिए दिए गए फ़ैसले में यह जानकारी भी शामिल होनी चाहिए:

• बदला गया कोई डेटा नहीं है. इस मामले में, hasReplacedComponents: FALSE.
• कोई अनुमानित कॉम्पोनेंट नहीं है. इस मामले में, hasInferredComponents: FALSE.

3. अमेरिका के पते के सिग्नल

अमेरिका के पतों के लिए लागू होने वाले कुछ फ़ील्ड से, अच्छी क्वालिटी वाले पते का पता चलता है. इस पते पर डिलीवरी की जा सकती है. अमेरिका का मान्य पता होने पर, आपको यह जानकारी दिखेगी:

dpvConfirmation	Y dpvConfirmation के बारे में ज़्यादा जानकारी के लिए, अमेरिका के पते मैनेज करना लेख पढ़ें.

पते के उदाहरण स्वीकार करना