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

मकसद

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

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

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

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

टेस्ट करना

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

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

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

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

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

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

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

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

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

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

पते की पुष्टि करने वाले एपीआई का इस्तेमाल करते समय, अक्सर एपीआई कॉल के रिस्पॉन्स के कुछ हिस्से को कैश मेमोरी में सेव करना होता है. हमारी सेवा की शर्तों के मुताबिक, यह तय किया गया है कि कौनसा डेटा कैश मेमोरी में सेव किया जा सकता है. हालांकि, 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 Validation API से मिले रिस्पॉन्स के कुछ हिस्से को कैश मेमोरी में सेव करना ज़रूरी होता है.
  • हालांकि, Google Maps Platform की सेवा की शर्तों के मुताबिक, यह तय किया जा सकता है कि कौनसा डेटा कैश मेमोरी में सेव किया जाए.

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

पहला चरण:

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

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

alt_text

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

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

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

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

दूसरा चरण:

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

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

alt_text

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

नतीजा

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

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

अगले चरण

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

इसके बारे में और पढ़ने के लिए:

योगदानकर्ता

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

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