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

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

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

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

मुख्य मकसद

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

वर्कफ़्लो

  1. अगर ज़रूरी हो, तो पते के कॉम्पोनेंट की जांच करें.
  2. खरीदार को पते से जुड़ी समस्याएं ठीक करने के लिए कहें.
  3. अपडेट किए गए पते की पुष्टि करने का अनुरोध करें.
  4. पते के साथ आगे बढ़ें.

नतीजे के सिग्नल

इनमें से कोई भी स्थिति लागू हो:
पते की पुष्टि करें

verdict से मिले जवाब से पता चलता है कि पता डिलीवर करने लायक है. हालांकि, इसमें ओरिजनल इनपुट में बदलाव किए गए हैं: ऐसे डेटा का अनुमान लगाना जिसकी स्पेलिंग सही की गई है या जिसकी पुष्टि की जा सकती है.

वर्कफ़्लो

  1. इनमें सुधार करना ज़रूरी है:
    1. अगर ज़रूरी हो, तो पते के कॉम्पोनेंट की जांच करें.
    2. अपडेट किए गए पते की पुष्टि करने का अनुरोध करें.
    3. पते के साथ आगे बढ़ें.
  2. कोई बदलाव करने की ज़रूरत नहीं है:
  3. पते के साथ आगे बढ़ें.

नतीजे के सिग्नल

ये सभी शर्तें लागू होती हैं:
पता स्वीकार करें

Address Validation API से मिले जवाब से पता चलता है कि पते की क्वालिटी बहुत अच्छी है.

वर्कफ़्लो

नतीजे में मिले पते का इस्तेमाल करें.

नतीजे के सिग्नल

ये सभी शर्तें लागू होती हैं:

  • validationGranularity में PREMISE या इससे बेहतर वर्शन है.
  • addressComplete true है.
  • अनुमानित या बदले गए कॉम्पोनेंट नहीं हैं.

लागू करने के लिए सलाह

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

सलाह जानकारी
जोखिम का स्तर

सुधारों के लिए प्रॉम्प्ट देने और डाले गए पते को स्वीकार करने के बीच संतुलन बनाते समय, अपनी स्थिति के लिए सहनशीलता के लेवल को ध्यान में रखें.

Address Validation 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 के बारे में ज़्यादा जानने के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.
Address response इसमें missingComponentTypes फ़ील्ड शामिल है, जिसकी वैल्यू subpremise है.

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

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

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

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

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

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

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

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

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

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

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

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

dpvConfirmation Y

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

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