ज़्यादा पतों की पुष्टि करने के लिए गाइड

मकसद

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

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

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

अब हम उन मामलों के बारे में जानेंगे जिनमें High Volume Address Validation का इस्तेमाल किया जा सकता है.

टेस्ट करना

अक्सर, आपको हज़ारों पतों की जांच करके, 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 लागू करना

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

  • कारोबार से जुड़ी वजहों से, Address Validation API से मिले जवाब के कुछ हिस्से को कैश मेमोरी में सेव करना ज़रूरी होता है.
  • हालांकि, Google Maps Platform की सेवा की शर्तों के मुताबिक, कुछ डेटा को कैश मेमोरी में सेव नहीं किया जा सकता.

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

पहला चरण:

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

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

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 को कैश मेमोरी में सेव किया जा सकता है.

नतीजा

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

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

अगले चरण

Improve checkout, delivery, and operations with reliable addresses व्हाइटपेपर डाउनलोड करें और Improving checkout, delivery, and operations with Address Validation वेबिनार देखें.

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

योगदानकर्ता

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

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