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

मकसद

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

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

उपयोग के उदाहरण

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

टेस्ट करना

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

पतों की पुष्टि सिर्फ़ एक बार के लिए मान्य होती है

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

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

कई स्थितियों में, पतों की पुष्टि बार-बार करनी पड़ती है:

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

तकनीकी जानकारी

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

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

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

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

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

  • AddressComponent ऑब्जेक्ट से डेटा
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

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

उपयोगकर्ता की सहमति का एक उदाहरण, चेकआउट पेज पर ई-कॉमर्स पते के फ़ॉर्म के साथ सीधे तौर पर इंटरैक्ट करना है. यह माना जाता है कि पैकेज को शिप करने के मकसद से, पते को कैश मेमोरी में सेव किया जाएगा और प्रोसेस किया जाएगा.

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

जवाब को समझना

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

  • Verdict ऑब्जेक्ट में मौजूद addressComplete मार्कर true है,
  • Verdict ऑब्जेक्ट में मौजूद 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 Validation API से मिले जवाब के कुछ हिस्से को कैश मेमोरी में सेव करना ज़रूरी होता है.
  • हालांकि, Google Maps Platform की सेवा की शर्तों के मुताबिक, यह तय किया जाता है कि कौनसा डेटा कैश मेमोरी में सेव किया जा सकता है.

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

पहला चरण:

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

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

alt_text

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

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

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

ज़्यादा जानकारी के लिए, असल डेटा के स्ट्रक्चर के बारे में जानकारी देखें.

दूसरा चरण:

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

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

alt_text

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

नतीजा

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

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

अगले चरण

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

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

योगदानकर्ता

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

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