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

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

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

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

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

Address Validation API, कई सिग्नल उपलब्ध कराता है. इनसे यह पता चलता है कि किसी पते को ठीक किया जाना चाहिए या नहीं.

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

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

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

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

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

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

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

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

dpvConfirmation	N, D या खाली.

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

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

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

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

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

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

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

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

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

validationGranularity की वैल्यू ROUTE या इससे बेहतर होने पर, उसे स्वीकार किया जा सकता है. हालांकि, PREMISE या SUBPREMISE की वैल्यू होने पर, डिलीवरी की पुष्टि करने वाला ज़्यादा सटीक सिग्नल मिलता है.

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

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

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

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

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

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

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

किसी पते को स्वीकार करना

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

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

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

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

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

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

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

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

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

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

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

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