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

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

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

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

मुख्य मकसद

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

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 है.
पता स्वीकार करें

Address Validation API के जवाब से पता चलता है कि यह पता अच्छी क्वालिटी का है.

वर्कफ़्लो

सामान लौटाने का पता डालें.

नतीजे के सिग्नल

इनमें से सभी बातें लागू होती हैं:

  • 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 देखें.

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

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

1. पुष्टि की बारीकी

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

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

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

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

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

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

dpvConfirmation S

dpvConfirmation के बारे में जानकारी पाने के लिए, अमेरिका के पते मैनेज करना देखें.
पते का जवाब इसमें missingComponentType फ़ील्ड है, जिसकी वैल्यू subpremise है.

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

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

जब नतीजे से यह पता चलता है कि पते पर डिलीवरी की जा सकती है और खरीदार के साथ बातचीत किए बिना, उसे इस्तेमाल किया जा सकता है, तो आप उस पते को स्वीकार कर लेते हैं.

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

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

1. पुष्टि की बारीकी

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

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

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

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

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

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

dpvConfirmation Y

dpvConfirmation के बारे में ज़्यादा जानने के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.

स्वीकार किए जा सकने वाले पते के उदाहरण

पीछे जाएं
मूल जवाब को समझना