एक रसीद खरीदारी की पुष्टि करती है। एक ऑफ़र दूसरी खरीदारी का न्योता देता है। दोनों चेकआउट के बाद स्वचालित रूप से आ सकते हैं, लेकिन इनके उद्देश्य अलग-अलग हैं।
इस अंतर से तय होता है कि कौन-से ऑप्ट-आउट लागू होते हैं। इससे यह भी तय होता है कि कौन-से संदेश एक साझा भेजने की प्रतिष्ठा साझा करते हैं। संदेश का प्रकार तय करता है कि उसे अनसब्सक्राइब तंत्र की ज़रूरत है या नहीं।
किसी email को transactional या marketing क्या बनाता है?
संदेश का उद्देश्य उसकी श्रेणी तय करता है। ऑटोमेशन, पर्सनलाइज़ेशन और प्राप्तकर्ताओं की संख्या से वह उद्देश्य निर्धारित नहीं होता।
Google के subscription दिशानिर्देश पासवर्ड रीसेट, खरीदारी रसीदों और वन-टाइम पासवर्ड को subscription संदेशों से अलग करते हैं। Marketing सूचियाँ और न्यूज़लेटर subscription श्रेणी में आते हैं।
| प्रश्न | Transactional email | Marketing email |
|---|---|---|
| यह क्यों भेजा जाता है? | किसी लेन-देन, अनुरोध या अकाउंट इवेंट को पूरा करने या रिपोर्ट करने के लिए | किसी चीज़ का प्रचार करने या सब्सक्राइब की गई सामग्री भेजने के लिए |
| इसे कौन शुरू करता है? | कोई खरीदारी, रीसेट अनुरोध या संबंधित अकाउंट इवेंट | कोई कैम्पेन शेड्यूल या स्वचालित प्रचार ट्रिगर |
| प्राप्तकर्ता क्या उम्मीद करता है? | उस लेन-देन या अकाउंट के लिए ज़रूरी जानकारी | वह सामग्री जिसे प्राप्त करने के लिए उन्होंने subscription के रूप में सहमति दी है |
| उदाहरण | रसीद, रीसेट लिंक, सुरक्षा अलर्ट | न्यूज़लेटर, प्रोडक्ट ऑफ़र, प्रचार फ़ॉलो-अप |
ग्राहक का रसीद माँगना और न्यूज़लेटर प्राप्त करने की अनुमति देना अलग-अलग बातें हैं। Google subscription भेजने वालों से कहता है कि भेजने से पहले प्राप्तकर्ता के email पते की पुष्टि करें।
सहमति की आवश्यकताएँ लागू कानून पर भी निर्भर करती हैं। CAN-SPAM एक ऑप्ट-आउट ढाँचे के ज़रिए US commercial email को नियंत्रित करता है।
अलग-अलग भेजने के पते, डोमेन और IP पूल क्यों इस्तेमाल करें?
अलगाव ट्रैफ़िक को पहचानने योग्य बनाए रखता है और साझा प्रतिष्ठा के जोखिम को कम करता है। Yahoo का sender दिशानिर्देश IP पतों और DKIM signing डोमेन दोनों को प्रतिष्ठा संकेत के रूप में पहचानता है।
Google subscription और non-subscription संदेशों के लिए अलग-अलग भेजने के पतों की सिफ़ारिश करता है। Yahoo बल्क marketing मेल को transactional मेल से IP या DKIM डोमेन द्वारा अलग करने की सिफ़ारिश करता है।
उदाहरण के लिए, रसीदें एक प्रमाणित receipts.example.com सबडोमेन का उपयोग कर सकती हैं और ऑफ़र news.example.com का उपयोग कर सकते हैं। प्रत्येक स्ट्रीम अपने स्वयं के IP पूल का भी उपयोग कर सकती है, जो भेजने वाले IP पतों का एक समूह है।
ये नियंत्रण अलग-अलग हैं। एक भिन्न From पता फिर भी उसी signing डोमेन और भेजने वाले IP का उपयोग कर सकता है।
स्ट्रीम मिला दिए जाएँ तो क्या होता है?
अनचाही marketing ऑपरेशनल मेल द्वारा उपयोग की जाने वाली प्रतिष्ठा को प्रभावित कर सकती है। Yahoo का FAQ transactional संदेशों के साथ IP साझा करने वाले अवांछित commercial मेल के बारे में चेतावनी देता है।
एक कैम्पेन और एक पासवर्ड रीसेट उन IP का उपयोग करते हुए वही जोखिम साझा करते हैं।
एक ही संदेश के अंदर उद्देश्यों को मिलाने से एक और समस्या पैदा होती है। रसीद में प्रचार ऑफ़र डालने से CAN-SPAM के तहत संदेश का वर्गीकरण बदल सकता है।
Gmail और Yahoo की आवश्यकताएँ संदेश प्रकार के अनुसार कैसे भिन्न हैं?
Transactional संदेशों को भी प्रमाणीकरण और अनुपालन-योग्य भेजने के ढाँचे की ज़रूरत होती है। अनसब्सक्राइब का भेद उन्हें प्रदाताओं की अन्य sender आवश्यकताओं से छूट नहीं देता।
Gmail की sender आवश्यकताएँ व्यक्तिगत Gmail अकाउंट पर सभी भेजने वालों के लिए SPF या DKIM की आवश्यकता रखती हैं। प्रतिदिन व्यक्तिगत Gmail अकाउंट पर 5,000 से अधिक संदेश भेजने वालों को SPF, DKIM और DMARC की ज़रूरत होती है। उनके marketing और subscribed संदेशों को one-click unsubscribe और बॉडी में एक दृश्य लिंक भी चाहिए।
Google के subscription दिशानिर्देश भेजने वालों से 48 घंटों के भीतर अनसब्सक्राइब अनुरोधों का सम्मान करने को कहते हैं। इसलिए प्राथमिकता में बदलाव को उस अवधि के भीतर बाद के subscription भेजना बंद करने की ज़रूरत है।
Yahoo की आवश्यकताएँ भी बल्क भेजने वालों के लिए SPF, DKIM और DMARC की आवश्यकता रखती हैं। इसकी one-click unsubscribe आवश्यकता प्रचार और marketing संदेशों पर लागू होती है। इसका FAQ transactional उदाहरणों जैसे ऑर्डर पुष्टि और पासवर्ड रीसेट को स्पष्ट रूप से बाहर रखता है।
CAN-SPAM दोनों श्रेणियों के साथ कैसा व्यवहार करता है?
CAN-SPAM संदेश के प्राथमिक उद्देश्य के अनुसार अलग-अलग दायित्व लागू करता है। FTC, US उपभोक्ता संरक्षण नियामक, transactional या relationship सामग्री को संकीर्ण रूप से परिभाषित करता है।
Commercial संदेशों को सत्यनिष्ठ sender जानकारी, सटीक विषय पंक्तियाँ, विज्ञापन पहचान, डाक पता और ऑप्ट-आउट तंत्र की ज़रूरत होती है। पूर्णतः transactional या relationship संदेश गलत या भ्रामक रूटिंग जानकारी पर प्रतिबंध के अधीन रहते हैं।
किसी मौजूदा ग्राहक संबंध से हर संदेश transactional नहीं बन जाता। मिश्रित सामग्री के लिए, एक प्रचार विषय पंक्ति संदेश को commercial बना सकती है। transactional सामग्री को मुख्य रूप से प्रचार के बाद रखने से भी ऐसा हो सकता है।
इसलिए एक प्रचार email transactional भेजने का पता या API श्रेणी इस्तेमाल करके इन दायित्वों से बच नहीं सकता।
आप Bird में दोनों को कैसे अलग करते हैं?
आप संदेश की श्रेणी उसकी सामग्री के अनुसार transactional या marketing सेट करते हैं। इनलाइन भेजने पर डिफ़ॉल्ट marketing होता है। स्टोर-टेम्पलेट भेजने पर टेम्पलेट की श्रेणी विरासत में मिलती है, जब तक आप इसे ओवरराइड नहीं करते।
Bird marketing भेजने में one-click unsubscribe हेडर और HTML-बॉडी लिंक जोड़ता है। केवल-marketing ऑप्ट-आउट marketing मेल को रोकता है जबकि transactional मेल की अनुमति देता है। हार्ड बाउंस, मैन्युअल दमन और सभी संदेशों को कवर करने वाला ऑप्ट-आउट दोनों श्रेणियों को रोकता है।
आप इंफ़्रास्ट्रक्चर अलग से चुनते हैं। सत्यापित भेजने के सबडोमेन का उपयोग करें और ip_pool_id से भेजने का पूल चुनें। वह फ़ील्ड छोड़ देने पर आपके संगठन का डिफ़ॉल्ट पूल उपयोग होता है। category सेट करने से कोई अलग पूल नहीं चुना जाता।
Transactional email API उस सेटअप को आपके एप्लिकेशन से जोड़ता है। Transactional email सेवा चेकलिस्ट प्रदाता मूल्यांकन को कवर करती है।