SMS

मेरे SMS संदेश कैरियर द्वारा क्यों फ़िल्टर किए जा रहे हैं?

कैरियर फ़िल्टरिंग तब डिलीवरी रोक सकती है जब कोई मैसेज, सेंडर या ट्रैफ़िक पैटर्न नेटवर्क की जाँच में विफल होता है।

एक स्वीकृत SMS अभी भी अमान्य नंबर, अनुपलब्ध हैंडसेट या नेटवर्क समस्या के कारण विफल हो सकता है। मैसेज रिकॉर्ड, डिलीवरी इवेंट और लौटाई गई त्रुटि इन परिणामों को फ़िल्टरिंग से अलग पहचानने में सहायता करते हैं।

संदिग्ध फ़िल्टर की जाँच कैसे करें?

आप संदेश रिकॉर्ड की तुलना उसके SMS इवेंट से करते हैं। इवेंट परिणाम बताता है; त्रुटि और प्रदाता का विवरण उसे समझने में मदद करते हैं।

इवेंटइवेंट आपको क्या बताता है
sms.rejectedप्रोसेसिंग या डाउनस्ट्रीम प्रोवाइडर ने स्वीकृत मैसेज को अस्वीकार कर दिया।
sms.failedएक स्थायी विफलता रिपोर्ट की गई।
sms.undeliveredएक पुनर्प्राप्त-योग्य विफलता रिपोर्ट की गई, जैसे अनुपलब्ध सब्सक्राइबर या नेटवर्क समस्या।
sms.expiredप्रोवाइडर ने समय-सीमा समाप्ति रिपोर्ट की।

कोई भी इवेंट अकेले फ़िल्टरिंग साबित नहीं करता। Bird की डिलीवरी-रिसीट मैपिंग में, carrier_rejected का प्रोवाइडर कारण content_rejected बन जाता है। अनमैप्ड कारण unknown बन जाता है, जिसकी जाँच ज़रूरी है और जिसका कारण असंबंधित हो सकता है। रिसीट का स्टेटस इवेंट को उसके कारण से अलग निर्धारित करता है, इसलिए कैरियर रिजेक्शन विभिन्न विफलता इवेंट के साथ आ सकता है।

त्रुटि कैटलॉग में blocked_by_carrier और sender_unregistered परिभाषित हैं। इनके न मिलने से फ़िल्टरिंग की संभावना खत्म नहीं होती: Bird, carrier_rejected को content_rejected और मैप न किए गए कारणों को unknown में बदलता है। लौटाया गया वास्तविक कोड जाँचें, अपरिचित मान सुरक्षित रखें और प्रदाता का विवरण बनाए रखें।

कौन-से विवरण सहेजने चाहिए?

मैसेज ID, सेंडर, गंतव्य, सबमिशन समय, इवेंट टाइप, नॉर्मलाइज़्ड error.code, विवरण और carrier_error_code सहेजें। विफलताओं को गंतव्य, सेंडर और मैसेज टाइप के अनुसार समूहित करें; एक अकेली विफलता, भेजे गए मैसेज के एक सुसंगत समूह को प्रभावित करने वाले बदलाव से कम साक्ष्य देती है।

नॉर्मलाइज़्ड कोड आपके ऐप्लिकेशन की हैंडलिंग के लिए स्थिर फ़ील्ड है। विवरण डायग्नोस्टिक टेक्स्ट है, इसलिए इसे एक निश्चित कॉन्ट्रैक्ट के रूप में पार्स न करें। carrier_error_code उपलब्ध होने पर भेजने वाले प्रोवाइडर का अधिक विस्तृत कोड रखता है; यह मोबाइल कैरियर का अपना कोड होने की गारंटी नहीं है। प्रोवाइडर कोई कोड न देने पर या प्रोवाइडर हैंडऑफ़ से पहले विफलता होने पर यह खाली हो सकता है।

उदाहरण के लिए, content_rejected आपको रिपोर्ट किए गए रिजेक्शन की ओर इंगित करता है, invalid_destination प्राप्तकर्ता नंबर की ओर, और provider_unavailable नेटवर्क या क्षमता परिणाम की ओर। unknown कारण अनसुलझा छोड़ देता है। जब ये विवरण विफलता की व्याख्या न करें तो मैसेज ID और उपलब्ध प्रोवाइडर कोड सपोर्ट के साथ साझा करें।

क्या अपने सेंडर को रजिस्टर करना फ़िल्टरिंग रोकता है?

रजिस्ट्रेशन लागू सेंडर प्रोग्राम की आवश्यकता पूरी करता है; यह डिलीवरी की गारंटी नहीं देता। सेंडर को गंतव्य के लिए भी पात्र होना चाहिए, और मैसेज तथा ट्रैफ़िक को संबंधित आवश्यकताएँ पूरी करनी चाहिए।

लोकल नंबरों के साथ US A2P मैसेजिंग के लिए, पूर्ण 10DLC रजिस्ट्रेशन जाँचें: ब्रांड, कैम्पेन और नंबर लिंकेज। एक स्वीकृत ब्रांड या कैम्पेन अपने आप आपके हर नंबर को लिंक नहीं करता। टोल-फ़्री और शॉर्ट-कोड प्रोग्रामों की आवश्यकताएँ अलग हैं। अन्य गंतव्यों के लिए सेंडर-नेम रजिस्ट्रेशन आवश्यक हो सकता है।

सेंडर चुनने की योजना बनाने के लिए SMS गंतव्य का उपयोग करें, फिर लॉन्च से पहले लागू आवश्यकताएँ और अपने वर्कस्पेस की रजिस्ट्रेशन स्थिति की पुष्टि करें। कंट्री गाइड एक संदर्भ स्नैपशॉट है, इस बात का प्रमाण नहीं कि आपका सेंडर स्वीकृत है।

ऑप्ट-आउट विफलता पर मुझे क्या करना चाहिए?

प्राथमिकता को सुरक्षित रखें। Bird-सप्रेस्ड सेंडर-और-प्राप्तकर्ता पेयर पर भेजने को API पर E12077 के साथ अस्वीकार किया जाता है; यह रिफ़्यूज़ल कोई मैसेज या मैसेज इवेंट नहीं बनाता। recipient_opted_out की डाउनस्ट्रीम रिपोर्ट अलग है: यह एक स्वीकृत मैसेज का परिणाम है और Bird को पेयर के लिए सप्रेशन रिकॉर्ड करने का कारण बनती है।

समर्थित ऑप्ट-आउट कीवर्ड भेजने वाले और प्राप्तकर्ता की जोड़ी के लिए रोक बना सकते हैं। जोड़ी-स्तर के रोक इवेंट हर वर्कस्पेस पसंद या ग्राहक सहायता से मिले हर अनुरोध को नहीं दर्शाते। ऑडियंस चुनते समय इन व्यापक पसंदों को शामिल करें। ऑप्ट-आउट से बचने के लिए भेजने वाला न बदलें।

फिर से प्रयास करने से पहले मुझे क्या जाँचना चाहिए?

  1. सेंडर तैयारी। इस ट्रैफ़िक के लिए आवश्यक सेंडर टाइप, रजिस्ट्रेशन और गंतव्य एक्सेस की पुष्टि करें।
  2. अनुमति और प्रासंगिकता। पुष्टि करें कि व्यक्ति ने इस उद्देश्य के लिए सहमति दी थी और उस अनुमति को वापस नहीं लिया है।
  3. कंटेंट और लिंक। व्यवसाय को स्पष्ट रूप से पहचानें, उचित लिंक का उपयोग करें और गंतव्य की कंटेंट आवश्यकताओं की समीक्षा करें। केवल लिंक बदलना डिलीवरी पात्रता स्थापित नहीं कर सकता।
  4. ट्रैफ़िक और समय। विफल भेजे गए मैसेज की तुलना अपने सामान्य पैटर्न, क्यूइंग और रूट की सीमाओं से करें। बार-बार वही अस्वीकृत कंटेंट सबमिट करना कारण ठीक किए बिना लागत बढ़ा सकता है।
  5. रिपोर्ट की गई विफलता। दोबारा भेजने से पहले स्थायी रिफ़्यूज़ल की जाँच करें। अस्पष्ट API रिस्पॉन्स के लिए, अपनी रीप्ले विंडो के भीतर मूल idempotency key का पुन: उपयोग करें; अनिश्चितता को स्वचालित रूप से दूसरे रिक्वेस्ट में न बदलें।

SMS रूटिंग ऑपरेटर को सौंपने से पहले गंतव्य नियंत्रण लागू करती है। SMS इंटीग्रेशन हर स्वीकार किए गए अनुरोध को उसके संदेश रिकॉर्ड और डिलीवरी इवेंट के जरिए ट्रैक करता है।

संक्षेप में

  1. विफल डिलीवरी जाँच का शुरुआती बिंदु है।

    इवेंट, सामान्यीकृत त्रुटि और प्रदाता का विवरण विफलता बताते हैं। अज्ञात कारण से ऑपरेटर की फ़िल्टरिंग साबित नहीं होती।

  2. रजिस्ट्रेशन एक आवश्यकता है, डिलीवरी की गारंटी नहीं।

    कुछ बदलने का निर्णय लेने से पहले सेंडर, गंतव्य, कंटेंट, अनुमति और ट्रैफ़िक पैटर्न की जाँच करें।

  3. ऑप्ट-आउट एक प्राथमिकता है जिसे सुरक्षित रखना है।

    सप्रेस्ड पेयर के लिए API रिफ़्यूज़ल और डाउनस्ट्रीम ऑप्ट-आउट रिपोर्ट में अंतर करें, और व्यक्ति के अनुरोध के पूरे दायरे का सम्मान करें।

  4. साक्ष्य को मैसेज के साथ सहेजें।

    मैसेज ID, गंतव्य, सेंडर, समय, इवेंट और त्रुटि विवरण सहेजें ताकि आप किसी पैटर्न की जाँच कर सकें या एक उपयोगी सपोर्ट केस उठा सकें।

व्यवहार में लाएँ।

इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।

अभ्यास करें और इम्प्लीमेंटेशन ब्रीफ़ पाएँ

उसी नेटवर्क पर बनाएँ।

एक टेस्ट API key आपको तुरंत मिल जाती है। भुगतान विधि जोड़ने और सेंडर सत्यापित करने पर प्रोडक्शन अनलॉक होता है।

आपका अगला आइडिया।
जुड़ने के लिए तैयार।