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

इस दस्तावेज़ में, पते की जांच करने वाला सिस्टम बनाने की प्रोसेस के बारे में बताया गया है. इससे 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.

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

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

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

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 डेमो में डालकर, नतीजे देखे जा सकते हैं.

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

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

सिग्नल से जुड़ी समस्याएं ठीक करना

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

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

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

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

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

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

संदिग्ध कॉम्पोनेंट	जब किसी कॉम्पोनेंट के लिए पुष्टि के लेवल का एनम 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 होता है, तब API, डाले गए डेटा को उस डेटा से बदल देता है जिसे वह पते को मान्य बनाने के लिए ज़रूरी मानता है.

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

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

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

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

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

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

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

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

1. पुष्टि करने की सुविधा का लेवल

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

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

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

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

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

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

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

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