मकसद
Address Validation की सुविधा, अलग-अलग तरह के इस्तेमाल के उदाहरणों के लिए काम की है. साथ ही, टेस्ट के नतीजों की क्वालिटी के अलावा भी कुछ अहम बातें हैं जिन पर ध्यान देना ज़रूरी है. हमारा सुझाव है कि आप इन बातों के बारे में जानें. उदाहरण के लिए: Place Autocomplete और Maps जैसे उपयोगकर्ता फ़्लो में, काम करने वाले प्रॉडक्ट की पूरी जानकारी, इलाके के हिसाब से उपलब्धता, और एंटरप्राइज़ के लिए भरोसेमंद और भरोसेमंद होना.
अगर आपने Address Validation API की समीक्षा कर ली है, तो हमारा सुझाव है कि टेस्ट के दौरान, यहां दिए गए दिशा-निर्देशों का पालन करें.
इस टेस्ट के ये लक्ष्य होंगे:
- पुष्टि करना कि Address Validation API, आपके इस्तेमाल के उदाहरण के लिए सही है.
- यह पुष्टि करना कि Address Validation API, आपकी समस्याओं को हल करने की ज़रूरतों को पूरा करता है या नहीं. जैसे:
- अच्छी क्वालिटी वाले पतों की पहचान करना.
- खराब क्वालिटी वाले पतों के इनपुट के बारे में सूचना देना.
- पते के डेटा में सुधार करना. इनमें अनुमान, बदलाव, और स्पेलिंग में सुधार शामिल हैं.
- शिपिंग के लिए, फ़ॉर्मैट किया गया पता देना.
- सब-प्रिमाइज़ के डेटा के मौजूद न होने या गलत होने के बारे में सूचना देना. यह सुविधा सिर्फ़ अमेरिका में उपलब्ध है.
- यह पक्का करना कि एपीआई लागू करने से आपको मेज़र किया जा सकने वाला फ़ायदा मिलेगा.
टेस्ट करने के बाद, आपके पास ऊपर दिए गए सवालों के जवाब देने और यह तय करने का विकल्प होगा कि एपीआई आपके कारोबार के लिए सही है या नहीं.
अपना डेटा तैयार करें
आपका टेस्ट, मौजूदा पते के डेटा के सैंपल के आधार पर किया जाना चाहिए. टेस्ट के लिए डेटा मैन्युअल तरीके से न चुनें. इसके बजाय, रैंडम सैंपल चुनें. ये सैंपल, उन इलाकों के हिसाब से होने चाहिए जहां आपका कारोबार चलता है. इसका मतलब है कि अगर आपका कारोबार, अमेरिका और यूके, दोनों में चलता है, लेकिन आपके कारोबार का 70% हिस्सा यूके में और 30% हिस्सा अमेरिका में है, तो सैंपल में यह अंतर दिखना चाहिए.
डेटा कैप्चर करने के समय के पतों का इस्तेमाल करें. उदाहरण के लिए, अगर आपको अपने ई-कॉमर्स चेकआउट में, पते की पुष्टि करने की सुविधा लागू करनी है, तो फ़ॉर्म पर आपके ग्राहकों की ओर से डाले गए पतों का इस्तेमाल करें. ऐसा इसलिए, क्योंकि Address Validation API लागू करने के बाद, मौजूदा प्रोसेसिंग को बदला जा सकता है.
टेस्ट के लिए, करीब 5,000 से 10,000 रिकॉर्ड का सैंपल तैयार करें.
एपीआई को कॉल करें
सेक्शन के लिए ज़रूरी शर्तें: जानें कि पते की पुष्टि करने का अनुरोध कैसे भेजा जाता है.
डेटा तैयार करने के बाद, आपको हर पते के रिकॉर्ड के लिए एपीआई को कॉल करना होगा.
एपीआई को कॉल करने के तरीके के बारे में जानने के लिए, Address Validation API का दस्तावेज़ देखें. हमारे पास एक लेख भी है, जिसमें ज़्यादा संख्या में पतों को प्रोसेस करने के लिए, Address Validation API का इस्तेमाल करने के सबसे सही तरीकों के बारे में बताया गया है.
इस चरण का नतीजा, हर पते के रिकॉर्ड के लिए एपीआई से मिलने वाला डेटा आउटपुट होना चाहिए. इसके बाद, नतीजों का विश्लेषण करके यह तय किया जा सकता है कि एपीआई, आपके इस्तेमाल के उदाहरण के लिए सही है या नहीं. यह तय करना आपके ऊपर है कि आपको स्प्रेडशीट, डेटाबेस या किसी अन्य टूल का इस्तेमाल करना है.
नतीजों की समीक्षा करना
सेक्शन के लिए ज़रूरी शर्तें: जानें कि पुष्टि करने के जवाब को कैसे मैनेज किया जाता है, खास तौर पर, ठीक करें, पुष्टि करें, और स्वीकार करें की अवधारणा को समझें.
इस सेक्शन में, हम उन आउटपुट के उदाहरणों के बारे में बात करेंगे जिनका विश्लेषण करके, यह आकलन किया जा सकता है कि समाधान सही है या नहीं.
इस दस्तावेज़ में चर्चा किए गए, एपीआई के मुख्य फ़ील्ड की खास जानकारी
जवाब का डेटा |
यह क्या है? |
इसका आकलन कैसे करें |
यह कैसे मददगार है? |
|---|---|---|---|
verdict.inputGranularity |
पते के इनपुट की ग्रैन्युलैरिटी के बारे में बताता है. |
SUB_PREMISE PREMISE PREMISE_PROXIMITY BLOCK ROUTE OTHER |
इससे यह तय किया जा सकता है कि इनपुट किए गए पते में, मान्य होने के लिए ज़रूरी डेटा है या नहीं. |
verdict.validationGranularity |
पते के कुल आउटपुट की पुष्टि के बारे में बताता है. |
SUB_PREMISE PREMISE PREMISE_PROXIMITY BLOCK ROUTE OTHER |
इससे एपीआई से मिलने वाले आउटपुट के आधार पर, पते की कुल क्वालिटी तय की जा सकती है. |
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
}
मौजूद नहीं कॉम्पोनेंट या जिनकी पुष्टि नहीं हुई है उनकी समीक्षा करना
इस चरण में, उन कॉम्पोनेंट की समीक्षा भी की जा सकती है जो मौजूद नहीं हैं या जिनकी पुष्टि नहीं हुई है. यह, जवाब में मौजूद पते के ऑब्जेक्ट का हिस्सा है. ये दो फ़ील्ड हैं: missingComponentTypes और unconfirmedComponentTypes.
इन फ़ील्ड का इस्तेमाल करके, यह पता लगाया जा सकता है कि एपीआई ने किसी पते को अमान्य के तौर पर क्यों मार्क किया है. साथ ही, पते के लिए सही जानकारी इकट्ठा की जा सकती है, ताकि उसे मान्य बनाया जा सके. इसके लिए, डेटा कलेक्शन के समय, उन फ़ील्ड के बारे में जानकारी दी जा सकती है जिनमें गड़बड़ी है. इस तरह, एपीआई आपको अपने डेटा की क्वालिटी के बारे में खास जानकारी देकर, वैल्यू उपलब्ध कराता है.
उदाहरण: कॉम्पोनेंट मौजूद नहीं है और उसकी पुष्टि नहीं हुई है
दर्ज किया गया पता |
इलाका |
|---|---|
Fake St, New York, NY 10011 |
यूएसए |
फ़ैसला
{
"inputGranularity": "ROUTE",
"validationGranularity": "OTHER",
"geocodeGranularity": "OTHER",
"hasUnconfirmedComponents": true
}
मौजूद नहीं कॉम्पोनेंट और जिनकी पुष्टि नहीं हुई है
"missingComponentTypes": [
"street_number"
],
"unconfirmedComponentTypes": [
"route"
]
सुधार किए गए पतों की समीक्षा करना
Address Validation API, इनपुट किए गए डेटा में सुधार कर सकता है. इसके लिए, वह अमान्य पते के इनपुट को लेता है और मान्य पते का डेटा आउटपुट करता है. यह एक तरीका है जिससे एपीआई वैल्यू जोड़ता है. साथ ही, टेस्ट के दौरान इसे कैप्चर करना ज़रूरी है.
इन मुख्य सिग्नल पर ध्यान दें:
addressComponentsमें से किसी पर भीinferred,replacedयाspellCorrectedकी वैल्यूtrueपर सेट है.verdict.hasInferredComponentsयाverdict.hasReplacedComponentsकी वैल्यूtrueपर सेट है.
ज़्यादा जानकारी के लिए, पते की पुष्टि करना देखें.
इस प्रोसेस का नतीजा, पते के डेटा का वह सबसेट होना चाहिए जिसमें एपीआई ने सुधार किया है.
इस डेटा के कुछ हिस्से की मैन्युअल तरीके से समीक्षा की जा सकती है, ताकि यह तय किया जा सके कि एपीआई आपके डेटा में ऐसे सुधार कर रहा है जिनसे आपके वर्कफ़्लो में होने वाली समस्याएं कम हो सकती हैं.
उदाहरण: सुधार किया गया पता
दर्ज किया गया पता |
इलाका |
|---|---|
76 Bruckingm Palace Road, London SW1W 9TQ |
यूके |
Route addressComponent
{
"componentName": {
"text": "Buckingham Palace Road",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel": "CONFIRMED",
"spellCorrected": true
}
[सिर्फ़ अमेरिका] सब-प्रिमाइज़ के डेटा के मौजूद न होने या गलत होने वाले पतों की समीक्षा करना
Address Validation API, अमेरिका के पतों के लिए यह तय कर सकता है कि सब-प्रिमाइज़ मौजूद नहीं है या गलत है.
इन मुख्य सिग्नल पर ध्यान दें:
- पते के ऑब्जेक्ट में:
unconfirmedComponentTypesमेंsubpremiseशामिल हैmissingComponentTypesमेंsubpremiseशामिल है
- UspsData ऑब्जेक्ट में:
dpvConfirmationकी वैल्यूDहै (सब-प्रिमाइज़ मौजूद नहीं है)dpvConfirmationकी वैल्यूSहै (सब-प्रिमाइज़ की पुष्टि नहीं हुई है)
ज़्यादा जानकारी के लिए, अमेरिका के पतों को मैनेज करना देखें.
इस टेस्ट से यह पता चलेगा कि आपके डेटा में, अपार्टमेंट नंबर जैसे सब-प्रिमाइज़ मौजूद नहीं हैं या गलत हैं. इससे आगे समस्याएं हो सकती हैं. खास तौर पर, डिलीवरी के इस्तेमाल के उदाहरणों के लिए. Address Validation API, इस समस्या की पहचान पहले ही करके, आपके वर्कफ़्लो में वैल्यू जोड़ सकता है. इससे आपको सही डेटा इकट्ठा करने के लिए, ज़रूरी कदम उठाने में मदद मिलेगी.
उदाहरण: सब-प्रिमाइज़ मौजूद नहीं है
दर्ज किया गया पता |
इलाका |
|---|---|
111 8th Avenue, Manhattan, NY 10011 |
अमेरिका |
कॉम्पोनेंट मौजूद नहीं है
"missingComponentTypes": [
"subpremise"
]
USPS डेटा DPV की पुष्टि
"dpvConfirmation": "D"
[सिर्फ़ अमेरिका] USPS के स्टैंडर्डाइज़्ड पते की समीक्षा करना
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"
}
नतीजा
टेस्ट करना शुरू करें - पते का सटीक डेटा पाने, ग्राहकों के अनुभव को बेहतर बनाने, और अपने कारोबार के कामों को आसान बनाने के लिए, आज ही Address Validation API का टेस्ट करना शुरू करें. ऊपर बताए गए टेस्ट के उदाहरणों को फ़ॉलो करने के बाद, आपके पास यह तय करने के लिए ज़रूरी जानकारी होगी कि Address Validation API, आपके वर्कफ़्लो के लिए काम का है या नहीं.
ज़्यादा जानकारी के लिए, ये लेख पढ़ें:
- Address Validation API का डेवलपर दस्तावेज़
- ज़्यादा संख्या में पतों को प्रोसेस करने के लिए, Address Validation API का इस्तेमाल करना
- ई-कॉमर्स चेकआउट के लिए, Address Validation की सुविधा
योगदानकर्ता
हेनरिक वाल्व | DevX इंजीनियर