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

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

आम तौर पर, एपीआई रिस्पॉन्स इन तरीकों से तय होता है कि आपके सिस्टम को किसी पते को कैसे हैंडल करना चाहिए:

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

मुख्य मकसद

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

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

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

वर्कफ़्लो की खास जानकारी

नीचे दी गई टेबल में, आपके सिस्टम से जुड़ी दो कार्रवाइयों के बारे में खास जानकारी दी गई है:

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

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

वर्कफ़्लो

  1. अगर ज़रूरी हो, तो पते के कॉम्पोनेंट की जांच करें.
  2. ग्राहक को पते से जुड़ी समस्याओं को ठीक करने के लिए कहें.
  3. अपडेट किए गए पते की पुष्टि का अनुरोध करें.
  4. (ज़रूरी नहीं) एपीआई के लिए सुझाव एंडपॉइंट पर अनुरोध भेजें. अपडेट किए गए पते मैनेज करना देखें.
  5. पते के साथ आगे बढ़ें.

फ़ैसले के सिग्नल

इनमें से कोई भी लागू होगा:

पते की पुष्टि करें

verdict से मिले जवाब में, डिलीवर किए जा सकने वाले पते के बारे में बताया गया है. हालांकि, इसके ओरिजनल इनपुट में कुछ बदलाव किए गए हैं: यह ऐसा डेटा है जिसकी स्पेलिंग में सुधार किया गया है या जिसकी पुष्टि की जा सकती है.

वर्कफ़्लो

  1. सुधार करने की ज़रूरत है:
    1. अगर ज़रूरी हो, तो पते के कॉम्पोनेंट की जांच करें.
    2. अपडेट किए गए पते की पुष्टि का अनुरोध करें.
    3. (ज़रूरी नहीं) एपीआई के लिए सुझाव एंडपॉइंट पर अनुरोध भेजें. अपडेट किए गए पते मैनेज करना देखें.
    4. पते के साथ आगे बढ़ें.
  2. किसी बदलाव की ज़रूरत नहीं है:
    1. (ज़रूरी नहीं) एपीआई के लिए सुझाव एंडपॉइंट पर अनुरोध भेजें. अपडेट किए गए पते मैनेज करना देखें.
    2. पते के साथ आगे बढ़ें.

फ़ैसले के सिग्नल

नीचे दिए गए सभी लागू होते हैं:

  • validationGranularity में ROUTE या इससे बेहतर होता है. जानकारी का लेवल देखें.
  • addressComplete true है.
  • hasInferredComponents फ़ील्ड true है या hasReplacedComponents फ़ील्ड true है.
पता स्वीकार करें

पता की पुष्टि करने वाले एपीआई से मिले रिस्पॉन्स का मतलब है कि पते की क्वालिटी अच्छी है.

वर्कफ़्लो

दिए गए पते के साथ आगे बढ़ें.

फ़ैसले के सिग्नल

नीचे दिए गए सभी लागू होते हैं:

  • validationGranularity में PREMISE या इससे बेहतर होता है. जानकारी का लेवल देखें.
  • addressComplete true है.
  • कोई कॉम्पोनेंट नहीं या उसका अनुमान लगाया गया या कोई कॉम्पोनेंट बदला गया.

लागू करने के लिए सलाह

यह तय करते समय कि सिस्टम, Address Verified API से मिलने वाले सिग्नल के रिस्पॉन्स कैसे देता है, ये सुझाव ज़्यादा असरदार रिस्पॉन्स मॉडल बनाने में आपकी मदद कर सकते हैं. हालांकि, ये सिर्फ़ सुझाव हैं, इसलिए ध्यान रखें कि लागू करने का तरीका आपके कारोबार के मॉडल के हिसाब से सही होना चाहिए.

सलाह जानकारी
जोखिम का स्तर

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

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

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

पते स्वीकार करें

ग्राहक के सवालों का जवाब न देने पर, सिस्टम को मूल एंट्री स्वीकार करने की अनुमति देना एक अच्छा तरीका हो सकता है.

इन मामलों में, हो सकता है कि ग्राहक ने ऐसा पता डाला हो जो सिस्टम में मौजूद नहीं है, जैसे कि नए निर्माण का पता.

सुझाव/राय देना या शिकायत करना

पते की पुष्टि करने का अनुरोध फिर से जारी करने पर, provideValidationFeedback एंडपॉइंट पर भी अनुरोध भेजा जा सकता है.

इससे Google को पता चलता है कि आपने आखिरी जवाब को कैसे मैनेज किया. अपडेट किए गए पते मैनेज करना देखें.

पता ठीक करें

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

सिग्नल ठीक करें

Address Validation API से आपको कई सिग्नल मिलते हैं. इससे पता चलता है कि पते की समस्या को ठीक करना है या नहीं.

1. पुष्टि का लेवल और कुछ कॉम्पोनेंट मौजूद नहीं हैं

ये दो सिग्नल, किसी समस्या वाले पते का सबसे अच्छा संकेत देते हैं:

  • जब भी validationGranularity फ़ील्ड OTHER होता है, तो आपके सिस्टम को पते के कॉम्पोनेंट के सिग्नल की जांच करनी चाहिए. इससे आपको पता चलेगा कि गड़बड़ी कहां हुई और उसे कैसे ठीक किया जा सकता है.
  • जब भी प्रोसेस किया गया address ऑब्जेक्ट, missingComponentTypes फ़ील्ड दिखाता है, तो आपके सिस्टम को उस कॉम्पोनेंट की जांच करनी चाहिए. छूटे हुए कॉम्पोनेंट भी किसी पते को अधूरे कॉन्टेंट के तौर पर दिखाते हैं और उसे डिलीवर नहीं किया जा सकता.

2. पेज के लिए सही ऑडियंस तय करने के दूसरे तरीके

पता की पुष्टि करने वाला एपीआई, खास समस्याओं का पता लगाने में मदद करने के लिए दूसरे सिग्नल भी देता है:

संदिग्ध कॉम्पोनेंट जब किसी कॉम्पोनेंट के लिए, पुष्टि के लेवल की सूची UNCOMFIRMED_AND_SUSPICIOUS होती है, तो हो सकता है कि कॉम्पोनेंट गलत हो.
कॉम्पोनेंट की समस्या को हल नहीं किया गया unresolvedToken इनपुट का वह हिस्सा है जिसे किसी पते के मान्य हिस्से के तौर पर नहीं पहचाना जाता है.

3. अमेरिका के पते के सिग्नल

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

dpvConfirmation N, D या खाली.

dpvConfirmation के बारे में जानकारी पाने के लिए, अमेरिका के पते मैनेज करना देखें.

पते के उदाहरण

पते की पुष्टि करें

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

ग्राहक को सही प्रॉम्प्ट देने के लिए, आपका लॉजिक, सेवा की ओर से फ़्लैग किए गए कॉम्पोनेंट की पहचान करेगा, ताकि यह तय किया जा सके कि उस कॉम्पोनेंट पर लागू की गई एपीआई की कार्रवाई या उसे फ़्लैग किया गया है या नहीं. जैसे, inferred, replaced या spellCorrected. रेफ़रंस में AddressComponent देखें.

सिग्नल की पुष्टि करें

Address Validation API से आपको कई सिग्नल मिलते हैं. इससे पता चलता है कि पते की पुष्टि की जानी चाहिए या नहीं.

1. पुष्टि की जानकारी का स्तर

ROUTE या इससे बेहतर का validationGranularity स्वीकार किया जा सकता है, लेकिन PREMISE या SUBPREMISE, डिलीवरी में लगने वाले समय का बेहतर संकेत देता है.

2. पेज के लिए सही ऑडियंस तय करने के दूसरे तरीके

ग्राहक को पता डालने की पुष्टि करते समय, नतीजे में यह जानकारी भी दी जाती है, ताकि यह तय किया जा सके कि किन कॉम्पोनेंट की जांच करनी है:

अनुमानित डेटा जब hasInferredComponents फ़ील्ड true होता है, तो आपको पता चलता है कि एपीआई ने पते के अन्य कॉम्पोनेंट से मिली जानकारी को भरा है.
बदला गया डेटा जब hasReplacedComponents फ़ील्ड true होता है, तो एपीआई ने डाले गए डेटा को उस डेटा से बदल दिया जाता है जो पते को मान्य मानता है.

3. अमेरिका के पते के सिग्नल

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

dpvConfirmation S

dpvConfirmation के बारे में जानकारी पाने के लिए, अमेरिका के पते मैनेज करना देखें.

पते का जवाब इसमें missingComponentType फ़ील्ड शामिल है, जिसकी वैल्यू subpremise है.

पते की पुष्टि करने के उदाहरण

पता स्वीकार करें

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

सिग्नल स्वीकार करें

Address Validation API से आपको कई सिग्नल मिलते हैं. इससे पता चलता है कि पते की पुष्टि की जानी चाहिए या नहीं.

1. पुष्टि की जानकारी का स्तर

PREMISE या इससे बेहतर का validationGranularity स्वीकार किया जा सकता है, लेकिन कुछ मामलों में ROUTE अब भी डिलीवर किया जा सकने वाला पता दिखाता है.

2. पेज के लिए सही ऑडियंस तय करने के दूसरे तरीके

अच्छी क्वालिटी वाले पते के नतीजे में यह जानकारी भी दी जानी चाहिए:

  • कोई बदला गया डेटा नहीं है. इस मामले में, hasReplacedComponents: FALSE.
  • कोई कॉम्पोनेंट नहीं बताया गया है. इस मामले में, hasInferredComponents: FALSE.

3. अमेरिका के पते के सिग्नल

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

dpvConfirmation Y

dpvConfirmation के बारे में जानकारी पाने के लिए, अमेरिका के पते मैनेज करना देखें.

पते के उदाहरण स्वीकार करना