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

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

आम तौर पर, एपीआई से मिली जानकारी से यह तय होता है कि आपके सिस्टम को पते को किस तरह मैनेज करना चाहिए:

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

मुख्य मकसद

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

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 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 के अलावा अन्य टाइप शामिल हैं, तो कार्रवाई, पता ठीक करने की कैटगरी में आएगी. Geocoding के दस्तावेज़ में, पते के टाइप की पूरी सूची देखें.

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

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

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

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

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

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

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

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

अच्छी क्वालिटी वाले पते के लिए, यह जानकारी भी दी जानी चाहिए:

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

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

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

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

स्वीकार किए जाने वाले पतों के उदाहरण