क्रिएटिभ
टेम्प्लेट होइन, दस्तावेज
तपाईंले लेख्ने कुरा प्रकाशित स्किमासहितको ब्लक वृक्ष हो। बाहिर जाने कुरा त्यही दस्तावेज लक्ष्यअनुसार रेन्डर भएको रूप हो — इमेल, पेज, फारम, SMS, पुश वा प्रिन्ट। दुवै जानाजान छुट्टाछुट्टै छन्, किनकि सम्पादक बदलिन सक्छ तर रेन्डरिङ बदलिँदैन, र अन्यथा ढाँट्नु भनेको एउटै सन्देशका छ वटा अमिल्ने संस्करण भएको मार्केटिङ उपकरण बन्नु हो।
छ लक्ष्य, एउटै स्रोत
हरेक लक्ष्यका स्वादको विषय नभई अनिवार्य प्रतिबन्धहरू हुन्छन्, र रेन्डररले ती जान्छ — तपाईंलाई जान्नु पर्दैन।
इमेल भनेको टेबल र इनलाइन CSS हो, flex र grid बिना किनकि Outlook ले अझै मेलको लेआउटका लागि Word प्रयोग गर्छ, तपाईंका लागि स्वतः बनेको सादा पाठ विकल्प, डार्क-मोड क्लाइन्टले रङ उल्ट्याउँदा पनि टिक्ने रङहरू, र Gmail ले काट्न सुरु गर्ने करिब १०२ KB को आकार सीमा।
पेज भनेको सामान्य आधुनिक रेस्पोन्सिभ HTML हो, स्लगअन्तर्गत प्रकाशित, चाहनुहुन्छ भने तपाईंकै डोमेनमा। फारम भनेको फिल्ड बाइन्डिङ, मान्यता जाँच, हनीपट र दर सीमासहितको पेज हो — र यो नै तपाईंका सम्पर्कहरूमा पुग्ने त्यो एक वैध मार्ग हो जसले consent आधार बनाउन सक्छ।
SMS ले टाइप गर्दागर्दै सेगमेन्ट गणना गर्छ। पुश भनेको शीर्षक, मुख्य पाठ, आइकन, कार्यहरू र डिप लिंक हो। पत्र भनेको प्रिन्ट CSS लाई PDF मा रेन्डर गरी ठेगाना लगाई पोस्ट गरिने कुरा हो।
दस्तावेज आफैं प्रकाशित स्किमासहितको सेटअपका रूपमा, निजी टेबलमा लुकाइएको नभई इकोसिस्टमको दस्तावेज सेवामा भण्डारण गरिन्छ। जसको अर्थ कुनै दिन राम्रो सम्पादक आयो भने, त्यसले ती दस्तावेजहरू नै सम्पादन गर्छ र माथिको कुनै कुरामा परिवर्तन हुँदैन।
- 1इमेलटेबल, इनलाइन CSS, पाठ विकल्प, डार्क-मोड सुरक्षित, ~१०२ KB सीमा।
- 2पेजस्लगअन्तर्गत रेस्पोन्सिभ HTML, तपाईंकै डोमेनमा।
- 3फारमबाइन्डिङ, मान्यता जाँच, हनीपट, दर सीमासहित पेज।
- 4smsलाइभ GSM-7 / UCS-2 सेगमेन्ट गणकसहितको पाठ।
- 5पुशशीर्षक, मुख्य पाठ, आइकन, कार्यहरू, डिप लिंक।
- 6पत्रCSS लाई PDF मा छाप्नुहोस्।
- iजोडसम्पादक परिवर्तनयोग्य छ; लक्ष्यहरू होइनन्। त्यसैले दस्तावेजसँग प्रकाशित स्किमा छ।
प्रत्येक लक्ष्य अनुसार क्यास गरिएको रेन्डर गरिएको आउटपुट
मर्ज चरहरू
अज्ञात चर प्रकाशनमा असफल हुन्छ, पठाउँदा मौन रूपमा होइन
हरेक टेम्प्लेटिङ भाषाको पूर्वनिर्धारित व्यवहार भनेको हराइरहेको कुञ्जीका लागि केही पनि रेन्डर नगर्नु हो। इमेलमा यसको अर्थ चालीस हजार मानिसलाई "नमस्ते ," पुग्नु हो, र जवाफ आउन थालेपछि मात्र कसैलाई थाहा हुन्छ। त्यसैले दस्तावेजलाई प्रकाशन गर्नुअघि चर शब्दावलीविरुद्ध प्रमाणित गरिन्छ।
तपाईंले के इन्टरपोलेट गर्न सक्नुहुन्छ
सम्पर्कको इमेल, नाम, फोन र लोकेल; attrs.*, जुन खुला छ किनभने विशेषताहरू तपाईंकै हुन्; तपाईंको संस्थाको नाम र डाँचो ठेगाना; अनसब्सक्राइब र प्राथमिकता लिंकहरू; र सन्देशकै विषय र प्रिहेडर।
जानाजानी गरेर "रेकर्डमा भएको जे पनि" भन्नुको सट्टा सूची बनाइएको छ। सम्पर्क पङ्क्तिमा आन्तरिक पहिचानकर्ताहरू पनि हुन्छन्, र ती मध्ये कुनै पनि सन्देशमा हुनु हुँदैन।
फलब्याक हराइरहेको चर होइन
{{first_name | default:there}} एउटा परिचित चर हो जुन यो विशेष सम्पर्कसँग नहुन सक्छ — आयात गरिएको सूची जहाँ आधा पङ्क्तिमा नाम थिएन। त्यसले फलब्याक रेन्डर गर्छ र पूर्ण रूपमा ठीक छ।
अस्वीकार गरिने कुरा {{frist_name}} हो: कसैका लागि पनि नअस्तित्वमा रहेको चर। पठाउने समयमा दुवै एकै जस्ता देखिन्छन्। प्रकाशनको समयमा भने तिनीहरू पूर्ण रूपमा फरक हुन्छन्, त्यसैले जाँच त्यहीँ हुन्छ।
एउटै शब्दावली प्रत्येक लक्ष्यमा काम गर्छ, त्यसैले इमेलका लागि लेखिएको वाक्यांश SMS मा र ल्यान्डिङ पेजमा पुनः लेखिएको बिना रेन्डर हुन्छ। र first_name भण्डारण गरिएको होइन, रेन्डरको समयमा पूरा नामबाट निकालिन्छ — किनभने भण्डारण गरिएको विभाजन त्यो व्यक्तिका लागि गलत विभाजन हो जसको नाम धारणाअनुरूप बस्दैन।
एक पटक लेख्नुहोस्। यो च्यानलअनुसार सजिएर आउँछ।
बाहिर जानुअघि
तपाईंले अझै सुधार गर्न सक्ने अवस्थामा हुँदा हुने जाँचहरू
Gmail क्लिप
करिब 102 KB भन्दा माथि, Gmail ले सन्देश काट्छ र बाँकी अंश त्यस्तो लिंकपछि लुकाउँछ जुन धेरैजना कहिल्यै थिच्दैनन् — तपाईंको अनसब्सक्राइब समेत, पूरै तल। रेन्डररले नाप्छ र प्रकाशनमा चेतावनी दिन्छ।
तस्बिरको तौल
चार मेगाबाइटको हिरो फोटोले आकार बजेट नष्ट गर्छ र फोनमा नराम्रो देखिन्छ। तस्बिरहरू अपलोडको बेला रिसाइज र रूपान्तरण गरिन्छ, जुन सजिलो कुरा होइन, डेलिभरेबिलिटीको विषय हो।
इनबक्स प्रिभ्यू
सन्देश डेस्कटप र मोबाइल चौडाइमा रेन्डर र फोटो खिचिन्छ, त्यसैले सूची दृश्यले त्यसको नाम होइन, वास्तवमा कस्तो देखिन्छ भन्ने देखाउँछ। कुनै सशुल्क प्रिभ्यू सेवा सम्लग्न छैन।
वास्तविक परीक्षण पठाउने
आफैलाई पठाउनुहोस्, त्यही रेन्डरर र त्यही पठाउने पहिचानबाट जुन वास्तविक प्राप्तकर्ताले पाउँथ्यो। फरक कोड पथ लिने प्रिभ्यूले पठाइने सन्देशबारे केही पनि प्रमाणित गर्दैन।
टाँसिएको HTML स्यानिटाइज गरिन्छ
अरू ठाउँबाट टाँसिएको सामग्री भण्डारण हुनुअघि स्यानिटाइजरबाट जान्छ, किनभने मार्केटिङ इमेल कसैको क्लिपबोर्डमा के थियो भनेर पत्ता लगाउने ठाउँ होइन।
रुचि भए Markdown
Markdown मा लेख्नुहोस् र रेन्डर गराउनुहोस्। मोडेललाई इमेल HTML माग्नुभन्दा धेरै भरपर्दो, र यहीले एजेन्टले सन्देश लेख्ने कुरालाई डेमो होइन, व्यवहार्य विचार बनाउँछ।
आफ्नै वेबसाइटबाट सुरु गर्दै
पहिलो चलाउँदा URL टाँस्नुहोस्। ClickSomo ले पृष्ठबाट यसको लोगो, आइकनहरू, म्यानिफेस्ट र यसका नापिएका रङहरू — कसैले अनुमान गरेका रङ होइनन् — पढ्छ र तपाईंकै जस्तो देखिने पहिलो इमेल बनाउँछ। यसले प्लेटफर्म पनि पहिचान गर्छ, जुन प्रायः उपयोगी फनल सुझाव गर्न पर्याप्त हुन्छ: पसलले परित्यागित बास्केट पाउँछ, प्रकाशकले न्यूजलेटर स्वागत पाउँछ।
तपाईंले दिनुभएको URL को हरेक फेच सुरक्षित फेचरबाट जान्छ: HTTP र HTTPS मात्र, साक्षात् ठेगानाहरू सिधै जाँच गरिन्छ, हरेक DNS उत्तर सार्वजनिक हुनुपर्छ, र हरेक रिडाइरेक्ट चरण पुनः प्रमाणित गरिन्छ। ग्राहकका तर्फबाट स्वेच्छाचारी URL फेच गर्नु आफ्नै नेटवर्कमा प्वाल बनाउने सबैभन्दा सजिलो तरिकामध्ये एक हो, र यो दुई पटक लेख्ने कुरा होइन।
इमानदार कुरा: तपाईंको वेबसाइटबाट बनेको पहिलो टेम्प्लेट राम्रो सुरुवात हो, तयार डिजाइन होइन। यसले लोगो, रङ र अक्षरशैली लगभग ठीक गर्छ ताकि तपाईंको पहिलो पठाइ डेमो जस्तो नदेखियोस् — र त्यसपछि तपाईंले यसलाई सम्पादन गर्नुहुन्छ, जुन खाली क्यानभास हेरेर बस्नुभन्दा धेरै राम्रो काम हो।