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

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

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

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

मुख्य मकसद

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

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 को पता चलता है कि आपने जवाब को कैसे मैनेज किया. अपडेट किए गए पते मैनेज करना देखें.

पता ठीक करें

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

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

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

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

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

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

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

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

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

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

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

dpvConfirmation N, D या खाली.

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

पते के उदाहरण ठीक करना

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

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

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

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

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

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

ROUTE या बेहतर का validationGranularity स्वीकार किया जाता है, लेकिन PREMISE या SUBPREMISE से कोई भी डिलीवरी की जा सकती है.

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

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

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

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

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

dpvConfirmation S

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

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

पते की पुष्टि करना

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

पता तब स्वीकार किया जाता है, जब नतीजा इस बात पर पूरा भरोसा करता है कि इस पते पर डिलीवरी की जा सकती है. साथ ही, डाउनस्ट्रीम प्रोसेस में, ग्राहक से इंटरैक्शन किए बिना भी उसका इस्तेमाल किया जा सकता है.

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

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

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

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

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

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

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

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

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

dpvConfirmation Y

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

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