इस दस्तावेज़ में, पते की जांच करने वाला सिस्टम बनाने की प्रोसेस के बारे में बताया गया है. इससे Address Validation API से मिलने वाले अलग-अलग जवाबों को मैनेज किया जा सकता है. इसमें यह बताया गया है कि एपीआई से मिले जवाब को कैसे समझा जाए, ताकि यह तय किया जा सके कि आपको अपने ग्राहकों से ज़्यादा जानकारी कब और कैसे मांगनी है.
आम तौर पर, एपीआई से मिले जवाब के आधार पर यह तय होता है कि आपका सिस्टम किसी पते को इन तरीकों से हैंडल करे:
-
ठीक करें—पते में गंभीर समस्याएं हो सकती हैं.
अपने ग्राहक से ज़्यादा जानकारी देने के लिए कहें. -
उप-परिसर जोड़ें—ऐसा हो सकता है कि पते में उप-परिसर की जानकारी मौजूद न हो.
अपने खरीदार को यूनिट नंबर जोड़ने के लिए कहें. -
पुष्टि करें—पते में कुछ समस्याएं हो सकती हैं.
अपने खरीदार से पुष्टि करने के लिए कहें कि पता सही है. -
स्वीकार करें—ऐसा हो सकता है कि पते में कोई समस्या न हो.
बिना किसी और प्रॉम्प्ट के, इस पते का इस्तेमाल अपने जोखिम पर करें.
मुख्य मकसद
इस दस्तावेज़ की मदद से, अपने सिस्टम में बदलाव किया जा सकता है. इससे एपीआई के जवाब का बेहतर तरीके से विश्लेषण किया जा सकेगा. साथ ही, दिए गए पतों के साथ अगली कार्रवाई तय की जा सकेगी. यहां दिए गए स्यूडोकोड में, संभावित फ़्लो दिखाया गया है.
if (verdict.possibleNextAction == FIX)
Prompt the user to fix the address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt the user to add a unit number.
else if (verdict.possibleNextAction == CONFIRM)
Confirm with the user that the address is correct.
else
Continue with the address returned by the API.
लॉजिक आपकी स्थिति के हिसाब से तय होता है. ज़्यादा जानकारी के लिए, पुष्टि करने के लॉजिक को पसंद के मुताबिक बनाएं लेख पढ़ें.
वर्कफ़्लो के उदाहरण
यहां दी गई टेबल में, एपीआई के जवाब के आधार पर ग्राहक को सूचना देने के लिए, लागू किए जा सकने वाले वर्कफ़्लो के उदाहरणों के बारे में खास जानकारी दी गई है.
| आपके सिस्टम का व्यवहार | ||
|---|---|---|
| पता ठीक करें |
|
|
| उप-परिसर जोड़ें |
|
|
| पते की पुष्टि करें |
|
|
| पता स्वीकार करें |
|
|
पुष्टि करने के लॉजिक को पसंद के मुताबिक बनाना
verdict.possibleNextAction फ़ील्ड से मिले नतीजों का इस्तेमाल करके, यह तय किया जा सकता है कि आपका सिस्टम एपीआई रिस्पॉन्स के साथ कैसे आगे बढ़ेगा. हालांकि, कारोबार की खास ज़रूरतों को पूरा करने के लिए, कस्टम लॉजिक बनाने पर भी विचार किया जा सकता है.
इस सेक्शन का मकसद यह दिखाना है कि एपीआई के रिस्पॉन्स को समझने के लिए, कस्टम लॉजिक कैसे डेवलप किया जा सकता है. इससे यह तय किया जा सकता है कि आपको अपने ग्राहक को प्रॉम्प्ट करना है या नहीं और अगर करना है, तो कैसे. इस सेक्शन में, जोखिम के लेवल और अतिरिक्त एपीआई रिस्पॉन्स सिग्नल के बारे में बताया गया है. इनका इस्तेमाल, अपनी पसंद के मुताबिक सेटिंग तय करने के लिए किया जा सकता है.
हालांकि, अगर आपको अगले चरणों के बारे में फ़ैसला लेने के लिए सिर्फ़ verdict.possibleNextAction पर भरोसा करना है, तो भी यहां बताए गए अन्य सिग्नल से आपको पते से जुड़ी संभावित समस्याओं के बारे में जानकारी मिल सकती है.
जोखिम लेने की क्षमता
Address Validation API से मिलने वाले सिग्नल के आधार पर, अपने सिस्टम के जवाब देने के तरीके को डिज़ाइन करते समय, यहां दिए गए सुझावों से आपको ज़्यादा असरदार जवाब देने वाला मॉडल बनाने में मदद मिल सकती है. हालांकि, ये सिर्फ़ सुझाव हैं. इसलिए, ध्यान रखें कि आपको इन्हें अपने कारोबार के मॉडल के हिसाब से लागू करना चाहिए.
| सलाह | जानकारी | |
|---|---|---|
| जोखिम का स्तर |
पते में सुधार करने के लिए प्रॉम्प्ट दिखाने और पते को वैसे ही स्वीकार करने के बीच संतुलन बनाते समय, अपनी स्थिति के हिसाब से तय करें कि आपको कितनी छूट देनी है. |
Address Validation API, कई तरह के सिग्नल दिखाता है. इनका इस्तेमाल, जोखिम के लेवल के साथ किया जा सकता है, ताकि पुष्टि करने की प्रोसेस को ऑप्टिमाइज़ किया जा सके. उदाहरण के लिए, अगर किसी पते में सड़क का ऐसा नंबर है जिसकी पुष्टि नहीं हुई है, तो भी उसे स्वीकार किया जा सकता है. दूसरी ओर, अगर आपके कारोबार के लिए पते की ज़्यादा सटीक जानकारी ज़रूरी है, तो उपयोगकर्ता को प्रॉम्प्ट किया जा सकता है. किसी ऐसे उदाहरण के लिए जो दोनों में से किसी भी कैटगरी में आ सकता है, पते स्वीकार करना - उदाहरण में अमेरिका के बाहर के ऐसे पते के लिए स्ट्रीट नंबर की पुष्टि नहीं हुई है देखें. |
| पते स्वीकार करना |
अगर खरीदार प्रॉम्प्ट का जवाब नहीं देता है, तो अपने सिस्टम को मूल एंट्री स्वीकार करने की अनुमति दें. |
इन मामलों में, ऐसा हो सकता है कि खरीदार ने सिस्टम में मौजूद पते के बजाय कोई दूसरा पता डाला हो. जैसे, नई इमारत का पता. |
जोखिम से बचने वाले चेकआउट फ़्लो का उदाहरण
अगर आपको डिलीवरी के फ़ेल होने का जोखिम कम करना है, तो अपने लॉजिक को पसंद के मुताबिक बनाएं, ताकि खरीदारों को ज़्यादा बार सूचना दी जा सके. उदाहरण के लिए, मुख्य मकसद सेक्शन में बताए गए लॉजिक का इस्तेमाल करने के बजाय, इस लॉजिक का इस्तेमाल किया जा सकता है.
if (verdict.possibleNextAction == FIX or verdict.validationGranularity
== OTHER or verdict.validationGranularity == ROUTE)
Prompt customer to fix their address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
Prompt customer to add a unit number.
else if (verdict.possibleNextAction == CONFIRM or verdict.validationGranularity
== PREMISE_PROXIMITY or verdict.hasSpellCorrectedComponents or
verdict.hasReplacedComponents or verdict.hasInferredComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
आसानी से चेकआउट करने के फ़्लो का उदाहरण
अगर आपको चेकआउट फ़्लो में आने वाली समस्याओं को कम करना है, तो अपने लॉजिक को पसंद के मुताबिक बनाएं, ताकि ग्राहकों को कम बार प्रॉम्प्ट दिखे. उदाहरण के लिए, मुख्य मकसद सेक्शन में बताए गए लॉजिक का इस्तेमाल करने के बजाय, इस लॉजिक का इस्तेमाल किया जा सकता है.
if (verdict.possibleNextAction == FIX)
Prompt customer to fix their address.
else if (verdict.hasReplacedComponents)
Prompt customer to confirm their address.
else
Proceed with the returned address.
सिग्नल ठीक करना
अगर नतीजों से साफ़ तौर पर पता चलता है कि पते पर डिलीवरी नहीं की जा सकती, तो पते को ठीक करें. इसके बाद, आपका सिस्टम खरीदार को ज़रूरी जानकारी देने के लिए कहेगा. इसके बाद, आपको अपना वर्कफ़्लो फिर से जारी करना होगा, ताकि आपको डिलीवरी का पता मिल सके.
Address Validation API के रिस्पॉन्स में मौजूद इन फ़ील्ड का इस्तेमाल, verdict.possibleNextAction के साथ-साथ यह पता लगाने के लिए किया जा सकता है कि किसी पते में कोई बड़ी समस्या है या नहीं. साथ ही, यह भी पता लगाया जा सकता है कि वे समस्याएं क्या हैं.
| पुष्टि के लिए ज़रूरी आमदनी का थ्रेशोल्ड | जब किसी पते के लिए, पुष्टि करने की बारीकी से जुड़ी enum वैल्यू OTHER होती है, तो इसका मतलब है कि पता गलत है.
|
|---|---|
| कॉम्पोनेंट मौजूद नहीं हैं | अगर address.missingComponentTypes खाली नहीं है, तो हो सकता है कि पते में ज़रूरी जानकारी मौजूद न हो.
|
| संदिग्ध कॉम्पोनेंट | जब किसी कॉम्पोनेंट के लिए पुष्टि के लेवल का enum UNCONFIRMED_AND_SUSPICIOUS होता है, तो हो सकता है कि कॉम्पोनेंट गलत हो.
|
| अनसुलझे कॉम्पोनेंट | unresolvedToken इनपुट का वह हिस्सा होता है जिसे पते के मान्य हिस्से के तौर पर नहीं पहचाना जाता. |
| USPS DPV की पुष्टि | जब uspsData.dpvConfirmation की वैल्यू N हो या वह खाली हो, तो पते में कोई समस्या हो सकती है. यह फ़ील्ड सिर्फ़ अमेरिका के पतों के लिए उपलब्ध है. uspsData.dpvConfirmation के बारे में ज़्यादा जानने के लिए,
अमेरिका के पतों को मैनेज करना लेख पढ़ें.
|
CONFIRM_ADD_SUBPREMISES सिग्नल (सिर्फ़ अमेरिका के पतों के लिए)
जब Address Validation API के जवाब से पता चलता है कि पते में सबप्रीमाइसेस की जानकारी मौजूद नहीं है, तो अपने ग्राहक से पते की समीक्षा करने के लिए कहें. साथ ही, यूनिट नंबर जोड़ने के लिए कहें. इन मामलों में, building का पता शायद मान्य हो, लेकिन आपको यह पक्का करना है कि नतीजे में मिला पता वही है जो खरीदार ने दिया है.
verdict.possibleNextAction के अलावा, Address Validation API के रिस्पॉन्स के इन फ़ील्ड का इस्तेमाल किया जा सकता है. इससे यह पता लगाया जा सकता है कि किसी पते में सब-प्रीमाइसेस की जानकारी मौजूद है या नहीं.
Missing subpremise component
|
अगर address.missingComponentTypes फ़ील्ड में subpremise वैल्यू मौजूद है, तो इसका मतलब है कि पते में यूनिट नंबर मौजूद नहीं है.
|
|---|---|
| USPS DPV की पुष्टि | जब uspsData.dpvConfirmation की वैल्यू S होती है, तो इसका मतलब है कि पते के प्राइमरी नंबर को USPS डेटाबेस में मौजूद किसी पते से मैच किया गया है. हालांकि, पते में दूसरा नंबर भी होना चाहिए. यह फ़ील्ड सिर्फ़ अमेरिका के पतों के लिए उपलब्ध है. uspsData.dpvConfirmation के बारे में ज़्यादा जानकारी के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.
|
उप-इमारत के पते जोड़ने के उदाहरण
CONFIRM सिग्नल
किसी पते की पुष्टि तब की जाती है, जब नतीजे से पता चलता है कि Address Validation API ने पुष्टि किया गया पता बनाने के लिए, पते के कॉम्पोनेंट का अनुमान लगाया है या उनमें बदलाव किया है. इन मामलों में, आपके पास डिलीवरी के लिए पता होता है, लेकिन आपको इस बात की ज़्यादा पुष्टि करनी होती है कि ग्राहक ने जो पता दिया है वह सही है.
Address Validation API के रिस्पॉन्स के इन फ़ील्ड का इस्तेमाल, verdict.possibleNextAction के साथ-साथ यह पता लगाने के लिए किया जा सकता है कि किसी पते में मामूली समस्याएं हैं या नहीं. साथ ही, यह भी पता लगाया जा सकता है कि वे समस्याएं क्या हैं.
| पुष्टि के लिए ज़रूरी आमदनी का थ्रेशोल्ड | अगर किसी पते के लिए validationGranularity ROUTE या PREMISE_PROXIMITY है, तो हो सकता है कि पता गलत हो.
|
|---|---|
| अनुमानित डेटा | जब hasInferredComponents फ़ील्ड true होता है, तो इसका मतलब है कि एपीआई ने पते के अन्य कॉम्पोनेंट से मिली जानकारी को भर दिया है.
|
| बदला गया डेटा | जब hasReplacedComponents फ़ील्ड true होता है, तो API, डाले गए डेटा को उस डेटा से बदल देता है जिसे वह पते को मान्य बनाने के लिए ज़रूरी मानता है.
|
| वर्तनी में सुधार | hasSpellCorrectedComponents फ़ील्ड true होने पर, एपीआई ने गलत स्पेलिंग वाले कुछ कॉम्पोनेंट की स्पेलिंग ठीक कर दी.
|
पते के उदाहरणों की पुष्टि करना
ACCEPT सिग्नल
Address Validation API से मिले जवाब में, पते के सही होने की पुष्टि होने पर, उसे स्वीकार किया जा सकता है. इससे यह पता चलता है कि पते पर डिलीवरी की जा सकती है और इसका इस्तेमाल, आगे की प्रोसेस में ग्राहक से संपर्क किए बिना किया जा सकता है.
पते की पुष्टि करने वाले API के रिस्पॉन्स के इन फ़ील्ड का इस्तेमाल, verdict.possibleNextAction के साथ-साथ यह तय करने के लिए किया जा सकता है कि पता सही है या नहीं.
| पुष्टि के लिए ज़रूरी आमदनी का थ्रेशोल्ड | PREMISE में से validationGranularity को अक्सर स्वीकार कर लिया जाता है. हालांकि, ROUTE वैल्यू से भी डिलीवरी किए जा सकने वाले पते का पता चल सकता है.
|
|---|---|
| अनुमानित डेटा मौजूद नहीं है | जब hasInferredComponents फ़ील्ड false होता है, तो इसका मतलब है कि आउटपुट में किसी भी कॉम्पोनेंट का अनुमान नहीं लगाया गया है.
|
| बदला गया कोई डेटा नहीं है | hasReplacedComponents फ़ील्ड false होने पर, आपको पता चलता है कि इनपुट डेटा को नहीं बदला गया है.
|
| वर्तनी में कोई सुधार नहीं किया गया है | hasSpellCorrectedComponents फ़ील्ड में false होने का मतलब है कि शब्दों की स्पेलिंग में कोई सुधार नहीं किया गया है.
|
| USPS DPV की पुष्टि | जब uspsData.dpvConfirmation की वैल्यू Y होती है, तो इसका मतलब है कि पता, USPS के डेटाबेस में मौजूद किसी पते से मेल खाता है. यह फ़ील्ड सिर्फ़ अमेरिका के पतों के लिए उपलब्ध है. uspsData.dpvConfirmation के बारे में ज़्यादा जानने के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.
|