वाहिन्या
एकाच ग्राफमधून कोणालाही पोहोचण्याचे चार मार्ग
स्मरणपत्र SMS ने जाते कारण लोक ते काही मिनिटांत वाचतात. गोष्ट ईमेलने जाते कारण तिला जागा असतो. खांद्यावरील थाप पुशने जाते. टिकट लायक ग्राहकाला छापलेले आणि टपाळ्याने पाठवलेले काहीतरी मिळते. संदेश कोणता मार्ग वापरेल हे नोडचे गुणधर्म आहे — आपण विकत घेऊन, शिकून आणि सुसंगत करावे लागणाऱ्या वेगळ्या साधनाचे नाही.
ई-मेल
आपल्या दस्तऐवजातून ईमेल क्लायंट्स खरोखर हवा त्या आकारात रेंडर केलेले: टेबल्स, इनलाइन CSS, Outlook साठी flex किंवा grid नाही, डार्क-मोड-सुरक्षित रंग आणि आपल्यासाठी तयार केलेला साधा मजकूर पर्याय.
List-Unsubscribe-Post सह एक-क्लिक अनसब्सक्राइब, जसे RFC 8058 आणि आता मोठे इनबॉक्स प्रदाते मागतात. आणि प्रकाशनावेळी आकार तपासणी, कारण Gmail सुमारे 102 KB वर कापते आणि कापलेला संदेश कोणीही न पाहणाऱ्या भागाच्या तळाशी आपला अनसब्सक्राइब दुवा लपवतो.
SMS
आजच वाचायचा असलेल्या संदेशासाठी: उद्याची भेट, रविवारी संपणारी ऑफर. लहान, आणि जवळपास लगेच वाचला जाणारा — आणि त्यामुळेच त्याचा गैरवापर करू नये.
पाठवण्यापूर्वी विभाग मोजले जातात. GSM-7 आपल्याला १६० अक्षरे देते; एक इमोजी, वक्र उद्धरण चिन्ह किंवा विस्तार तक्त्याबाहेरील एक पोलिष उच्चार चिन्ह संपूर्ण संदेश UCS-2 मध्ये बदलते — प्रति विभाग ७० अक्षरे — आणि एक असा संदेश जो आपल्याला एक इतका खर्चील वाटत होता आता तीन इतका खर्चील बनतो. आपल्याला ती संख्या पाठवण्यापूर्वी दिसते, बिलावर नाही. STOP आणि त्याचे समतुल्य शब्द सेवेमध्ये आदरले जातात, कारण बहुतेक बाजारांत ती कायदेशीर आवश्यकता आहे, वैशिष्ट्य नाही.
पुश करा
VAPID कीज् आणि RFC 8291 पेलोड एन्क्रिप्शनसह वेब पुश, iOS APNs द्वारे, Android FCM द्वारे, आणि आधीच जोडलेल्या अ‍ॅप्ससाठी सॉकेटवरील अ‍ॅप-मधील मार्ग.
डिव्हाइस रजिस्ट्रीमध्ये प्रत्येक संपर्कासाठी, प्रत्येक अ‍ॅपसाठी, प्रत्येक एंडपॉइंटसाठी एक ओळ असते, आणि प्रदाताकडून आलेला 410 किंवा 404 ती ओळ लगेच काढून टाकतो. कधीही काढले न जाणारे टोकन शांतपणे आपला वितरण दर बिघडवतात आणि पुढील प्रत्येक मोजमाप चुकीचे करतात — म्हणूनच काढण्यापेक्षा महत्त्वाचे काहीही नाही.
छापलेली पत्रे
तोच सर्जनशील दस्तऐवज, प्रिंट CSS द्वारे PDF मध्ये रेंडर करून, पत्त्यासह टपाळ्याने पाठवलेले. वाढदिवसासाठी, उच्च-मूल्याच्या ग्राहकासाठी, ईमेल न वाचणाऱ्या प्रेक्षकांसाठी — आणि इतर सर्वांचे प्रतिस्पर्धी इनबॉक्समध्ये असताना आपण दारावर असण्याच्या क्षणासाठी.
हा एक सामान्य नोड आहे. त्याच्या समोर तीच प्रतीक्षा असते, तीच ध्येय तपासणी ते रद्द करते, आणि तेच संमती खाते ठरवते की आपण तो पाठवू शकता की नाही.
आपले स्वतःचे पाठवणे आणा
ClickSomo जाणीवपूर्वक आणि कायमचा कोणताही मेल सर्व्हर चालवत नाही. आपण प्रेषक ओळख जोडता: पाठवण्याच्या मार्गाशी बांधलेला एक पत्ता. तो एकतर आपला स्वतःचा SMTP मेलबॉक्स आहे — आपल्या होस्टिंग आधीच देत असलेल्यांसह — किंवा आपण आधीच पैसे देत असलेला प्रदाता, जसे SendGrid.
एका प्रोजेक्टमध्ये अनेक असू शकतात. ट्रान्झॅक्शनल मेलसाठी एक मेलबॉक्स, बल्कसाठी एक प्रदाता, आणि फनल नोड कोणता वापरायचा ते निवडतो. प्रत्येक ओळखीची स्वतःची दर मर्यादा असते, कारण लहान मेलबॉक्सची मर्यादा कमी असते आणि त्यावर जोरात वार केल्याने खाते फक्त दर-मर्यादित होण्याऐवजी निलंबित होते.
सिस्टम तुम्हाला मोडू न देणारा एक नियम आहे: ट्रान्झॅक्शनल म्हणून चिन्हांकित केलेल्या डोमेनवर बल्क ट्रॅफिक कधीही जात नाही. जर एखाद्या डोमेनवरून साइन-इन मेल आणि रसीद पाठवल्या जात असतील, तर तिथे बल्क आयडेंटिटी तयार करता येणार नाही. एक वाईट कॅम्पेन — आपला असो वा कोणत्याही दुसऱ्याचा — आपल्या स्वतःच्या पासवर्ड रीसेटमध्ये व्यत्यय आणू शकत नाही.
परिणाम, जोच खरा उद्देश आहे: प्रति-संदेश कोणताही एकत्रित खर्च नाही, कारण एकत्र करण्यासारखे काहीही नाही. आपली प्रतिष्ठा केवळ आपलीच असते आणि अपरिचितांसोबत सामायिक केली जात नाही.
- 1पत्ता आणि होस्टहोस्ट, पोर्ट, क्रेडेन्शियल्स, TLS मोड आणि आपण ठरवलेली दर-मर्यादा.
- 2DNS तपासलेआपल्याला लागणारी SPF, DKIM आणि DMARC रेकॉर्ड्स, नंतर पडताळली जातात — आणि नंतर पुन्हा तपासली जातात, कारण कोणी झोन फाइल सुव्यवस्थित करताना रेकॉर्ड्स बदलतात.
- 3रिटर्न पाथएका खऱ्या मेलबॉक्सकडे निर्देशित, जो बाउंस सूचना मिळवतो, वाचतो आणि वर्गीकृत करतो. SMTP कडे वेबहुक नसतो; लहान प्रेषकाला खरी बाउंस हाताळणी अशाच मिळते.
- !नाकारलेट्रान्झॅक्शनल म्हणून चिन्हांकित डोमेनवर बल्क आयडेंटिटी. आता एक ओळीचे धोरण, नंतर दुरुस्त न होणारी गोधूळ.
आपला पत्ताआपली प्रतिष्ठामार्कअप नाही
प्रवेशाचे चार मार्ग. संदेश स्वतास अनुरूप असलेला निवडतो.
खरोखर उपयुक्त असलेला भाग
एकच डिलिव्हरी शब्दावली, संदेश कोणताही प्रदाता वाहून नेवो
प्रत्येक प्रदाता डिलिव्हरीचा वेगळा अहवाल देतो. SendGrid स्वाक्षरी केलेले वेबहुक पोस्ट करतो. साधे SMTP खाते काहीही पोस्ट करत नाही, आणि त्याचे बाउंस माणसाने वाचण्यासाठी लिहिलेल्या ई-मेलच्या रूपात येतात. वरील कोणतेही सिस्टम त्यांना पाहण्यापूर्वी दोन्ही एकाच अकरा घटनांमध्ये प्रमाणित केले जातात.
- 1रांगेत · पाठवले · वितरित · पुढे ढकललेसंदेशाची प्रगती, अशा शब्दांत ज्यांचा अर्थ प्रत्येक प्रदात्यावर एकच असतो.
- 2open · clickक्लिकसाठी URL सह. बॉट ट्रॅफिक लपवला जात नाही, तर अहवालात वेगळा दाखवला जातो.
- 3सॉफ्ट_बाऊन्स · हार्ड_बाऊन्स · तक्रारहार्ड बाउंस आणि तक्रार दोन्ही कायमची सप्रेशन नोंद लिहितात.
- 4unsubscribe · failedअनसबस्क्राइब एकाच वेळी सर्वत्र लागू होतो, पाठवण्याच्या सेवेतही.
- iहे महत्त्वाचे का आहेप्रदाता बदलण्याने वरील काहीही बदलत नाही — अहवाल नाही, सेगमेंट नाही, फनेल अटी नाहीत. ही बोली दारावरच थांबते.
SMS आणि पुशसाठीही त्याच घटना
पाठवणे चुकीचे झाल्यास काय होते
रीट्राय एक्सपोनेन्शियल बॅकऑफ वापरतात आणि शांतपणे न पडता डेड-लेटर क्यूमध्ये समाप्त होतात. प्रदात्याकडून आलेला 4xx पुन्हा पाठवला जातो; संदेश अस्वीकार्य असल्याचे दर्शवणारा 5xx पुन्हा पाठवला जात नाही, कारण तो कायमचा रीट्राय करणे हीच खाते निलंबित होण्याची कारणे आहे.
सप्रेशन येथेच नव्हे तर पाठवण्याच्या सेवेतही लागू केले जाते, त्यामुळे प्रदाता बदलून आपण दोन वर्षांपूर्वी सप्रेस केलेला पत्ता पुन्हा जिवंत होऊ शकत नाही. आणि प्रति-आयडेंटिटी समांतरता मर्यादांमुळे मोठा कॅम्पेन लहान मेलबॉक्सला पहिल्या तीस सेकंदात ओझ्याने दडपून टाकण्याऐवजी त्याच्या गतीनुसार चालतो.
जाणीवपूर्वक बांधले न गेलेले: आपला स्वतःचा मेल ट्रान्सफर एजंट नाही, समर्पित IP पूल नाहीत, वॉर्म-अप शेड्युलर नाही, फीडबॅक-लूप नोंदणी नाही. हे खरे कष्टाचे काम आहे आणि ते त्या पक्षाचे आहे ज्याची प्रतिष्ठा दांव्यावर असते — आपला प्रदाता, किंवा आपले स्वतःचे मेलबॉक्स. ते येथे बांधणे म्हणजे आपले पाठवणे अपरिचितांसोबत सामायिक करणे, आणि हीच ती गोष्ट आहे जी हा डिझाइन नाकारतो.