ज़्यादा तेज़ी से पते प्रोसेस करने के लिए, पते की पुष्टि करने वाले एपीआई का इस्तेमाल करें

कैंपेन का मकसद

डेवलपर के तौर पर, आपको अक्सर ऐसे डेटासेट के साथ काम करना होता है जिनमें ग्राहक के पते होते हैं. शायद उनकी क्वालिटी अच्छी न हो. आपको यह पक्का करना होगा कि पते सही हैं. साथ ही, ग्राहक आईडी की पुष्टि करने से लेकर डिलीवरी और अन्य सभी मामलों में इस्तेमाल किए जा सकते हैं.

पते की पुष्टि करने वाला एपीआई, Google Maps Platform का एक प्रॉडक्ट है. इसका इस्तेमाल पते की पुष्टि करने के लिए किया जा सकता है. हालांकि, यह एक बार में सिर्फ़ एक पते को प्रोसेस करता है. इस दस्तावेज़ में हम पता लगाएंगे कि अलग-अलग स्थितियों में, हाई वॉल्यूम वाले पते की पुष्टि करने की सुविधा कैसे इस्तेमाल की जाए. इन मामलों में, एपीआई टेस्टिंग से लेकर एक बार की जाने वाली पते की पुष्टि और बार-बार किए जाने वाले पते की पुष्टि करना शामिल है.

इस्तेमाल के उदाहरण

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

टेस्ट करना

आप अक्सर हज़ारों पते चलाकर, Address Verified API की जांच करना चाहते हैं. ऐसा हो सकता है कि ये पते, कॉमा सेपरेटेड वैल्यू वाली फ़ाइल में हों और आपको इन पतों की क्वालिटी की पुष्टि करनी हो.

पतों की एक बार की जाने वाली पुष्टि

Address Validation API में शामिल होते समय, आपको उपयोगकर्ता डेटाबेस के हिसाब से अपने पते के डेटाबेस की पुष्टि करनी होती है.

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

पतों की पुष्टि बार-बार की जाती है. इसके लिए कई मामलों की ज़रूरत होती है:

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

तकनीकी चीज़ों की पूरी जानकारी

इस दस्तावेज़ के लिए, हम मानते हैं कि:

  • पते की पुष्टि करने वाले एपीआई को, ग्राहक के डेटाबेस (जैसे, ग्राहक की जानकारी वाला डेटाबेस) के पतों के साथ कॉल किया जा रहा है
  • आप अपने डेटाबेस में अलग-अलग पतों के लिए वैधता फ़्लैग को कैश मेमोरी में सेव कर सकते हैं.
  • जब कोई ग्राहक लॉग इन करता है, तो वैधता की जानकारी देने वाले फ़्लैग, Address Verified API से वापस आते हैं.

प्रोडक्शन के लिए कैश मेमोरी

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

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

  • 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 पर सेट हो

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

  • formattedAddress
  • postalAddress
  • addressComponent componentNamesया
  • UspsData standardizedAddress

हेडलेस (सिर्फ़ बैक-एंड पर काम करने की सुविधा देने वाला) पते की पुष्टि करने की सुविधा लागू करना

ऊपर दी गई चर्चा के आधार पर:

  • कारोबारी वजहों से, जवाब के कुछ हिस्से को Address के तौर पर पुष्टि करने वाले एपीआई से कैश मेमोरी में सेव करना अक्सर ज़रूरी होता है.
  • हालांकि, Google Maps Platform की सेवा की शर्तें यह तय करती हैं कि किस डेटा को कैश मेमोरी में सेव किया जा सकता है.

अगले सेक्शन में, हम सेवा की शर्तों का पालन करने और ज़्यादा पते की पुष्टि करने की प्रक्रिया को लागू करने के बारे में दो चरणों वाली प्रोसेस के बारे में चर्चा करेंगे.

पहला चरण:

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

डायग्राम A: नीचे दिया गया डायग्राम दिखाता है कि हाई वॉल्यूम वाले पते की पुष्टि करने वाले लॉजिक से, डेटा पाइपलाइन को कैसे बेहतर बनाया जा सकता है.

alt_text

सेवा की शर्तों के मुताबिक, addressComponent से यह डेटा कैश मेमोरी में सेव किया जा सकता है:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

इसलिए, लागू करने के इस चरण के दौरान, हम ऊपर दिए गए फ़ील्ड को UserID के लिए कैश मेमोरी में डाल देंगे.

ज़्यादा जानकारी के लिए असल डेटा स्ट्रक्चर पर दी गई जानकारी देखें.

दूसरा चरण:

पहले चरण में, हमें यह जानकारी मिली कि इनपुट डेटासेट में मौजूद कुछ पते शायद अच्छी क्वालिटी के न हों. अगले चरण में, हम फ़्लैग किए गए इन पतों को उपयोगकर्ता को दिखाएंगे और सेव किए गए पते को ठीक करने के लिए उनकी सहमति लेंगे.

डायग्राम B: इस डायग्राम में दिखाया गया है कि उपयोगकर्ता की सहमति के फ़्लो का आखिरी इंटिग्रेशन कैसा दिख सकता है:

alt_text

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

नतीजा

हाई वॉल्यूम वाले पते की पुष्टि करने की सुविधा, इस्तेमाल का एक आम उदाहरण है. कई ऐप्लिकेशन में आपको इस समस्या का सामना करना पड़ सकता है. इस दस्तावेज़ में कुछ स्थितियों और डिज़ाइन पैटर्न को बताया गया है कि इस तरह के समाधान को Google Maps Platform की सेवा की शर्तों के हिसाब से कैसे लागू किया जाए.

इसके अलावा, हमने GitHub पर ओपन सोर्स लाइब्रेरी के तौर पर, ज़्यादा संख्या में पते की पुष्टि करने की जानकारी देने के बारे में भी लिखा है. हाई वॉल्यूम में पते की पुष्टि भी तुरंत शुरू करने के लिए, इसे देखें. साथ ही, अलग-अलग स्थितियों में लाइब्रेरी का इस्तेमाल करने के डिज़ाइन पैटर्न से जुड़ा लेख पढ़ें.

अगले चरण

भरोसेमंद पतों की मदद से चेकआउट, डिलीवरी, और कार्रवाइयों को बेहतर बनाएं व्हाइटपेपर डाउनलोड करें. साथ ही, पते की पुष्टि करने की सुविधा की मदद से चेकआउट, डिलीवरी, और कार्रवाइयों को बेहतर बनाने के वेबिनार को देखें.

आगे पढ़ने के लिए सुझाव:

योगदानकर्ता

Google इस लेख को मैनेज करता है. मूल रूप से इन योगदान देने वालों ने इसे लिखा है.
मुख्य लेखक:

हेनरिक वैलव | सॉल्यूशंस इंजीनियर
थॉमस एंगलरेट | सलूशन इंजीनियर
र्थक गांगुली | सलूशन इंजीनियर