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

मकसद

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

Address Validation API का आकलन करने के बाद, यहां कुछ दिशा-निर्देश दिए गए हैं. हमारा सुझाव है कि आप इन्हें टेस्टिंग के दौरान इस्तेमाल करें.

इस टेस्ट के ये लक्ष्य होंगे:

1. पुष्टि करें कि Address Validation API, आपके इस्तेमाल के उदाहरण के लिए सही है.
2. पुष्टि करें कि Address Validation API, आपके समाधान की ज़रूरी शर्तों को पूरा करता है या नहीं. जैसे:
   • अच्छी क्वालिटी वाले पतों की पहचान करना.
   • खराब क्वालिटी वाले इनपुट के बारे में सूचना देना.
   • पते के डेटा में सुधार करना. इसमें अनुमान, बदलाव, और स्पेलिंग ठीक करना शामिल है.
   • शिपिंग के लिए, फ़ॉर्मैट किया गया पता देना.
   • उप-परिसर के डेटा के मौजूद न होने या गलत होने के बारे में सूचना देना (सिर्फ़ अमेरिका में).
3. पक्का करें कि एपीआई लागू करने से आपको मेज़र किया जा सकने वाला फ़ायदा मिलेगा.

जांच करने के बाद, आपको ऊपर दिए गए सवालों के जवाब मिल जाएंगे. साथ ही, यह तय करने में मदद मिलेगी कि एपीआई आपके कारोबार के लिए सही है या नहीं.

अपना डेटा तैयार करें

आपको यह जांच, पते के मौजूदा डेटा के सैंपल के आधार पर करनी चाहिए. टेस्ट के लिए डेटा को खुद न चुनें. इसके बजाय, रैंडम सैंपल चुनें. ये सैंपल, उन भौगोलिक क्षेत्रों के हिसाब से होने चाहिए जहां आपका कारोबार चलता है. इसका मतलब है कि अगर आपका कारोबार अमेरिका और यूनाइटेड किंगडम, दोनों देशों में चलता है, लेकिन 70% कारोबार यूके में होता है और 30% अमेरिका में, तो सैंपल में यह बंटवारा दिखना चाहिए.

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

टेस्ट के लिए, करीब 5,000 से 10,000 रिकॉर्ड का सैंपल साइज़ तैयार करें.

एपीआई को कॉल करना

सेक्शन की ज़रूरी शर्त: यह समझें कि पते की पुष्टि करने का अनुरोध कैसे भेजा जाता है.

डेटा तैयार करने के बाद, आपको हर पते के रिकॉर्ड को एपीआई के हिसाब से चलाना होगा.

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

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

नतीजों की समीक्षा करना

सेक्शन की ज़रूरी शर्तें: पुष्टि के जवाब को मैनेज करने का तरीका जानें. साथ ही, खास तौर पर, ठीक करें, पुष्टि करें, और स्वीकार करें के कॉन्सेप्ट को समझें.

इस सेक्शन में, हम आउटपुट के उन उदाहरणों के बारे में बात करेंगे जिनका विश्लेषण करके, यह पता लगाया जा सकता है कि समाधान आपकी समस्या के हिसाब से सही है या नहीं.

इस दस्तावेज़ में बताए गए मुख्य एपीआई फ़ील्ड की खास जानकारी

जवाब का डेटा	यह क्या है?	आकलन करने का तरीका	यह कैसे मददगार है?
verdict.inputGranularity	इससे पते की जानकारी के लेवल के बारे में पता चलता है.	SUB_PREMISE प्रीमाइज़ PREMISE_PROXIMITY BLOCK ROUTE अन्य	इसकी मदद से यह पता लगाया जा सकता है कि इनपुट किए गए पते में, मान्य होने के लिए ज़रूरी डेटा मौजूद है या नहीं.
verdict.validationGranularity	इसमें पते की पुष्टि करने के पूरे प्रोसेस के बारे में बताया गया है.	SUB_PREMISE प्रीमाइज़ PREMISE_PROXIMITY BLOCK ROUTE अन्य	इससे, एपीआई से मिले आउटपुट के आधार पर पते की क्वालिटी का पता लगाया जा सकता है.
verdict.hasInferredComponents	इससे पता चलता है कि एपीआई ने किसी कॉम्पोनेंट का अनुमान लगाया है या नहीं.	सही/गलत	एपीआई, उन कॉम्पोनेंट को जोड़ सकता है जिनके लिए डेटा का अनुमान लगाया जा सकता है. उदाहरण के लिए, राज्य का कोड मौजूद न होना.
verdict.hasReplacedComponents	इससे पता चलता है कि एपीआई ने किसी कॉम्पोनेंट को बदल दिया है.	सही/गलत	कुछ मामलों में, एपीआई गलत कॉम्पोनेंट को सही डेटा से बदल सकता है.
verdict.addressComplete	इससे पता चलता है कि पता पूरा है या नहीं.	सही/गलत	अगर एपीआई को लगता है कि आउटपुट पते में सभी ज़रूरी कॉम्पोनेंट मौजूद हैं, तो यह वैल्यू सही होगी.
address.missingComponentTypes	अगर पते में कॉम्पोनेंट मौजूद नहीं हैं, तो चेतावनी देने के लिए सिग्नल.	वैल्यू के लिए दूसरी टेबलदेखें.	अधूरे पते में मौजूद नहीं कॉम्पोनेंट को हाइलाइट करें.

मान्य पतों की समीक्षा करना

एपीआई से मिले डेटा को क्रम से लगाएं, ताकि यह पता लगाया जा सके कि आपका सिस्टम किन पतों को मान्य मानेगा. एपीआई से मिलने वाले मुख्य सिग्नल ये हैं:

• verdict.validationGranularity में PREMISE या इससे बेहतर क्वालिटी का कॉन्टेंट शामिल हो.
• verdict.addressComplete true है.
• कोई भी कॉम्पोनेंट न तो बदला गया है और न ही जोड़ा गया है.

ज़्यादा जानकारी के लिए, पता स्वीकार करना लेख पढ़ें.

इस अभ्यास का आउटपुट, पते के डेटा का एक सबसेट होना चाहिए. यह डेटा, आपके सिस्टम में मान्य माना जाएगा. इस चरण में, यह तय किया जा सकता है कि:

• क्या स्वीकार किए गए अनुरोधों का प्रतिशत सही है?
• अगर पते की पुष्टि करने वाले किसी मौजूदा वर्कफ़्लो का इस्तेमाल किया जाता है, तो क्या पुष्टि होने की दर पहले जैसी ही है या उससे बेहतर है?

उदाहरण: मान्य पता

पता डाला गया	क्षेत्र
76 Buckingham Palace Road, London SW1W 9TQ	यूके

फ़ैसला

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true
}

अमान्य पतों की समीक्षा करना

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

एपीआई से मिले डेटा को क्रम से लगाएं, ताकि यह पता चल सके कि आपका सिस्टम किन पतों को अमान्य के तौर पर मार्क करेगा. एपीआई से मिलने वाले मुख्य सिग्नल ये हैं:

• verdict.validationGranularity को OTHER या ROUTE पर सेट किया जाता है. यह आपके जोखिम के लेवल पर निर्भर करता है.
• verdict.addressComplete false है.

ज़्यादा जानकारी के लिए, पता ठीक करना लेख पढ़ें.

इस गतिविधि का आउटपुट, पते के डेटा का एक सबसेट होना चाहिए. इस डेटा को आपका सिस्टम अमान्य के तौर पर मार्क करेगा. इस चरण में, यह तय किया जा सकता है कि अमान्य प्रतिशत दर स्वीकार की जा सकती है या नहीं.

यह ध्यान रखना ज़रूरी है कि पतों को अमान्य के तौर पर मार्क करना, Address Validation API की मुख्य सुविधा है. साथ ही, अमान्य के तौर पर मार्क किए गए पतों की ज़्यादा संख्या से, यह ज़रूरी नहीं है कि एपीआई की परफ़ॉर्मेंस खराब हो. एपीआई आपको यह जानकारी दे रहा है कि पते में कोई गड़बड़ी है. इससे, गड़बड़ियों का पता पहले ही चल जाता है. इसलिए, यह आपके वर्कफ़्लो को बेहतर बना सकता है. ऐसा होने से, बाद में आने वाली समस्याओं से बचा जा सकता है.

उदाहरण: अमान्य पता

पता डाला गया	क्षेत्र
21 45 40th street	यूएसए

फ़ैसला

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true
}

उन कॉम्पोनेंट की समीक्षा करें जो मौजूद नहीं हैं या जिनकी पुष्टि नहीं हुई है

इस चरण में, पुष्टि न किए गए या मौजूद न होने वाले कॉम्पोनेंट की भी समीक्षा की जा सकती है. यह, रिटर्न में मौजूद Address ऑब्जेक्ट का हिस्सा है. ये दो फ़ील्ड हैं: missingComponentTypes और unconfirmedComponentTypes.

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

उदाहरण: कॉम्पोनेंट मौजूद नहीं है और इसकी पुष्टि नहीं हुई है

पता डाला गया	क्षेत्र
Fake St, New York, NY 10011	यूएसए

फ़ैसला

{
     "inputGranularity": "ROUTE",
     "validationGranularity": "OTHER",
     "geocodeGranularity": "OTHER",
     "hasUnconfirmedComponents": true
}

कॉम्पोनेंट मौजूद नहीं हैं और उनकी पुष्टि नहीं हुई है

"missingComponentTypes": [
    "street_number"
],
"unconfirmedComponentTypes": [
    "route"
]

सुधार किए गए पतों की समीक्षा करना

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

इन मुख्य सिग्नल पर ध्यान दें:

• inferred, replaced या spellCorrected को किसी भी addressComponents पर true पर सेट किया गया हो.
• verdict.hasInferredComponents या verdict.hasReplacedComponents को true पर सेट किया गया हो.

ज़्यादा जानकारी के लिए, पते की पुष्टि करना लेख पढ़ें.

इस प्रोसेस का आउटपुट, पते के डेटा का सबसेट होना चाहिए. इसमें एपीआई की मदद से सुधार किया गया हो.

इस डेटा के कुछ हिस्से की मैन्युअल तरीके से समीक्षा की जा सकती है. इससे यह पता लगाया जा सकता है कि एपीआई आपके डेटा में ऐसे बदलाव कर रहा है या नहीं जिनसे आपके डाउनस्ट्रीम वर्कफ़्लो में रुकावट कम हो.

उदाहरण: सुधार किया गया पता

पता डाला गया	क्षेत्र
76 Bruckingm Palace Road, London SW1W 9TQ	यूके

रास्ता addressComponent

{
    "componentName": {
        "text": "Buckingham Palace Road",
        "languageCode": "en"
    },
    "componentType": "route",
    "confirmationLevel": "CONFIRMED",
    "spellCorrected": true
}

[सिर्फ़ अमेरिका के लिए] ऐसे पते की समीक्षा करें जिसमें सबप्रीमाइसेस का डेटा मौजूद नहीं है या गलत है

Address Validation API, अमेरिका में मौजूद पतों के लिए यह पता लगा सकता है कि सबप्रीमाइज़ की जानकारी मौजूद नहीं है या गलत है.

इन मुख्य सिग्नल पर ध्यान दें:

• Address ऑब्जेक्ट में:
  • unconfirmedComponentTypes में subpremise शामिल है
  • missingComponentTypes में subpremise शामिल है
• UspsData ऑब्जेक्ट में:
  • dpvConfirmation, D है (सबप्रीमाइसेस की जानकारी मौजूद नहीं है)
  • dpvConfirmation, S है (सबप्रीमाइसेस की पुष्टि नहीं हुई है)

अधिक जानकारी के लिए संयुक्त राज्य अमेरिका के पते संभालें देखें.

इस जांच से पता चलेगा कि आपके डेटा में अपार्टमेंट नंबर जैसी सब-प्रीमाइसेस की जानकारी मौजूद नहीं है या गलत है. इससे आगे चलकर समस्याएं हो सकती हैं. खास तौर पर, डिलीवरी के इस्तेमाल के उदाहरणों के लिए. Address Validation API, इस समस्या का पता पहले ही लगा लेता है. इससे आपके वर्कफ़्लो में सुधार होता है. साथ ही, आपको सही डेटा इकट्ठा करने के लिए ज़रूरी चरणों को लागू करने का मौका मिलता है.

उदाहरण: सबप्रीमाइज़ मौजूद नहीं है

पता डाला गया	क्षेत्र
111 8th Avenue, Manhattan, NY 10011	अमेरिका

कॉम्पोनेंट मौजूद नहीं है

"missingComponentTypes": [
    "subpremise"
]

USPS के डेटा के हिसाब से, डिलीवरी पॉइंट की पुष्टि करना

"dpvConfirmation": "D"

[सिर्फ़ अमेरिका के लिए] USPS के स्टैंडर्ड के मुताबिक पता (standardizedAddress) की समीक्षा करें

Address Validation API, अमेरिका के पतों के लिए USPS के स्टैंडर्ड के मुताबिक पता भी दिखाता है. यह खास तौर पर तब ज़रूरी होता है, जब आपको शिपिंग लेबल पर USPS के फ़ॉर्मैट में पते प्रिंट करने हों.

इस डेटा को देखने के लिए, UspsAddress की समीक्षा की जा सकती है. इससे यह तय किया जा सकता है कि यह आपके वर्कफ़्लो में काम का है या नहीं.

उदाहरण: USPS के हिसाब से पते का स्टैंडर्ड फ़ॉर्मैट

"standardizedAddress": {
    "firstAddressLine": "111 8TH AVE FL 11",
    "cityStateZipAddressLine": "NEW YORK NY 10011-5201",
    "city": "NEW YORK",
    "state": "NY",
    "zipCode": "10011",
    "zipCodeExtension": "5201"
}

नतीजा

टेस्टिंग शुरू करें - पते की पुष्टि करने वाले API की टेस्टिंग आज से ही शुरू करें. इससे आपको यह पक्का करने में मदद मिलेगी कि पते का डेटा सटीक हो, ग्राहकों को बेहतर अनुभव मिले, और आपके कारोबार के काम आसानी से हो सकें. ऊपर बताए गए टेस्ट के उदाहरणों को आज़माने के बाद, आपको यह तय करने में मदद मिलेगी कि Address Validation API आपके वर्कफ़्लो के लिए फ़ायदेमंद है या नहीं.

इस बारे में और पढ़ें:

• Address Validation API के लिए डेवलपर दस्तावेज़
• ज़्यादा पतों की पुष्टि करने के लिए, Address Validation API का इस्तेमाल करना
• ई-कॉमर्स चेकआउट के लिए, पते की पुष्टि करने की सुविधा

योगदानकर्ता

हेनरिक वाल्व | DevX इंजीनियर