कैंपेन का मकसद
डेवलपर के तौर पर, आप अक्सर ऐसे डेटासेट के साथ काम करते हैं जिनमें ग्राहक के पते होते हैं. ऐसा हो सकता है कि उनकी क्वालिटी अच्छी न हो. आपको यह पक्का करना होगा कि ग्राहक आईडी की पुष्टि, डिलीवरी, और दूसरी कई तरह के इस्तेमाल के लिए पते सही हों.
पते की पुष्टि करने वाला एपीआई, Google Maps Platform का एक प्रॉडक्ट है. इसका इस्तेमाल करके, किसी पते की पुष्टि की जा सकती है. हालांकि, यह एक बार में सिर्फ़ एक ही पता प्रोसेस करता है. इस दस्तावेज़ में, हम अलग-अलग स्थितियों में, ज़्यादा संख्या में पते की पुष्टि करने की सुविधा को इस्तेमाल करने के तरीके पर बात करेंगे. इसमें, एपीआई टेस्टिंग से लेकर एक बार और बार-बार होने वाले पते की पुष्टि करना शामिल है.
इस्तेमाल के उदाहरण
आइए, अब इस्तेमाल के उन मामलों के बारे में जानते हैं जहां हाई वॉल्यूम पते की पुष्टि करना फ़ायदेमंद होता है.
टेस्ट करना
आप कई बार हज़ारों पते चलाकर, Address Validation API की जांच करना चाहते हैं. हो सकता है कि आपके पते, कॉमा सेपरेटेड वैल्यू वाली फ़ाइल में हों और आपको पतों की क्वालिटी की पुष्टि करनी हो.
पतों की पुष्टि एक बार की जाए
पते की पुष्टि करने वाले एपीआई में शामिल होने के दौरान, आपको उपयोगकर्ता डेटाबेस के साथ अपने मौजूदा पते के डेटाबेस की पुष्टि करनी होती है.
पतों का बार-बार पुष्टि करना
पतों की पुष्टि करने के लिए, कई स्थितियों में बार-बार कॉल करना पड़ता है:
- यह मुमकिन है कि आपने दिन भर में कैप्चर की गई जानकारी के लिए, पतों की पुष्टि करने के लिए जॉब शेड्यूल किए. उदाहरण के लिए, ग्राहक के साइन अप, ऑर्डर की जानकारी, और डिलीवरी शेड्यूल करने जैसी जानकारी.
- आपको ऐसे डेटा डंप मिल सकते हैं जिसमें बिक्री से लेकर मार्केटिंग जैसे अलग-अलग डिपार्टमेंट के पते शामिल हों. जिस नए डिपार्टमेंट को पते मिलते हैं वह अक्सर इस्तेमाल करने से पहले, पतों की पुष्टि करना चाहता है.
- ऐसा हो सकता है कि सर्वे या कई प्रमोशन के दौरान और बाद में ऑनलाइन सिस्टम को अपडेट करने के दौरान आपने पते इकट्ठा कर लिए हों. सिस्टम में पते डालते समय, आपको इस बात की पुष्टि करनी होगी कि पते सही हैं या नहीं.
तकनीकी चीज़ों के बारे में पूरी जानकारी
इस दस्तावेज़ के लिए, हम मानते हैं कि:
- आपने किसी ग्राहक डेटाबेस (जैसे, ग्राहक की जानकारी वाला डेटाबेस) के पतों के साथ पते की पुष्टि करने वाले एपीआई को कॉल किया है
- अपने डेटाबेस में अलग-अलग पतों के लिए, मान्य होने वाले फ़्लैग को कैश मेमोरी में सेव किया जा सकता है.
- जब कोई ग्राहक लॉग इन करता है, तो पते की पुष्टि करने वाले एपीआई से मान्य होने वाले फ़्लैग मिलते हैं.
प्रोडक्शन में इस्तेमाल के लिए कैश मेमोरी में सेव करना
पते की पुष्टि करने वाले एपीआई का इस्तेमाल करते समय, आपको अक्सर एपीआई कॉल के रिस्पॉन्स का कुछ हिस्सा कैश मेमोरी में सेव करना होता है. हमारी सेवा की शर्तों से यह तय होता है कि किस तरह का डेटा कैश मेमोरी में सेव किया जा सकता है. हालांकि, पते की पुष्टि करने वाले एपीआई की मदद से कैश मेमोरी में सेव किए जा सकने वाले किसी भी डेटा को, उपयोगकर्ता खाते की कैश मेमोरी में सेव करना ज़रूरी है. इसका मतलब है कि डेटाबेस में, पते या पते के मेटाडेटा को उपयोगकर्ता के ईमेल पते या दूसरे मुख्य आईडी की कैश मेमोरी में सेव किया जाना चाहिए.
ज़्यादा वॉल्यूम वाले पते की पुष्टि करने के इस्तेमाल के उदाहरण के लिए, डेटा कैश मेमोरी में पते की पुष्टि करने वाले एपीआई की सेवा की खास शर्तों का पालन करना ज़रूरी है. इन शर्तों के बारे में सेक्शन 11.3 में बताया गया है. इस जानकारी के आधार पर, आपके पास यह तय करने का विकल्प होगा कि उपयोगकर्ता का पता अमान्य है या नहीं. ऐसा होने पर, आपके ऐप्लिकेशन के साथ अगले इंटरैक्शन के दौरान, आपको सही पते के लिए उपयोगकर्ता को सूचना देनी होगी.
फ़ैसले ऑब्जेक्ट से मिला डेटा
inputGranularity
validationGranularity
geocodeGranularity
addressComplete
hasUnconfirmedComponents
hasInferredComponents
hasReplacedComponents
AddressComponent ऑब्जेक्ट से मिलने वाला डेटा
confirmationLevel
inferred
spellCorrected
replaced
unexpected
अगर आपको असल पते से जुड़ी किसी भी जानकारी को कैश मेमोरी में सेव करना है, तो उस डेटा को सिर्फ़ उपयोगकर्ता की सहमति से कैश मेमोरी में सेव किया जाना चाहिए. इससे यह पक्का होता है कि उपयोगकर्ता अच्छी तरह से यह जानते हैं कि कोई खास सेवा उनका पता क्यों सेव कर रही है. साथ ही, उन्हें अपना पता शेयर करने की शर्तों से कोई परेशानी नहीं है.
उपयोगकर्ता की सहमति का एक उदाहरण, चेकआउट पेज पर ई-कॉमर्स पते के फ़ॉर्म के साथ सीधे तौर पर इंटरैक्शन करना होगा. हम समझते हैं कि पैकेज भेजने के लिए, आपके पते को कैश मेमोरी में सेव और प्रोसेस किया जाएगा.
उपयोगकर्ता की सहमति से, रिस्पॉन्स में मौजूद formattedAddress
और दूसरे मुख्य कॉम्पोनेंट को कैश मेमोरी में सेव किया जा सकता है. हालांकि, बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले मामलों में, उपयोगकर्ता सहमति नहीं दे सकता, क्योंकि पते की पुष्टि बैकएंड से हो रही है. इसलिए, बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले इस मामले में, बहुत सीमित जानकारी को कैश मेमोरी में सेव किया जा सकता है.
जवाब को समझना
अगर पते की पुष्टि करने वाले एपीआई के रिस्पॉन्स में नीचे दिए गए मार्कर मौजूद हैं, तो इससे पता चलता है कि इनपुट पते की क्वालिटी डिलीवर की जा सकती है या नहीं:
- फ़ैसले ऑब्जेक्ट में
addressComplete
मार्करtrue
है, - फ़ैसले ऑब्जेक्ट में
validationGranularity
,PREMISE
याSUB_PREMISE
है - किसी भी AddressComponent को इस तरह से मार्क नहीं किया गया है:
Inferred
(ध्यान दें: inferred=true
ऐसा तब हो सकता है, जबaddressComplete=true
)spellCorrected
replaced
unexpected
और
confirmationLevel
: AddressComponent में पुष्टि का लेवलCONFIRMED
याUNCONFIRMED_BUT_PLAUSIBLE
पर सेट है
अगर एपीआई रिस्पॉन्स में ऊपर दिए गए मार्कर शामिल नहीं हैं, तो हो सकता है कि इनपुट पते की क्वालिटी खराब हो. इसे दिखाने के लिए, आपके पास अपने डेटाबेस में फ़्लैग कैश मेमोरी में सेव करने का विकल्प है. कैश मेमोरी में सेव किए गए फ़्लैग से पता चलता है कि पूरे पते की क्वालिटी खराब है. वहीं, स्पेल सुधार जैसे ज़्यादा जानकारी वाले फ़्लैग से पते की क्वालिटी से जुड़ी खास तरह की समस्या के बारे में पता चलता है. किसी पते के साथ अगले ग्राहक इंटरैक्शन पर, खराब क्वालिटी के तौर पर फ़्लैग किए गए पते की पुष्टि करने वाले एपीआई को मौजूदा पते पर कॉल किया जा सकता है. पते की पुष्टि करने वाला एपीआई सही पता दिखाएगा. इसे यूज़र इंटरफ़ेस (यूआई) प्रॉम्प्ट की मदद से दिखाया जा सकता है. जब ग्राहक फ़ॉर्मैट किए गए पते को स्वीकार कर लेता है, तो जवाब से इन क्वेरी को कैश मेमोरी में सेव किया जा सकता है:
formattedAddress
postalAddress
addressComponent componentNames
याUspsData standardizedAddress
बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले पते की पुष्टि करने की प्रोसेस लागू करना
ऊपर दी गई चर्चा के आधार पर:
- कारोबार से जुड़ी वजहों से, Address Validation API से मिले रिस्पॉन्स के कुछ हिस्से को कैश मेमोरी में सेव करना ज़रूरी होता है.
- हालांकि, Google Maps Platform की सेवा की शर्तों में यह तय किया गया है कि किस डेटा को कैश मेमोरी में सेव किया जा सकता है.
नीचे दिए गए सेक्शन में, हम सेवा की शर्तों का पालन करने और हाई वॉल्यूम पते की पुष्टि करने की प्रोसेस के बारे में दो चरणों में चर्चा करेंगे.
पहला चरण:
पहले चरण में, हम पता करेंगे कि मौजूदा डेटा पाइपलाइन से ज़्यादा वॉल्यूम वाले पते की पुष्टि करने वाली स्क्रिप्ट को कैसे लागू किया जाता है. इस प्रोसेस की मदद से, पते की पुष्टि करने वाले एपीआई के रिस्पॉन्स में मौजूद, सेवा की शर्तों के मुताबिक खास फ़ील्ड सेव किए जा सकेंगे.
डायग्राम A: नीचे दिया गया डायग्राम, हाई वॉल्यूम पते की पुष्टि करने वाले लॉजिक की मदद से, डेटा पाइपलाइन को बेहतर बनाने का तरीका दिखाता है.
सेवा की शर्तों के मुताबिक, बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले पतों की पुष्टि करते समय,
addressComplete,validationGranularity and validationFlags
को कैश मेमोरी में सेव किया जा सकता है .आपके पास ग्राहक के डेटाबेस में मौजूद किसी UserID के लिए,
addressComplete,validationGranularity and validationFlags, PlaceID
को कैश मेमोरी में सेव करने का विकल्प होता है.
इसलिए, लागू करने के इस चरण के दौरान हम ऊपर बताए गए फ़ील्ड को UserID के लिए कैश मेमोरी में सेव करेंगे.
ज़्यादा जानकारी के लिए, असल डेटा स्ट्रक्चर के बारे में जानकारी देखें.
दूसरा चरण:
पहले चरण में, हमने सुझाव इकट्ठा किए कि इनपुट डेटासेट में कुछ पते अच्छी क्वालिटी के नहीं हैं. अगले चरण में, हम फ़्लैग किए गए इन पतों को लेकर, उन्हें उपयोगकर्ता को दिखाएंगे. साथ ही, सेव किए गए पते को ठीक करने के लिए उनकी सहमति लेंगे.
डायग्राम B: इस डायग्राम में दिखाया गया है कि उपयोगकर्ता की सहमति वाले फ़्लो का एंड-टू-एंड इंटिग्रेशन कुछ इस तरह दिख सकता है:
जब उपयोगकर्ता लॉग इन करता है, तो सबसे पहले यह जांच लें कि क्या आपने अपने सिस्टम में मौजूद, पुष्टि करने वाले किसी फ़्लैग को कैश मेमोरी में सेव किया है. जैसे:
addressComplete
सही है- validationGranularity,
PREMISE
याSUB_PREMISE
नहीं है validationFlags
का नामinferred,spellCorrected,replaced,unexpected
है.- अगर कोई फ़्लैग नहीं है, तो इस बात का बहुत ज़्यादा भरोसा होता है कि कैश मेमोरी में सेव किए गए मौजूदा पते की क्वालिटी अच्छी है और उसे इस्तेमाल किया जा सकता है.
अगर फ़्लैग हैं, तो आपको उपयोगकर्ता को उसका पता ठीक करने/अपडेट करने के लिए यूज़र इंटरफ़ेस (यूआई) के साथ दिखाना चाहिए.
अपडेट किए गए या कैश मेमोरी में सेव किए गए पते का इस्तेमाल करके, पते की पुष्टि करने वाले एपीआई को फिर से कॉल किया जा सकता है. इसके बाद, सही किया गया पता उपयोगकर्ता को दिखाकर, इसकी पुष्टि की जा सकती है.
अगर पते की क्वालिटी अच्छी है, तो पते की पुष्टि करने वाला एपीआई
formattedAddress
दिखाता है.अगर सुधार किए गए हैं, तो आप उपयोगकर्ता को अपना पता बता सकते हैं या कोई सुधार न होने पर उसे स्वीकार कर सकते हैं.
जब उपयोगकर्ता न्योता स्वीकार कर लेता है, तब आपके पास डेटाबेस में
formattedAddress
को कैश मेमोरी में सेव करने का विकल्प होता है.
दूसरा चरण लागू करने वाला सूडो कोड:
If addressComplete is FALSE
OR
If validationGranularity is Not PREMISE OR SUB_PREMISE
OR
If validationFlags is inferred OR spellCorrected OR replaced OR unexpected
{
# This means there are issues with the existing cached address
Call UI to present the address to user
}
Else{
# This means existing address is good
Proceed to checkout
}
नतीजा
ज़्यादा संख्या में पते की पुष्टि करने की सुविधा का इस्तेमाल कई ऐप्लिकेशन में किया जा सकता है. यह आम तौर पर इस्तेमाल किया जाने वाला एक उदाहरण है. इस दस्तावेज़ में कुछ स्थितियों और डिज़ाइन पैटर्न को दिखाने की कोशिश की गई है. इनमें बताया गया है कि Google Maps Platform की सेवा की शर्तों का पालन करते हुए इस तरह के समाधान को कैसे लागू किया जाता है.
इसके अलावा, हमने GitHub पर एक ओपन सोर्स लाइब्रेरी के तौर पर, हाई वॉल्यूम अड्रेस वैलिडेशन को लागू करने का रेफ़रंस दिया है. ज़्यादा आवाज़ वाले पते की पुष्टि करने की सुविधा के साथ काम शुरू करने के लिए, इसे देखें. साथ ही, लाइब्रेरी का इस्तेमाल अलग-अलग स्थितियों में करने के तरीके बताने वाले डिज़ाइन पैटर्न से जुड़ा लेख देखें.
अगले चरण
भरोसेमंद पते की मदद से चेकआउट, डिलीवरी, और कार्रवाइयों को बेहतर बनाने के लिए व्हाइट पेपर डाउनलोड करें. साथ ही, पते की पुष्टि करने की सुविधा की मदद से, चेकआउट, डिलीवरी, और कार्रवाइयों को बेहतर बनाना वेबिनार देखें.
आगे पढ़ने का सुझाव:
- हाई वॉल्यूम अड्रेस की पुष्टि करने के आवेदन
- GitHub पर Python लाइब्रेरी
- पते की पुष्टि करने का डेमो एक्सप्लोर करें
योगदानकर्ता
Google इस लेख को सेव रखता है. मूल रूप से इन योगदान देने वालों ने इसे लिखा है.
मुख्य लेखक:
हेनरिक वाल्व | सॉल्यूशन इंजीनियर
थॉमस एंगलरेट | सलूशन इंजीनियर
सरथक गांगुली | सलूशन इंजीनियर