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

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

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

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

कोई भी इवेंट अकेले फ़िल्टरिंग साबित नहीं करता। 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 कुंजी को उसकी रीप्ले अवधि के भीतर फिर से इस्तेमाल करें; अनिश्चितता की स्थिति में अपने-आप दूसरा अनुरोध न भेजें।

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