पते की पुष्टि करने के समाधान से जुड़ी गाइड

मकसद

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

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

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

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

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

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

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

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

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

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

इस सेक्शन के लिए ज़रूरी शर्त: पते की पुष्टि करने का अनुरोध भेजने का तरीका जानें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डाला गया पता	क्षेत्र
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"
]

यूएसपीएस डेटा डीपीवी की पुष्टि

"dpvConfirmation": "D"

[USA only] Review USPS standardizedAddress

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

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

उदाहरण: यूएसपीएस के मुताबिक सही फ़ॉर्मैट में लिखा गया पता

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

नतीजा

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

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

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

योगदानकर्ता

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