इस दस्तावेज़ में, पते की पुष्टि करने वाले एपीआई से मिलने वाले अलग-अलग जवाबों को मैनेज करने के लिए, पते की जांच करने वाला सिस्टम बनाने की प्रोसेस के बारे में बताया गया है. इसमें, रिस्पॉन्स का सही तरीके से इस्तेमाल करने, एपीआई से मिले अन्य सिग्नल की जांच करने, और अपने ग्राहकों से ज़्यादा जानकारी पाने के लिए, कब और कैसे पूछताछ करने का तरीका बताया गया है.
आम तौर पर, एपीआई रिस्पॉन्स से यह तय होता है कि आपके सिस्टम को किसी पते को कैसे मैनेज करना चाहिए:
- ठीक करें—पते की क्वालिटी खराब है. आपको ज़्यादा जानकारी के लिए कहना चाहिए.
- पुष्टि करें—पता अच्छी क्वालिटी का है, लेकिन इसमें इनपुट पते से बदलाव किए गए हैं. आपसे पुष्टि करने के लिए कहा जा सकता है.
- स्वीकार करें—पता अच्छी क्वालिटी का है. आपके पास, दिए गए पते को स्वीकार करने का विकल्प है.
मुख्य मकसद
इस दस्तावेज़ की मदद से, एपीआई के जवाब का बेहतर तरीके से विश्लेषण करने के लिए अपने सिस्टम में बदलाव किया जा सकता है. साथ ही, दिए गए पतों के लिए आगे की कार्रवाइयां तय की जा सकती हैं. यहां दिए गए आभासी कोड में, संभावित फ़्लो दिखाया गया है.
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.
सटीक लॉजिक आपकी स्थिति पर निर्भर करता है. ज़्यादा जानकारी के लिए, लागू करने के दिशा-निर्देश देखें. इस लॉजिक को लागू करने के लिए, एक्सटेंडेड कॉम्पोनेंट लाइब्रेरी में मौजूद ओपन सोर्स का भी इस्तेमाल किया जा सकता है.
वर्कफ़्लो के बारे में खास जानकारी
नीचे दी गई टेबल में, आपके सिस्टम के लिए दो कार्रवाइयों के बारे में खास जानकारी दी गई है:
- इस्तेमाल करने के लिए वर्कफ़्लो, जो ठीक करने, पुष्टि करने, और स्वीकार करने के व्यवहार पर आधारित होता है.
- जवाब में पहले सिग्नल की जांच करने के लिए. यहां बताए गए सिग्नल,
verdictप्रॉपर्टी से आते हैं. हालांकि, इनके अलावा भी अन्य सिग्नल देखे जा सकते हैं. इनसे पता चलता है कि पते की क्वालिटी कैसी है. हर तरह के व्यवहार के लिए, इस दस्तावेज़ में एक सेक्शन होता है. इसमें ऐसे अन्य सिग्नल के बारे में बताया जाता है जिनकी आपको जांच करनी पड़ सकती है.
| आपके सिस्टम का व्यवहार | |||
|---|---|---|---|
| पता ठीक करना |
|
||
| पते की पुष्टि करना |
|
||
| पता स्वीकार करें |
Address Validation API के जवाब से पता चलता है कि पते की क्वालिटी बहुत अच्छी है.
|
||
लागू करने के लिए सलाह
पते की पुष्टि करने वाले सिग्नल के जवाब में, आपका सिस्टम कैसे काम करता है, इसे डिज़ाइन करते समय, यहां दिए गए सुझावों से आपको जवाब देने का ज़्यादा असरदार मॉडल बनाने में मदद मिल सकती है. हालांकि, ये सिर्फ़ सुझाव हैं. इसलिए, ध्यान रखें कि आपके लागू करने का तरीका आपके कारोबार के मॉडल के हिसाब से हो.
| सलाह | जानकारी | |
|---|---|---|
| जोखिम का स्तर |
सुधार करने के लिए कहा जाए या डाले गए पते को स्वीकार किया जाए, इस फ़ैसले को लेते समय अपनी स्थिति के हिसाब से, गड़बड़ी की सीमा को ध्यान में रखें. |
पते की पुष्टि करने वाला एपीआई, कई तरह के सिग्नल दिखाता है. इन सिग्नल को जोड़कर, पुष्टि करने की प्रोसेस को ऑप्टिमाइज़ किया जा सकता है. उदाहरण के लिए, अगर किसी पते में सड़क का वह नंबर दिया गया है जिसकी पुष्टि नहीं हुई है, तो भी आपके पास उसे स्वीकार करने का विकल्प है. दूसरी ओर, अगर आपके कारोबार के लिए पते की ज़्यादा जानकारी की ज़रूरत है, तो उपयोगकर्ता से इसके लिए कहा जा सकता है. किसी ऐसे उदाहरण के लिए जो दोनों कैटगरी में आ सकता है, पता स्वीकार करें - उदाहरण में अमेरिका से बाहर का वह सड़क नंबर जिसकी पुष्टि नहीं हुई है देखें. |
| पते स्वीकार करना |
अगर ग्राहक प्रॉम्प्ट का जवाब नहीं देता है, तो अपने सिस्टम को मूल एंट्री स्वीकार करने की अनुमति देना एक अच्छा तरीका है. |
इन मामलों में, हो सकता है कि ग्राहक ने ऐसा पता डाला हो जो सिस्टम में मौजूद न हो. जैसे, नया निर्माण. |
किसी पते को ठीक करना
जब नतीजों से साफ़ तौर पर पता चलता हो कि पते पर डिलीवरी नहीं की जा सकती, तो पता ठीक करें. इसके बाद, आपका सिस्टम खरीदार से ज़रूरी जानकारी मांग सकता है. इसके बाद, डिलीवरी के लिए पता पाने के लिए, आपको अपना वर्कफ़्लो फिर से जारी करना होगा.
सिग्नल ठीक करना
पते की पुष्टि करने वाला एपीआई, आपको कई सिग्नल देता है. इनसे आपको पता चलता है कि पते में कोई बदलाव करना है या नहीं.
1. पुष्टि की बारीकी और मौजूद न होने वाले कॉम्पोनेंट
इन दो सिग्नल से, समस्या वाले पते के बारे में सबसे सही जानकारी मिलती है:
- जब भी
validationGranularityफ़ील्डOTHERहो, तो आपके सिस्टम को पता चलना चाहिए कि गड़बड़ी कहां हुई और उसे कैसे ठीक किया जा सकता है. इसके लिए, उसे पता लगाना होगा कि एड्रेस कॉम्पोनेंट सिग्नल में क्या गड़बड़ी है. - जब भी प्रोसेस के बाद का
addressऑब्जेक्टmissingComponentTypesफ़ील्ड दिखाता है, तो आपके सिस्टम को उस कॉम्पोनेंट की जांच करनी चाहिए. कॉम्पोनेंट मौजूद न होने पर, पता अधूरा दिखता है और डिलीवर नहीं किया जा सकता.
2. पेज के लिए सही ऑडियंस तय करने के दूसरे तरीके
Address Validation API, कुछ खास समस्याओं का पता लगाने में मदद करने के लिए, अन्य सिग्नल भी उपलब्ध कराता है:
| संदिग्ध कॉम्पोनेंट | जब किसी कॉम्पोनेंट के लिए पुष्टि करने के लेवल का एनम UNCOMFIRMED_AND_SUSPICIOUS होता है, तो हो सकता है कि कॉम्पोनेंट गलत हो.
|
|---|---|
| समस्या का हल न किया गया कॉम्पोनेंट | unresolvedToken, डाले गए इनपुट का ऐसा हिस्सा होता है जिसे पते के मान्य हिस्से के तौर पर नहीं पहचाना जाता. |
3. अमेरिका के पते के सिग्नल
सिर्फ़ अमेरिका के पतों पर लागू होने वाले कुछ फ़ील्ड, इस बात का अहम संकेत देते हैं कि पते पर डिलीवरी नहीं की जा सकती और उसे ठीक करना चाहिए. जिस पते को ठीक करना है उसके लिए, आपको यह जानकारी दिखेगी:
dpvConfirmation
|
N, D या खाली हो.
|
|---|
dpvConfirmation के बारे में ज़्यादा जानने के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.
किसी पते की पुष्टि करना
किसी पते की पुष्टि तब की जाती है, जब नतीजे से पता चलता है कि पते की पुष्टि करने वाला एपीआई, पुष्टि किए गए पते को दिखाने के लिए, पते के कॉम्पोनेंट में अनुमान लगाया है या बदलाव किया है. इन मामलों में, आपके पास डिलीवर किया जा सकने वाला पता होता है. हालांकि, आपको यह पक्का करना होता है कि पता सही है और खरीदार ने यही पता दिया है.
ग्राहक को सही निर्देश देने के लिए, आपका लॉजिक उन कॉम्पोनेंट की पहचान करेगा जिन्हें सेवा ने फ़्लैग किया है. इससे यह तय किया जा सकेगा कि एपीआई ने कॉम्पोनेंट पर कौनसी कार्रवाई या फ़्लैग लागू किया है, जैसे कि inferred, replaced या spellCorrected.
रेफ़रंस में AddressComponent देखें.
सिग्नल की पुष्टि करना
पते की पुष्टि करने वाला एपीआई, कई सिग्नल देता है. इनसे आपको पता चलता है कि किसी पते की पुष्टि की जानी चाहिए या नहीं.
1. पुष्टि करने के लिए ज़रूरी जानकारी
ROUTE या इससे बेहतर validationGranularity का इस्तेमाल किया जा सकता है. हालांकि, PREMISE या SUBPREMISE से डिलीवरी की संभावना ज़्यादा होती है.
2. पेज के लिए सही ऑडियंस तय करने के दूसरे तरीके
ग्राहक से पते की पुष्टि करने का फ़ैसला लेते समय, यह तय करने के लिए कि किन कॉम्पोनेंट की जांच करनी है, नतीजे में ये जानकारी भी मिलती है:
| अनुमानित डेटा | जब
hasInferredComponents फ़ील्ड true है, तो इसका मतलब है कि एपीआई ने पते के अन्य कॉम्पोनेंट से मिली जानकारी भरी है.
|
|---|---|
| बदला गया डेटा | जब
hasReplacedComponents फ़ील्ड true है, तो एपीआई ने डाले गए डेटा को उस डेटा से बदल दिया जो पते को मान्य बनाने के लिए ज़रूरी था.
|
3. अमेरिका के पते के सिग्नल
सिर्फ़ अमेरिका के पतों पर लागू होने वाले कुछ फ़ील्ड से पता चलता है कि आपके लॉजिक को ग्राहक से जानकारी की पुष्टि करनी चाहिए. इनमें से कोई एक शर्त लागू हो:
dpvConfirmation
|
S
|
|---|---|
| जवाब का पता | इसमें missingComponentTypes फ़ील्ड है, जिसकी वैल्यू
subpremise है.
|
पते के उदाहरणों की पुष्टि करना
कोई पता स्वीकार करना
जब नतीजे से यह पता चलता है कि पते पर डिलीवरी की जा सकती है और खरीदार से संपर्क किए बिना, उसे इस्तेमाल किया जा सकता है, तो आप उस पते को स्वीकार कर लेते हैं.
सिग्नल स्वीकार करना
पते की पुष्टि करने वाला एपीआई, कई सिग्नल देता है. इनसे आपको पता चलता है कि किसी पते की पुष्टि की जानी चाहिए या नहीं.
1. पुष्टि करने के लिए ज़रूरी जानकारी
validationGranularity के लिए PREMISE या इससे बेहतर रेटिंग स्वीकार की जाती है. हालांकि, कुछ मामलों में ROUTE का मतलब अब भी डिलीवर किए जा सकने वाले पते से है.
2. पेज के लिए सही ऑडियंस तय करने के दूसरे तरीके
अच्छी क्वालिटी वाले पते के लिए, यह जानकारी भी दी जानी चाहिए:
- कोई डेटा बदला नहीं गया. इस मामले में,
hasReplacedComponents: FALSE. - अनुमानित कॉम्पोनेंट नहीं हैं. इस मामले में,
hasInferredComponents: FALSE.
3. अमेरिका के पते के सिग्नल
सिर्फ़ अमेरिका के पतों पर लागू होने वाले कुछ फ़ील्ड से पता चलता है कि पते की क्वालिटी अच्छी है और उस पर डिलीवरी की जा सकती है. अमेरिका का मान्य पता डालने पर, आपको यह जानकारी दिखेगी:
dpvConfirmation
|
Y
|
|---|
स्वीकार किए जा सकने वाले पते के उदाहरण