ट्रांजैक्शनल ईमेल चेकलिस्ट: लॉन्च से पहले क्या जांचें

ट्रांजैक्शनल ईमेल चेकलिस्ट वह अनुशासन है जिसमें आप उस मेल की जांच करते हैं जो आपका प्रोडक्ट अपनी ओर से भेजता है, इससे पहले कि असली लोग उसे पढ़ें। साइनअप की पुष्टि, पासवर्ड रीसेट, ऑर्डर की सूचना, कोई बिल: हर एक किसी घटना से चलता है, डेटा से भरता है, और ठीक एक बार पहुंचने की उम्मीद रखता है। नाकामी के रूप उबाऊ भी हैं और महंगे भी — ऐसा ट्रिगर जो कभी चलता ही नहीं, ऐसा टेम्पलेट जो ख़ाली नाम दिखाता है, ऐसा लिंक जो ग़लत एनवायरनमेंट की ओर जाता है, ऐसी दोबारा कोशिश जो तीन एक जैसी रसीदें बना देती है।

ट्रांजैक्शनल मेल में क्या गिना जाता है

ट्रांजैक्शनल मेल इसलिए भेजी जाती है क्योंकि कुछ हुआ, और उसे किसी ऐसे व्यक्ति को भेजा जाता है जो उस घटना का पक्षकार है। यह कोई समाचार-पत्र नहीं है और कोई प्रचार नहीं है, और यह फ़र्क़ किताबी नहीं है: यह तय करता है कि कौन सी सामग्री ठीक बैठती है, पाने वाला क्या उम्मीद करता है, और एक क्लिक में अनसब्सक्राइब का मतलब हर मामले में क्या होता है।

व्यवहार में यह हद धुंधली पड़ जाती है, और धुंधलापन ही वह जगह है जहां मुसीबत शुरू होती है। पासवर्ड रीसेट के भीतर प्रचार का टुकड़ा ठूंस देना लोगों को चिढ़ाने का पुराना तरीक़ा है। ऑर्डर की पुष्टि को मार्केटिंग की पाइपलाइन से भेजने का मतलब है कि कोई दबाव सूची या अनसब्सक्राइब की पसंद चुपचाप ऐसा संदेश रोक सकती है जो पाने वाले को सचमुच चाहिए था।

तय कीजिए कि कौन सा संदेश किस पाइपलाइन का है, और यह फ़ैसला कॉन्फ़िगरेशन में दिखने वाला रखिए, किसी की याददाश्त में नहीं।

लॉन्च से पहले ट्रिगर की सूची जांचना

शुरुआत टेम्पलेट से नहीं, घटनाओं से कीजिए। हर उस घटना के लिए जिससे मेल निकलनी चाहिए, यह पक्का कीजिए कि संदेश सचमुच बनता है, सही पते पर जाता है, और उस घटना का मानकर पहचाना जा सकता है।

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

हर पंक्ति के लिए सवाल वही हैं: यह एक बार चलती है क्या, सही पाने वाला रखती है क्या, और दोबारा कोशिश झेल जाती है क्या? जो सूची घटना का नाम लेती है, वह टेम्पलेट का नाम लेने वाली से ज़्यादा काम की है, क्योंकि ग़ायब असल में घटनाएं ही होती हैं।

क्या वेरिएबल हमेशा रेंडर होते हैं?

रेंडरिंग वह जगह है जहां अच्छी तरह जांचा हुआ प्रोडक्ट भी दिखने वाली ख़ामियां लेकर निकलता है, क्योंकि जो टेम्पलेट पूरे डेटा के साथ ठीक दिखता है, वह अधूरे डेटा के साथ बहुत अलग दिख सकता है।

आज़माने लायक मामले ख़ाली वाले हैं। ऐसा उपयोगकर्ता जिसका नाम एक ही शब्द का हो, ऐसा जिसका कोई दिखने वाला नाम ही न हो, ऐसा ऑर्डर जिसमें एक ही मद हो और ऐसा जिसमें कोई न हो, और ऐसा मान जो ग़ायब नहीं बल्कि ख़ाली पाठ हो। इनमें से हर मामला ऐसा कुछ बनाना चाहिए जिसे कोई पढ़ सके, और इनमें से कोई भी कच्चा प्लेसहोल्डर पाठ नहीं दिखाना चाहिए और न वहां ख़ाली जगह छोड़नी चाहिए जहां वाक्य को कोई संज्ञा चाहिए थी।

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

एक ही घटना दो बार आने पर क्या होता है?

मान लीजिए भुगतान की सेवा आपके वेबहुक को दो बार पुकारती है, या कोई क़तार इसलिए दोबारा सौंपती है कि पावती खो गई। उपयोगकर्ता को एक ऑर्डर के लिए दो रसीदें नहीं मिलनी चाहिए।

यह मेल सर्वर का नहीं, भेजने वाली तरफ़ का गुण है, और इसे सीधे जांचना चाहिए: वही घटना दो बार सौंपिए और एसर्शन कीजिए कि एक ही संदेश बना। आम तरीक़ा यह है कि घटना के साथ आया कोई पहचान-चिह्न दर्ज कर लिया जाए जब संदेश स्वीकार हो, जिससे दूसरी बार का सौंपना दोहराव मानकर पहचाना जा सके। तरीक़ा जो भी हो, टेस्ट को उसे मान लेना नहीं, चलाकर देखना चाहिए, क्योंकि बंटे हुए सिस्टमों में दोहराई घटनाएं सामान्य हैं और मेल के पास भेजे गए संदेश को वापस लेने का कोई ज़रिया नहीं होता।

भेजने वाली पहचान इनबॉक्स के लिए क्यों मायने रखती है?

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

इसे तैयार करना उसका काम है जिसके पास डोमेन हो, और ब्यौरा इस पर निर्भर है कि मेल सेवा कौन सी है। जो चेकलिस्ट कर सकती है वह यह पक्का करना है कि व्यवस्था उस एनवायरनमेंट में सचमुच पूरी हुई है जिसे आप लॉन्च कर रहे हैं, सिर्फ़ उसी में नहीं जिसमें आपने टेस्ट किया।

भाषा, तारीख़ के प्रारूप और देश के फ़र्क़

जो प्रोडक्ट एक से ज़्यादा बाज़ारों की सेवा करता है, वह दो आसान ग़लतियां विरासत में पाता है। पहली पाठ की है: ऐसा संदेश जिसकी बॉडी तो स्थानीय भाषा में है पर विषय पंक्ति और पाद-लेख मूल भाषा में ही छूट गए। दूसरी प्रारूप की है: ऐसी तारीख़ जो एक बाज़ार में बिना उलझन के पढ़ी जाती है और दूसरे में गड़बड़ कर देती है, या ऐसी संख्या जिसमें दशमलव का चिह्न पाने वाले की अपेक्षा से अलग है।

साफ़ जांच यह है कि हर संदेश को उन सभी भाषाओं में चलाया जाए जिनमें प्रोडक्ट मेल भेजता है, और पूरा संदेश पढ़ा जाए, विषय पंक्ति समेत, ठीक वैसे जैसे पाने वाला पढ़ेगा। अगर सामग्री किसी ख़ास क्षेत्राधिकार के ब्यौरे की ओर इशारा करती है — पहचान का प्रारूप, कर का लेबल, डाक पते की परिपाटी — तो उस बाज़ार के पेज काम की निर्देशिका हैं, जैसे जर्मनी या जापान के।

इस पूरी जांच में जो भी भेजा जाए, वह उन पतों पर जाना चाहिए जो इसी मक़सद से बनाए गए हों। यहां जो कुछ बताया गया है वह कोई असली पहचान या किसी जीवित ग्राहक का संपर्क नहीं है, और कोई टेम्पलेट किसी असली व्यक्ति के पते के साथ बाहर नहीं जाना चाहिए।

डेवलपर्स के लिए: इडेम्पोटेंसी, नाकामी की पकड़ और लॉग

चार गुण सूट में ख़ास तौर पर कवर होने लायक हैं।

पहले इडेम्पोटेंसी: एक घटना, एक संदेश, चाहे वह घटना कितनी भी बार सौंपी जाए। इसे दो बार सौंपकर ही साबित कीजिए।

दूसरे नाकामी की पकड़: तय कीजिए कि जब मेल सेवा मना कर दे या समय बीत जाए तो क्या होगा। फेल हुआ भेजना दर्ज होना चाहिए, तय समय पर फिर कोशिश होनी चाहिए, और दिखना चाहिए — निगला नहीं जाना चाहिए। चुपचाप फेल होने का मतलब है कि समस्या का पता ग्राहक से चलना।

तीसरे टेम्पलेट के विकल्प: तय कीजिए कि हर वेरिएबल के न होने पर वह क्या दिखाता है, और उस ग़ायब वाले मामले को भी टेस्ट में रखिए। यही ख़ामी की वह श्रेणी है जो सबसे ज़्यादा बार प्रोडक्शन तक पहुंचती है, क्योंकि पूरा टेस्ट डेटा उसे छिपा देता है।

चौथे लॉग: इतना रखिए कि ग़ायब मेल की पड़ताल हो सके, और इतना नहीं कि लॉग ख़ुद एक डेटा ज़िम्मेदारी बन जाए। घटना का पहचान-चिह्न, टेम्पलेट का वर्शन और नतीजा दर्ज कीजिए। संदेश की बॉडी दर्ज न कीजिए, और कोई रीसेट लिंक दर्ज न कीजिए, क्योंकि जिस लॉग पंक्ति में चलता हुआ लिंक हो, वह लंबी उम्र वाला पासवर्ड जैसा सबूत है।

उस मेल के लिए जो आपके टेस्ट ख़ुद बनाते हैं, रन के लिए बनाया गया पता एसर्शन संकरे रखता है और दूसरों के इनबॉक्स को पूरे मामले से बाहर रखता है; टेम्प मेल टूल दो सेकंड में एक बना देता है, और अस्थायी मेल कैसे काम करता है बताता है कि उसके बाद संदेशों का क्या होता है।

अगले क़दम

ऊपर की ट्रिगर सूची लीजिए और हर पंक्ति के सामने वह एनवायरनमेंट लिखिए जहां आपने उसे आख़िरी बार चलते देखा, और वह व्यक्ति जिसने आख़िरी बार संदेश पढ़ा। जो पंक्ति बिना निशान की रह जाए, वह लॉन्च का जोखिम है। फिर अपने हर संदेश को टेम्प मेल पेज से टेस्ट के लिए बनाए गए पते पर भेजिए और उसे वैसे पढ़िए जैसे पाने वाला पढ़ेगा — विषय पंक्ति पर भी, बॉडी में भी।