डिलिवरेबिलिटी ऑडिट के लिए ईमेल शिकायत दर की गणना

जब आपको शिकायत दर की आवश्यकता हो, न कि शिकायत संख्या

एक शिकायत संख्या आपको बताती है कि कितने लोगों ने “स्पैम रिपोर्ट करें” पर क्लिक किया। शिकायत दर आपको बताती है कि यह संख्या मात्रा के खिलाफ कैसे व्यवहार करती है। ये दोनों एक समान नहीं हैं।

यदि एक अभियान 10,000 संदेश भेजता है और 20 शिकायतें प्राप्त करता है, जबकि दूसरा 500 भेजता है और 6 प्राप्त करता है, तो कच्ची शिकायत संख्या पहले अभियान को खराब दिखाती है। दर तस्वीर को बदल देती है। यही कारण है कि ईमेल शिकायत दर की गणना डिलीवरबिलिटी ऑडिट में महत्वपूर्ण है, विशेष रूप से जब आपको अभियानों, सूचियों, या महीनों की तुलना करनी हो जिनका भेजने का आकार बहुत अलग हो।

जब प्रश्न तुलनात्मक हो तो शिकायत दर का उपयोग करें। एक साप्ताहिक रिपोर्ट, एक सूची की सफाई की समीक्षा, या एक विक्रेता जांच सभी को एक सामान्यीकृत संख्या की आवश्यकता होती है। समर्थन त्रिकोण के लिए एक साधारण कुल ठीक है, लेकिन यह यह निर्णय लेने के लिए पर्याप्त नहीं है कि क्या एक दर्शक खंड दूसरे से बेहतर व्यवहार कर रहा है।

एक चेतावनी: एक कम शिकायत संख्या अभी भी समस्या को छिपा सकती है। 200 पर दो शिकायतें 20,000 पर दो शिकायतों से बहुत अलग संकेत हैं। पहले वाले को एक विराम की आवश्यकता हो सकती है।

शिकायत संख्या “कितनी” का उत्तर देती है। दर “कितनी, मात्रा के सापेक्ष” का उत्तर देती है।

सटीक माप विंडो सेट करें

गणना का केवल तभी अर्थ है जब समय विंडो स्पष्ट हो। एक भेजें, एक अभियान दिन, एक बिलिंग अवधि, या एक रिपोर्टिंग अंतराल चुनें। फिर परिणामों की तुलना करते समय उस विकल्प को स्थिर रखें।

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

अभियान-दिन की रिपोर्टिंग अलग होती है। यदि एक अभियान 9:00 और 15:00 पर दो लहरों में शुरू होता है, तो आपको यह बताना होगा कि क्या विंडो पूरे दिन को कवर करती है या केवल प्रत्येक लहर को। अन्यथा, एक टीम के चार्ट में समान शिकायतों को दो बार और दूसरी में एक बार गिना जा सकता है।

लंबी रिपोर्टिंग अंतराल प्रवृत्ति कार्य के लिए उपयोगी हो सकते हैं। 7-दिन या 30-दिन की विंडो शोर को समतल करती है, लेकिन यह एक खराब भेजने में हुई एक स्पाइक को भी छिपा सकती है। यदि ऑडिट एक घटना के बारे में है, तो विंडो को छोटा रखें। यदि ऑडिट भेजने के पोर्टफोलियो के बारे में है, तो एक लंबी विंडो मदद कर सकती है।

विंडो को लिखें। गंभीरता से। एक “मार्च रिपोर्ट” बहुत ढीली है।

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

गणक चुनें: वितरित, भेजा गया, या बाउंस घटाकर वितरित

गणक दर को बदलता है। यह कोई छोटी बात नहीं है। यह संख्या के अर्थ को बदलता है।

भेजे गए मात्रा का उपयोग करना सरल है: शिकायतें सभी प्रयास किए गए संदेशों से विभाजित। वितरित मात्रा का उपयोग बाउंस को आधार से हटा देता है, इसलिए केवल वे संदेश जो इनबॉक्स या प्राप्त करने वाले सर्वरों तक पहुंचे हैं, गिने जाते हैं।

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

एक व्यावहारिक नियम मदद करता है: यदि आप डिलीवरी के बाद की शिकायत व्यवहार की तुलना कर रहे हैं, तो 'डिलीवर' का उपयोग करें। यदि आप एक भेजने वाले सिस्टम में परिचालन मात्रा की तुलना कर रहे हैं, तो 'सेंट' का उपयोग करें। फिर चार्ट शीर्षक में मीट्रिक को हरितांक के साथ लेबल करें, केवल फुटनोट में नहीं।

ऑडिट के लिए, स्थिरता सुंदरता से अधिक महत्वपूर्ण है। एक टीम थोड़ी अजीब परिभाषा के साथ रह सकती है। यह एक संख्या के साथ नहीं रह सकती जो एक रिपोर्ट से दूसरी रिपोर्ट में अर्थ बदलती है।

यहां एक वाक्य पर्याप्त है: एक बार चुनें।

स्प्रेडशीट या डैशबोर्ड में फॉर्मूला लागू करें

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

उदाहरण के लिए, यदि शिकायतें सेल B2 में हैं और डिलीवर की गई मात्रा C2 में है, तो फॉर्मूला =B2/C2 है। यदि आपकी टीम प्रतिशत आउटपुट चाहती है, तो डिस्प्ले लेयर में 100 से गुणा करें, डेटा लेयर में नहीं। इससे कच्चा नंबर बाद की जांच के लिए उपलब्ध रहता है।

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

खाली सेल और टेक्स्ट मानों पर ध्यान दें। एक खाली हरितांक चुपचाप शून्य नहीं होना चाहिए। एक स्प्रेडशीट जो “#DIV/0!” लौटाती है, परेशान करने वाली है, लेकिन यह एक गलत शून्य से बेहतर है।

यदि आपका डेटा एक BI टूल से आता है, तो गणना को एक बार बनाएं और पुन: उपयोग करें। प्रत्येक रिपोर्ट में फॉर्मूला फिर से दर्ज करना टीमों को एक ही मीट्रिक के चार संस्करणों के साथ समाप्त करता है। यह जल्दी गंदा हो जाता है।

यहां एक साफ कार्यप्रवाह है:

• शिकायत कुल लोड करें।
• चुने हुए ईमेल मात्रा को लोड करें।
• दोनों की पुष्टि करें कि वे एक ही विंडो को कवर करते हैं।
• शिकायत कुल को ईमेल मात्रा से विभाजित करें।
• रिपोर्ट में फॉर्मूला नाम को स्टोर करें।

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

कई अभियानों में शिकायत दर को सामान्य करें

एकल अभियान सरल है। तीन अभियानों के साथ विभिन्न भेजने के आकार सरल नहीं हैं। सवाल यह बनता है कि दरों का औसत लेना है या पहले कुल को एकत्र करना है।

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

औसत क्यों भ्रामक है? क्योंकि 100 संदेशों पर 2% की दर और 10,000 संदेशों पर 0.2% की दर को समान रूप से नहीं गिनना चाहिए। बड़े भेजने का अधिक वजन होता है। साधारण औसत उन्हें जुड़वां के रूप में मानता है, जो वे नहीं हैं।

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

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

एक त्वरित aside: औसत आकर्षक होते हैं और अक्सर गलत होते हैं।

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

परिणाम को विकृत करने वाले किनारे के मामलों को संभालें

टिनी जल्दी दरों को विकृत करता है। 50 ईमेल पर एक शिकायत 2% है, और यह नाटकीय लगता है क्योंकि यह है। 50,000 ईमेल पर वही एक शिकायत संख्या को मुश्किल से हिलाती है। दोनों वास्तविक हैं। वे बस अलग-अलग चीजें दर्शाते हैं।

शून्य शिकायतों को भी देखभाल की आवश्यकता होती है। एक शून्य दर का मतलब उत्कृष्ट लक्ष्यीकरण हो सकता है, या इसका मतलब हो सकता है कि शिकायत चैनल को सही तरीके से कैप्चर नहीं किया गया था। यदि आपके पास कोई शिकायत रिकॉर्ड नहीं है लेकिन अभियान में कई अनसब्सक्राइब या समर्थन उत्तर थे, तो जश्न मनाने के लिए जल्दी न करें।

आंशिक रूप से वितरित मेल एक और जाल है। यदि 8,000 भेजे गए थे और केवल 7,200 वितरित किए गए, तो हर हाल में परिभाषा के अनुसार हर हाल में मेल खाना चाहिए। एक ही ऑडिट में भेजे गए और वितरित किए गए को मिलाना परिणाम को बिना किसी को नोटिस किए भटकाता है।

दर्शक मिश्रण भी दर को विकृत कर सकता है। एक संलग्न ग्राहकों की सूची और ठंडे संभावनाओं की सूची को तब तक नहीं मिलाना चाहिए जब तक कि रिपोर्ट ऐसा न कहे। खंड-स्तरीय भिन्नताएँ अक्सर पूरी कहानी होती हैं। यदि एक क्षेत्र, उत्पाद लाइन, या जीवनचक्र चरण ने शिकायतों को प्रेरित किया, तो समग्र संख्या स्रोत को छुपा देती है।

डुप्लिकेट शिकायतें महत्वपूर्ण होती हैं। कुछ सिस्टम एक ही शिकायत घटना को दो बार रिकॉर्ड करते हैं, विशेष रूप से जब लॉग एक से अधिक स्रोतों से मिलाए जाते हैं। यदि टीम कच्चे घटना डेटा को आयात करती है, तो अंतिम गणना पर भरोसा करने से पहले दोहराए गए संदेश आईडी की जांच करें।

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

संबंधित स्वच्छता कार्य के लिए, शिकायत प्रबंधन और दमन नियमों के चौराहे पर ईमेल दमन सूची प्रबंधन · YourTrend पर मार्गदर्शिका पढ़ने लायक है। दमन फॉलो-अप के बिना एक शिकायत दर केवल आधी कहानी है।

आंतरिक रिपोर्टिंग के लिए परिणाम को लेबल करें

एक अच्छी रिपोर्ट ठीक यही कहती है कि संख्या क्या है। लगभग नहीं। बिल्कुल।

परिणाम को तीन भागों के साथ लेबल करें: सूत्र, विंडो, और हर हाल में। उदाहरण के लिए: “शिकायत दर = शिकायतें / वितरित ईमेल, 2026-03-01 अभियान विंडो के लिए मापी गई।” वह एक पंक्ति पाठक को सुरक्षित रूप से तुलना करने के लिए पर्याप्त बताती है।

यदि आपने कुछ भेजने को बाहर रखा है, तो ऐसा कहें। अपवादों में आंतरिक परीक्षण मेल, बीज सूचियाँ, या ऑडिट दायरे के बाहर के क्षेत्र शामिल हो सकते हैं। बिना नोट के उन्हें छोड़ने से संख्या अधिक साफ दिखती है।

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

आंतरिक रिपोर्टिंग को चार्ट के नीचे एक परिभाषा पंक्ति से भी लाभ होता है। इसे संक्षिप्त रखें। यदि इसमें हर और अवधि शामिल है तो एक वाक्य पर्याप्त है। लंबे नोट्स पहले सप्ताह के बाद अनदेखे हो जाते हैं।

यदि डिलीवरबिलिटी भाषा प्रमाणीकरण कार्य के साथ है, तो लेन-देन के लिए DKIM SPF DMARC सेटअप पर लेख उसी ऑडिट पैक के लिए उपयोगी संदर्भ प्रदान कर सकता है। शिकायत दर और प्रमाणीकरण अलग-अलग जांच हैं, लेकिन वे अक्सर एक समीक्षा में एक साथ चलते हैं।

शेयर करने से पहले लेबल लगाना एक सरल अनुशासन है। बिना लेबल के एक संख्या एक गलत व्याख्या को आमंत्रित करती है जो एक हर या एक दिन से गलत हो सकती है।

शेयर करने से पहले संख्या की sanity-check करें

रिपोर्ट भेजने से पहले, कुल की जांच करें। शिकायत की संख्या घटना लॉग या प्लेटफ़ॉर्म निर्यात से मेल खानी चाहिए। हर वही खिड़की से मेल खानी चाहिए। यदि ये दो फ़ील्ड असहमत हैं, तो दर तैयार नहीं है।

गुम पंक्तियों की तलाश करें। यदि एक अभियान अंश में दिखाई देता है लेकिन हर में नहीं, तो परिणाम बढ़ा हुआ होगा। यदि हर में एक ऐसा अभियान शामिल है जिसे शिकायत फ़ीड से बाहर रखा गया था, तो परिणाम उतना सुरक्षित दिखेगा जितना कि यह है।

अगले चरण में डुप्लिकेट की जांच करें। एक शिकायत घटना का दो बार दिखाई देना एक छोटे भेजने को विकृत करने के लिए पर्याप्त है। एक अच्छा ऑडिट संदेश आईडी, समय मुहर, और अभियान नामों को शामिल करता है, भले ही अंतिम रिपोर्ट केवल एक संख्या दिखाए।

फिर गणित का परीक्षण करें। एक पंक्ति को हाथ से फिर से गणना करें। इसमें 30 सेकंड लगते हैं और कई त्रुटियों को पकड़ लेते हैं। यहाँ एक असंगति आमतौर पर एक खराब फ़िल्टर या एक आकस्मिक विलय की ओर इशारा करती है।

विशेष रूप से हर में असंगतियों पर ध्यान दें। शिकायत-प्रति-भेजे गए मीट्रिक और शिकायत-प्रति-डिलीवर किए गए मीट्रिक एक साथ बैठ सकते हैं और स्वर में समान दिख सकते हैं जबकि अर्थ में भिन्न हो सकते हैं। यही कारण है कि अच्छे दिखने वाले चार्ट के साथ खराब निर्णय लिए जाते हैं।

यदि आपको व्यापक मेल पाइपलाइन की जांच करने की आवश्यकता है, तो ईमेल डिलीवरबिलिटी सर्वश्रेष्ठ प्रथाएँ इस एक मीट्रिक के परे ऑडिट को फ्रेम करने में मदद कर सकती हैं। शिकायत दर एक संकेत है, पूरा सिस्टम नहीं।

एक अंतिम जांच: सुनिश्चित करें कि फ़ाइल का नाम, चार्ट का शीर्षक, और शरीर का पाठ सभी एक ही हर में हैं। यदि स्लाइड में कहा गया है कि भेजा गया है और नोट्स में कहा गया है कि भेजा गया है, तो इसे ठीक करें इससे पहले कि कोई भी PDF को अग्रेषित करे।