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

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

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

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

मुख्य मकसद

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

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 है.
  • अनुमानित या बदले गए कोई कॉम्पोनेंट नहीं.

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

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

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

सुधार करने के लिए कहा जाए या डाले गए पते को स्वीकार किया जाए, इस फ़ैसले को लेते समय अपनी स्थिति के हिसाब से, गड़बड़ी की सीमा को ध्यान में रखें.

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

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

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

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

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

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

किसी पते को ठीक करना

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

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

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

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

इन दो सिग्नल से, समस्या वाले पते के बारे में सबसे सही जानकारी मिलती है:

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

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

Address Validation API, कुछ खास समस्याओं का पता लगाने में मदद करने के लिए, अन्य सिग्नल भी उपलब्ध कराता है:

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

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

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

dpvConfirmation N, D या खाली हो.

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

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

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

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

ग्राहक को सही निर्देश देने के लिए, आपका लॉजिक उन कॉम्पोनेंट की पहचान करेगा जिन्हें सेवा ने फ़्लैग किया है. इससे यह पता चलेगा कि एपीआई ने कॉम्पोनेंट पर कौनसी कार्रवाई या फ़्लैग लागू किया है, जैसे कि 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 के बारे में ज़्यादा जानने के लिए, अमेरिका के पतों को मैनेज करना लेख पढ़ें.

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

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