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

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

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

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

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

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

टेस्ट करना

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

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

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

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

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

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

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

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

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

प्रोडक्शन में इस्तेमाल के लिए कैश मेमोरी में सेव करना

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

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

  • फ़ैसला ऑब्जेक्ट का डेटा

    • inputGranularity
    • validationGranularity
    • geocodeGranularity
    • addressComplete
    • hasUnconfirmedComponents
    • hasInferredComponents
    • hasReplacedComponents

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

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

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

बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले पते की पुष्टि करना

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

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

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

पहला चरण:

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

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

alt_text

  • सेवा की शर्तों के मुताबिक, बिना ग्राफ़िक यूज़र इंटरफ़ेस वाले पते की पुष्टि करते समय, addressComplete,validationGranularity and validationFlags को कैश मेमोरी में सेव किया जा सकता है .

  • ग्राहक डेटाबेस में मौजूद किसी खास UserID के लिए, addressComplete,validationGranularity and validationFlags, PlaceID को कैश मेमोरी में सेव किया जा सकता है.

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

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

दूसरा चरण:

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

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

alt_text

  1. जब उपयोगकर्ता लॉग इन करे, तो सबसे पहले जांच लें कि आपने अपने सिस्टम में किसी भी पुष्टि करने वाले फ़्लैग को कैश मेमोरी में सेव किया है या नहीं, जैसे कि:

    • addressComplete सही है
    • validationGranularity PREMISE या SUB_PREMISE नहीं होना चाहिए
    • validationFlags का नाम inferred,spellCorrected,replaced,unexpected है.
      • अगर कोई फ़्लैग नहीं है, तो इस बात का पूरा भरोसा होगा कि कैश मेमोरी में सेव किए गए मौजूदा पते की क्वालिटी अच्छी है और उसका इस्तेमाल भी किया जा सकता है.

  2. अगर फ़्लैग मिलते हैं, तो आपको उपयोगकर्ता के पते को ठीक/अपडेट करने के लिए उसे यूज़र इंटरफ़ेस (यूआई) दिखाना चाहिए.

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

  4. अगर पते की क्वालिटी अच्छी है, तो पते की पुष्टि करने वाला एपीआई formattedAddress दिखाता है.

  5. अगर सुधार किए गए हों, तो उस पते को उपयोगकर्ता के साथ शेयर किया जा सकता है या अगर कोई सुधार न हो, तो उसे बिना किसी परेशानी के स्वीकार किया जा सकता है.

  6. उपयोगकर्ता की मंज़ूरी मिलने के बाद, आपके पास डेटाबेस में formattedAddress को कैश मेमोरी में सेव करने का विकल्प होता है.

दूसरे चरण को लागू करने वाला सूडो कोड:

If addressComplete is FALSE

OR

If validationGranularity is Not PREMISE OR SUB_PREMISE

OR

If validationFlags is inferred OR spellCorrected OR replaced OR unexpected
  {

    # This means there are issues with the existing cached address

    Call UI to present the address to user

}
Else{

    # This means existing address is good
  Proceed to checkout
}

नतीजा

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

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

अगले चरण

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

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

योगदानकर्ता

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

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