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

मकसद

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

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

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

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

टेस्ट करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जवाब को समझना

अगर पते की पुष्टि करने वाले एपीआई के रिस्पॉन्स में ये मार्कर शामिल हैं, तो आपको भरोसा हो सकता है कि इनपुट पते की क्वालिटी, डिलीवर की जा सकती है:

  • 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 को मौजूदा पते के साथ कॉल किया जा सकता है. पते की पुष्टि करने वाला एपीआई, सही किया गया पता दिखाएगा. इसे यूज़र इंटरफ़ेस (यूआई) प्रॉम्प्ट का इस्तेमाल करके दिखाया जा सकता है. जब ग्राहक फ़ॉर्मैट किए गए पते को स्वीकार कर लेता है, तो रिस्पॉन्स से ये चीज़ें कैश मेमोरी में सेव की जा सकती हैं:

  • 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. अगर पते की क्वालिटी अच्छी है, तो पते की पुष्टि करने वाला एपीआई, formattedAddress दिखाता है.
  5. अगर सुधार कर दिए गए हैं, तो उस पते को उपयोगकर्ता को दिखाया जा सकता है या अगर कोई सुधार नहीं किया गया है, तो उसे चुपचाप स्वीकार किया जा सकता है.
  6. उपयोगकर्ता के स्वीकार करने के बाद, formattedAddress को डेटाबेस में कैश मेमोरी में सेव किया जा सकता है.

नतीजा

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

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

अगले चरण

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

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

योगदानकर्ता

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

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