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

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

वर्कफ़्लो

  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, कुछ खास समस्याओं का पता लगाने में मदद करने के लिए अन्य सिग्नल भी उपलब्ध कराता है:

संदिग्ध कॉम्पोनेंट जब किसी कॉम्पोनेंट के लिए पुष्टि के लेवल का एनम 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 है.

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

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

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

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

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

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

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

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

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

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

3. अमेरिका में मौजूद पते के सिग्नल

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

dpvConfirmation Y

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

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