विकास के लिए ट्रैक करने के लिए SaaS डैशबोर्ड मैट्रिक्स

डैशबोर्ड में ट्रैक करने के लिए कौन से SaaS मेट्रिक्स: उत्पाद और राजस्व का विश्लेषण करने के लिए एक बुनियादी सेट

1. एक SaaS डैशबोर्ड क्या दिखाता है और यह क्यों महत्वपूर्ण है

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

एक SaaS टीम के लिए, यह डैशबोर्ड लगभग एक नियंत्रण पैनल की तरह है। यह दिखाता है कि उत्पाद वास्तविक समय में कैसे प्रदर्शन कर रहा है: क्या पंजीकरण बढ़ रहे हैं, क्या सक्रियता में गिरावट आई है, क्या भुगतान चक्र में बदलाव आया है, या क्या रद्दीकरण बढ़ रहे हैं। यदि डैशबोर्ड खराब तरीके से बनाया गया है, तो आप “नए उपयोगकर्ताओं” के बारे में लंबे समय तक अच्छा महसूस कर सकते हैं, भले ही उनमें से आधे कभी पहले महत्वपूर्ण क्रिया तक नहीं पहुंचे।

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

एक महत्वपूर्ण सिद्धांत: डैशबोर्ड सुंदर चार्ट के लिए नहीं है। यह इस लिए मौजूद है ताकि आप 10 मिनट में तीन सवालों का जवाब दे सकें — क्या उत्पाद जीवित है, क्या पैसा आ रहा है, और क्या उपयोगकर्ता बने हुए हैं? बाकी सब कुछ दूसरे स्थान पर आता है।

2. उपयोगकर्ता गतिविधि: पंजीकरण, लॉगिन, फ़ीचर उपयोग

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

पंजीकरण अकेले कुछ भी साबित नहीं करता। यदि एक सप्ताह में 300 लोग पंजीकृत हुए लेकिन केवल 60 ने उत्पाद में प्रवेश किया, तो कहीं न कहीं एक रिसाव हो गया है। कभी-कभी कारण सरल होता है: ईमेल कभी नहीं आया। कभी-कभी यह अधिक जटिल होता है: उपयोगकर्ता यह नहीं समझा कि उन्हें इस SaaS की आवश्यकता क्यों है। इसलिए आपको केवल पंजीकरण की संख्या पर नहीं, बल्कि उन उपयोगकर्ताओं के हिस्से पर भी ध्यान देना चाहिए जिन्होंने पहली महत्वपूर्ण क्रिया पूरी की।

यहाँ सवाल उठता है: यदि आप गतिविधि को विशेष रूप से समझना चाहते हैं, न कि अस्पष्ट रुचि, तो आपको कौन से SaaS डैशबोर्ड मैट्रिक्स को ट्रैक करना चाहिए? संक्षिप्त उत्तर: 1, 7, और 30 दिनों में सक्रिय उपयोगकर्ता, लॉगिन आवृत्ति, उपयोग की गहराई, और प्रमुख कार्यप्रवाहों के लॉन्च। एक B2B सेवा के लिए, यह पहले प्रोजेक्ट को बनाना, एक फ़ाइल अपलोड करना, एक टीम के साथी को आमंत्रित करना, या एक रिपोर्ट चलाना हो सकता है। किसी अन्य उत्पाद के लिए, सक्रियण बिंदु अलग होगा। कोई सार्वभौमिक बटन नहीं है।

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

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

3. पंजीकरण से भुगतान तक का फ़नल

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

पहले, देखें कि कितने लोग पंजीकरण से अपने पहले महत्वपूर्ण कार्य की ओर बढ़ते हैं। फिर देखें कि उनमें से कितने परीक्षण शुरू करते हैं। इसके बाद, जांचें कि परीक्षण समाप्त होने पर कितने भुगतान करते हैं। यदि एक परीक्षण है लेकिन केवल एक छोटी संख्या इसे पूरा करती है, तो समस्या बिक्री नहीं है - यह पहला अनुभव है। उपयोगकर्ता ने 1-2 मिनट के भीतर मूल्य नहीं देखा। कभी-कभी उन्हें बस एक स्पष्ट संकेत की आवश्यकता होती है।

बॉटलनेक्स अक्सर अप्रत्याशित स्थानों में छिपे होते हैं। उदाहरण के लिए, भुगतान फॉर्म खुलता है, लेकिन लोग कार्ड विवरण दर्ज करते समय छोड़ देते हैं। या परीक्षण समाप्त हो जाता है इससे पहले कि उपयोगकर्ता उस फीचर तक पहुंचे जिसकी उन्हें वास्तव में आवश्यकता है। या सक्रियण बहुत कठिन है: उन्हें 6 फ़ील्ड भरने होते हैं, 2 इंटीग्रेशन कनेक्ट करने होते हैं, और तभी वे कोई परिणाम देख सकते हैं। SaaS के लिए, यह आपके ट्रैफ़िक का एक हिस्सा खोने का सीधा रास्ता है।

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

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

4. राजस्व और भुगतान अनुशासन

जब गतिविधि स्पष्ट हो जाए, तो पैसे पर ध्यान देने का समय होता है। यहाँ मानक कोर सेट MRR, ARR, प्रति ग्राहक औसत राजस्व, भुगतान रूपांतरण, बकाया भुगतान, सदस्यता रद्दीकरण, और रिफंड हैं। यदि SaaS बढ़ रहा है लेकिन राजस्व स्थिर है, तो वृद्धि गलत जगह से आ रही है या ट्रैफ़िक बहुत सस्ता है।

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

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

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

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

5. बनाए रखना और चर्न

रिटेंशन यह दिखाता है कि क्या उपयोगकर्ता उत्पाद के साथ पहले संपर्क के बाद रुके। दूसरी ओर, चर्न यह दिखाता है कि SaaS ने किसे खो दिया। यहाँ सबसे सरल मैट्रिक्स चर्न और रिटेंशन हैं। सरल, लेकिन ईमानदार।

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

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

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

रिटेंशन को एक बटन से ठीक करना शायद ही कभी संभव होता है। आमतौर पर इसमें 2-3 छोटे बदलाव लगते हैं: पहले मूल्य को तेज़ करना, स्पष्ट नेविगेशन, कम अनावश्यक कदम, और अधिक सटीक अनुस्मारक। लेकिन ये वही बदलाव हैं जो 3-6 महीनों में प्रभाव डालते हैं, न कि केवल एक रिपोर्ट में।

6. खंड द्वारा व्यवहार

एक समग्र SaaS संख्या अक्सर गलत होती है। विभिन्न योजनाओं के उपयोगकर्ता अलग-अलग व्यवहार करते हैं, और यह सामान्य है। यही कारण है कि विभाजन लगभग हमेशा आवश्यक होता है: योजनाएँ, अधिग्रहण चैनल, उपयोगकर्ता भूमिकाएँ, कंपनी का आकार, भूगोल।

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

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

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

रिपोर्टों को मैन्युअल रूप से बनाने से बचने के लिए, पहले से संरचना के बारे में सोचना सहायक होता है। यदि परियोजना पहले से ही एकीकरण और पहुंच लॉजिक में बढ़ गई है, तो एक साइट एनालिटिक्स और मॉनिटरिंग प्लेटफ़ॉर्म · उपयोगी हो सकता है - एक चमकदार उदाहरण के रूप में नहीं, बल्कि एक अनुस्मारक के रूप में कि खंडों को शुरू से ही प्रणाली में सबसे अच्छा बनाया जाता है।

7. समर्थन, त्रुटियाँ, और तकनीकी स्वास्थ्य

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

आपको कम से कम 4 संकेतों को ट्रैक करना चाहिए: समर्थन अनुरोधों की संख्या, अनुरोधों के प्रकार, प्रमुख कार्यप्रवाहों में त्रुटियाँ, और भुगतान में देरी। यदि किसी विशेष फीचर के चारों ओर टिकट बढ़ते हैं, तो उस फीचर में शायद एक टूटी हुई इंटरफेस या लॉजिक है। यदि एक ही कारण के लिए अनुरोध लगातार आते हैं, तो समस्या प्रणालीगत है, यादृच्छिक नहीं।

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

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

जब तकनीकी स्वास्थ्य गिरता है, तो रिटेंशन और राजस्व मेट्रिक्स में कई दिनों की देरी के साथ गिरावट आ सकती है। यह बुरी खबर है। लेकिन यदि आप समर्थन और त्रुटियों को "गैर-उत्पाद" मुद्दों के रूप में खारिज नहीं करते हैं, तो यह पहले से दिखाई देता है।

8. SaaS के लिए एक न्यूनतम डैशबोर्ड सेट कैसे बनाएं

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

प्रत्येक स्क्रीन में 6–8 मुख्य मैट्रिक्स से अधिक नहीं होना चाहिए। अन्यथा लोग डैशबोर्ड को देखना बंद कर देते हैं और विश्लेषक से पूछते हैं, “यहां क्या महत्वपूर्ण है?” SaaS में, यह एक महंगा सवाल है, क्योंकि रिपोर्ट में अतिरिक्त शोर निर्णयों को धीमा कर देता है बजाय कि उन्हें तेज करने के।

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

एक और व्यावहारिक बिंदु: एक स्क्रीन पर उत्पाद और वित्तीय मैट्रिक्स को स्पष्ट तर्क के बिना न मिलाएं। जब “दैनिक लॉगिन” और “वार्षिक राजस्व” एक-दूसरे के बगल में होते हैं, तो मस्तिष्क सबसे तेज़ संख्या को पकड़ता है और संदर्भ खो देता है। एक ओवरलोडेड एक की तुलना में 4 डैशबोर्ड होना बेहतर है। यह स्वाद का मामला नहीं है। यह प्रबंधनीयता का मामला है।

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