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

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

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

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

मुख्य मकसद

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

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. पुष्टि की बारीकी

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

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

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

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

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

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

dpvConfirmation Y

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

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

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