सर्वोत्तम अनुभव बनाने के लिए, इंजीनियरों को सर्वोत्तम उपलब्ध डेटा की आवश्यकता होती है।
मोबाइल इस चुनौती को और अधिक जटिल बना देता है, जिसमें वेरिएबल्स शामिल हैं जिनमें डिवाइस प्रकार, विभिन्न ऑपरेटिंग सिस्टम और कनेक्टिविटी जैसे कुछ नाम शामिल हैं।
टूल की बढ़ती संख्या के साथ, जो आपके मोबाइल ऐप के स्वास्थ्य, प्रदर्शन और स्थिरता में दृश्यता के विभिन्न स्तर प्रदान करते हैं, यह जानना मुश्किल हो सकता है कि आपको वास्तव में कौन से मेट्रिक्स पर नज़र रखनी चाहिए।
इस पोस्ट में, हम सबसे महत्वपूर्ण प्रदर्शन मेट्रिक्स की रूपरेखा तैयार करेंगे जिन्हें आपको ट्रैक करने की आवश्यकता है और वे आपको समस्याओं के मूल कारण तक तेजी से पहुंचने में कैसे मदद करते हैं ताकि आप बेहतर मोबाइल अनुभव बना सकें।
मोबाइल उपयोगकर्ता आमतौर पर चलते-फिरते अपने ऐप्स की जांच करते हैं और तत्काल परिणामों के आदी होते हैं। इसलिए, वे इधर-उधर बैठकर ऐप लोड होने का इंतजार नहीं करेंगे। उदाहरण के लिए, यदि उबर ऐप को लोड होने में बहुत अधिक समय लगता है, तो उपयोगकर्ता संभवतः इसके बजाय Lyft ऐप पर स्विच कर देगा। इसके अलावा, जिन उपयोगकर्ताओं को उबर ऐप में खराब अनुभव था और लिफ़्ट ऐप में अच्छा अनुभव था, उनके वफादार लिफ़्ट उपयोगकर्ता बनने की अधिक संभावना है।
अब, न केवल आपने उस उपयोगकर्ता के सत्र से राजस्व खो दिया है, बल्कि आपकी प्रति अधिग्रहण और मंथन लागत भी बढ़ गई है, उस एलटीवी का उल्लेख नहीं किया गया है जो वह विशेष ग्राहक कंपनी ला सकता था।
इसलिए, यह सुनिश्चित करना कि आपके ऐप का स्टार्टअप समय उपयोगकर्ता की अपेक्षाओं को पूरा करे, इसकी सफलता के लिए आवश्यक है।
हालाँकि, यदि मोबाइल टीम के पास केवल औसत स्टार्टअप समय तक पहुंच है, तो वे संभवतः महत्वपूर्ण बदलावों से चूक जाते हैं और सक्रिय होने के बजाय प्रतिक्रियात्मक रूप से प्रतिक्रिया करते हैं।
उदाहरण के लिए, मान लें कि कोई कंपनी अपने ऐप को एक नए बाज़ार में लॉन्च कर रही है, और समग्र प्रतिक्रिया नकारात्मक है। औसत स्टार्टअप समय से पता चलता है कि ऐप लॉन्च से पहले की तुलना में कुछ मिलीसेकंड लंबा है, लेकिन यह इंगित नहीं करता है कि लॉन्च के दौरान यह नाटकीय रूप से धीमा हो गया है। तो कोई और समस्या तो होगी ही ना?
दुर्भाग्य से, क्योंकि नए बाज़ार में उपयोगकर्ताओं का प्रतिशत कुल उपयोगकर्ता आधार का केवल एक अंश है, इसलिए यह समझ में आता है कि नए बाज़ार में बेहद कम स्टार्टअप समय भी कुल उपयोगकर्ता आधार के स्टार्टअप समय को न्यूनतम रूप से प्रभावित करेगा।
इसके बजाय, टीम को बेहतर ढंग से समझने के लिए डेटा को विभाजित करने में सक्षम होना चाहिए कि स्टार्टअप का समय व्यवसाय को कैसे प्रभावित करता है।
उदाहरण के लिए, उच्च-मूल्य वाले उपयोगकर्ता धीमी स्टार्टअप से कैसे पीड़ित हैं? क्या नए बाज़ार में उपयोगकर्ता ख़राब प्रदर्शन का अनुभव कर रहे हैं? क्या कुछ डिवाइस धीमे स्टार्टअप का अनुभव कर रहे हैं?
यह डेटा आपकी कंपनी को फिर से स्थिति पर नियंत्रण देता है और समय-संवेदनशील परिदृश्यों में अनुमान लगाने से बचता है जो आपके राजस्व को प्रभावित करते हैं।
अधिक जानने के लिए, मोबाइल ऐप स्टार्टअप समय को बेहतर बनाने के तरीके पर हमारी ईबुक देखें।
दुर्घटनाएँ ग्राहकों को नाराज़ करने का एक निश्चित तरीका है और वह भी अच्छे कारण से! यह अनिवार्य रूप से एक ग्राहक के ईंट-और-मोर्टार स्टोर में जाने के समान है जहां कर्मचारी उन्हें खरीदारी के बीच में ही दरवाजे से बाहर निकाल देते हैं।
यह कंपनी के ब्रांड के लिए दो कारणों से एक प्रमुख मुद्दा है:
यह आपके ब्रांड की प्रतिष्ठा को नुकसान पहुंचाता है क्योंकि ग्राहकों को लगता है कि उनके समय का अनादर किया गया है।
यह आपके राजस्व को नुकसान पहुंचाता है क्योंकि ग्राहक अपना तत्काल लेनदेन पूरा नहीं कर पाते हैं, और यदि वे किसी प्रतिस्पर्धी के पास जाने का निर्णय लेते हैं तो आप उस ग्राहक का आजीवन मूल्य खो देते हैं।
यहां विभिन्न उद्योगों के कुछ उदाहरण दिए गए हैं जहां दुर्घटना का सीधा मतलब राजस्व की हानि है:
ई-कॉमर्स ऐप्स: यदि कोई ई-कॉमर्स ऐप चेकआउट के दौरान क्रैश हो जाता है, तो ग्राहक अपनी खरीदारी नहीं कर पाएगा और संभवतः वापस नहीं आएगा।
पीओएस सिस्टम : यदि किसी लाइव इवेंट के दौरान पीओएस सिस्टम क्रैश हो जाता है, तो उनमें से कोई भी लाइव ग्राहक खरीदारी नहीं कर पाएगा या आयोजन स्थल में प्रवेश नहीं कर पाएगा।
स्मार्ट डिवाइस ऐप्स : यदि कोई स्मार्ट डिवाइस, जैसे टूथब्रश, सेटअप प्रक्रिया के दौरान क्रैश हो जाता है, तो इसकी बहुत संभावना है कि ग्राहक उत्पाद वापस कर देगा।
हालाँकि, औसत दुर्घटना दर पर नज़र रखना एक अच्छी शुरुआत है, फिर भी यह समझने के लिए पर्याप्त नहीं है कि दुर्घटनाएँ आपके व्यवसाय को कैसे प्रभावित करती हैं ।
उदाहरण के लिए, यदि वर्तमान दुर्घटना दर केवल 0.5% है, तो आपको अधिक गहराई तक ड्रिल करने की आवश्यकता नहीं दिखेगी। हालाँकि, यदि सभी क्रैश चेकआउट स्क्रीन पर होते हैं तो क्या होगा? वह छोटा सा प्रतिशत व्यवसाय के महत्वपूर्ण राजस्व को धोखा दे सकता है।
इसलिए, प्रमुख मीट्रिक संख्याओं को देखने के अलावा, ऐसे डेटा का होना भी महत्वपूर्ण है जो क्रैश दर में पैटर्न दिखाता हो। विशेष रूप से, आपके ऐप में विभिन्न उच्च-मूल्य वाले क्षेत्र कैसा प्रदर्शन कर रहे हैं? कौन से उपकरण सबसे अधिक क्रैश का अनुभव करते हैं? उच्च-मूल्य वाले उपयोगकर्ताओं के लिए ऐप कैसा प्रदर्शन कर रहा है? क्या ऐसे कोई क्षेत्र हैं जहां विशेष रूप से खराब दुर्घटना दर का अनुभव होता है? और यदि हां, तो क्या ऐप को ठीक किया जाना चाहिए या उन क्षेत्रों से हटा दिया जाना चाहिए?
क्रैश विवरण को विभाजित करके, आपकी टीम समस्याओं को ठीक करने को बेहतर प्राथमिकता दे सकती है।
एप्लिकेशन नॉट रिस्पॉन्डिंग (एएनआर) त्रुटियों को आम तौर पर फ़्रीज़ या गड़बड़ के रूप में वर्णित किया जाता है।
अनिवार्य रूप से, यदि मुख्य थ्रेड अवरुद्ध है, तो एप्लिकेशन प्रभावी ढंग से नहीं चल सकते हैं। इसलिए, उपयोगकर्ता आगे नहीं बढ़ सकता, जिसका आपके व्यवसाय पर बड़ा प्रभाव पड़ सकता है।
उदाहरण के लिए, जिस रिटेलर के साथ हमने काम किया था, उसे ANR की समस्या थी। इस समस्या के कारण स्टार्टअप समय में लगभग 60% की वृद्धि हो रही थी, जिससे प्रति वर्ष $6.5 मिलियन की अनुमानित राजस्व हानि हो रही थी। सही डेटा के साथ , इंजीनियरिंग टीम समस्या का तुरंत समाधान करने और खोए हुए राजस्व को पुनः प्राप्त करने में सक्षम थी।
राजस्व के अलावा, ANR Google Play Store में किसी ऐप की रैंकिंग पर भी नकारात्मक प्रभाव डाल सकता है और इसे नए ग्राहकों के लिए कम दृश्यमान बना सकता है।
ANR को प्रभावी ढंग से ट्रैक करने के लिए, आप स्टैक ट्रेस को देख सकते हैं और देख सकते हैं कि उपयोगकर्ताओं ने समस्या पर कैसे प्रतिक्रिया दी।
वहां से, मोबाइल टीम प्राथमिकता दे सकती है कि विभिन्न सीमाओं पर कितने लोग निकलते हैं, जहां उच्च-मूल्य वाले उपयोगकर्ता सबसे अधिक प्रभावित होते हैं, और कौन से डिवाइस प्रकार और स्क्रीन एएनआर से सबसे अधिक प्रभावित होते हैं, इसके आधार पर पहले क्या ठीक करना है।
अधिक जानने के लिए, ANRs जैसे एंड्रॉइड क्रैश की जांच पर यह पोस्ट देखें।
क्षेत्र मेट्रिक्स को ट्रैक करना भी बहुत महत्वपूर्ण है क्योंकि विभिन्न क्षेत्रों के उपयोगकर्ताओं के पास अलग-अलग डिवाइस और अलग-अलग कनेक्टिविटी हैं।
इससे कई कारणों से व्यवसाय पर बड़ा प्रभाव पड़ सकता है।
सबसे पहले, व्यवसाय की निचली रेखा के लिए क्षेत्र अपने महत्व में भिन्न होते हैं।
उदाहरण के लिए, शायद आपके उपयोगकर्ताओं का केवल एक हिस्सा ही सिंगापुर में है, लेकिन वे आपके कुल वार्षिक राजस्व का एक बड़ा हिस्सा बना सकते हैं। इसलिए, विस्तृत स्तर पर क्षेत्र मेट्रिक्स की जांच करने से ऐप को बेहतर बनाने के अवसर उजागर होंगे, खासकर उच्च-मूल्य वाले उपयोगकर्ताओं के लिए।
किसी नए क्षेत्र में लॉन्च करते समय खंडित क्षेत्र मेट्रिक्स को ट्रैक करना भी आवश्यक है।
उदाहरण के लिए, मान लीजिए कि आप ऑस्ट्रेलिया में विस्तार करते हैं, फिर भी वह भौगोलिक क्षेत्र लॉन्च पर सभी उपयोगकर्ताओं का केवल 5% बनाता है। उस स्थिति में, यह औसत/औसत मेट्रिक्स को इतना प्रभावित नहीं करेगा कि टीम प्रदर्शन को प्रभावी ढंग से ट्रैक कर सके।
सांस्कृतिक अंतरों को ध्यान में रखना भी महत्वपूर्ण है, और एक उपकरण के साथ जो क्षेत्र-विशिष्ट मेट्रिक्स प्रदान करता है, टीम केवल उस क्षेत्र के लिए ऐप के विशिष्ट पहलुओं का परीक्षण कर सकती है।
उदाहरण के लिए, एक ई-कॉमर्स चेकआउट स्क्रीन जो संयुक्त राज्य अमेरिका में अच्छी तरह से रूपांतरित होती है, दुबई में उतनी अच्छी तरह से रूपांतरित नहीं हो सकती है।
इसके अलावा, ग्रैन्युलर रीजन मेट्रिक्स नई सुविधाओं को धीरे-धीरे रोल आउट करना आसान बनाते हैं। उदाहरण के लिए, टीम एक छोटे क्षेत्र में एक नई सुविधा शुरू कर सकती है और देख सकती है कि यह कैसा प्रदर्शन करती है। यदि यह अच्छा प्रदर्शन करता है, तो इसे उच्च-मूल्य वाले उपयोगकर्ताओं वाले अधिक से अधिक क्षेत्रों में रोल आउट करें।
यह डेटा आपकी टीम को महत्वपूर्ण प्रश्नों के उत्तर देने में मार्गदर्शन कर सकता है जैसे:
नज़र रखने के लिए एक अन्य महत्वपूर्ण मीट्रिक सत्र अवधि है, क्योंकि यह संकेत देता है कि उपयोगकर्ता आपके ऐप का उपयोग कितने समय से कर रहे हैं। यदि औसत सत्र अवधि एक सप्ताह में नाटकीय रूप से बदलती है, तो यह एक बहुत अच्छा संकेत है कि ऐप में कोई समस्या है।
उदाहरण के लिए, यदि आपके पास एक गेमिंग ऐप है और औसत सत्र अवधि 15 मिनट से घटकर 5 मिनट हो गई है, तो इस बात की अच्छी संभावना है कि उपयोगकर्ताओं को खराब अनुभव हुआ।
इस सुराग के साथ, आप जैसे प्रश्न पूछ सकते हैं:
सत्र की अवधि को ट्रैक करने से टीम को प्रभावित व्यक्तिगत सत्रों के बीच पैटर्न की जांच करने और मुद्दों के मूल कारण का पता लगाने की भी अनुमति मिलती है। अन्य मेट्रिक्स के समानांतर सत्र अवधि का विश्लेषण करके, मोबाइल इंजीनियर एक स्पष्ट तस्वीर खींच सकते हैं कि कौन से मुद्दे उपयोगकर्ताओं के लिए सबसे अधिक परेशान करने वाले हैं।
उदाहरण के लिए, एक ई-कॉमर्स स्टोर में उत्पादों की मुख्य स्क्रॉलिंग फ़ीड पर एक ओओएम समस्या हो सकती है जो छोटी सत्र अवधि के साथ दृढ़ता से संबंधित होती है, जबकि दूसरी स्क्रीन पर धीमी नेटवर्क कॉल का सत्र अवधि के साथ बहुत कम या कोई संबंध नहीं होता है।
इसलिए, सत्र की अवधि को ट्रैक करना यह प्राथमिकता देने का एक शानदार तरीका है कि किन मुद्दों को पहले ठीक किया जाना चाहिए क्योंकि यह सीधे तौर पर कम उपयोगकर्ता सहभागिता को प्रकट करता है।
मौजूदा ग्राहक को खुश रखने की तुलना में नया ग्राहक हासिल करने में बहुत अधिक खर्च होता है, और मोबाइल ऐप उपयोगकर्ताओं में मंथन का एक प्रमुख कारण खराब उपयोगकर्ता अनुभव है।
किसी नए ऐप को डाउनलोड करने में केवल कुछ सेकंड लगते हैं, इसलिए यदि किसी ऐप का अनुभव उपयोगकर्ता को इस तरह से बाधित करता है कि उसका समय कुछ सेकंड से अधिक लग जाता है, तो उनसे यह उम्मीद न करें कि वे वहीं टिके रहेंगे।
इसलिए, न केवल समग्र मंथन और प्रतिधारण दर को ट्रैक करें, बल्कि उपयोगकर्ता आधार के खंडों (डिवाइस, कनेक्टिविटी, क्षेत्र आदि द्वारा) के मंथन और प्रतिधारण दर को भी ट्रैक करें।
यह अवधारण में सुधार और प्राथमिकता देने के विभिन्न अवसरों पर प्रकाश डालेगा। उदाहरण के लिए, आप पा सकते हैं कि जबकि एक विशेष क्षेत्र में मंथन दर बहुत अधिक है, उस क्षेत्र में कुछ उच्च-मूल्य वाले उपयोगकर्ता हैं। इसलिए, आप इंजीनियरिंग संसाधनों को कहीं और निवेश करने का निर्णय ले सकते हैं जहां वे बड़े व्यावसायिक परिणामों में तब्दील होंगे।
मंथन और प्रतिधारण को ट्रैक करना यह समझने का एक शानदार तरीका है कि उपयोगकर्ता नई रिलीज़ और विभिन्न प्रयोगों पर कैसे प्रतिक्रिया देते हैं। यदि उच्च मंथन और नए फीचर अपडेट के बीच कोई संबंध है, तो यह एक मजबूत संकेतक है कि टीम को उस फीचर अपडेट को वापस लाने की जरूरत है।
विस्तृत डेटा टीम को विभिन्न खंडों (जैसे विशिष्ट क्षेत्र या डिवाइस) के मंथन को ट्रैक करने की अनुमति देगा, जिनके लिए अपडेट जारी किया गया है।
खंडित डेटा के बिना, छोटे परीक्षण समूहों पर विभिन्न फीचर अपडेट के प्रभाव को देखना मुश्किल होगा। इसलिए, केवल एक बार जब सुविधा को उपयोगकर्ताओं के एक बड़े समूह के लिए रोल आउट कर दिया जाता है (और संभवतः कई मासिक सक्रिय उपयोगकर्ताओं को छोड़ दिया जाता है) तो यह स्पष्ट हो जाएगा कि सुविधा रोलआउट समय से पहले किया गया था।
जबकि कुछ उपयोगकर्ता समाप्ति उपयोगकर्ता द्वारा अपने फ़ोन को अव्यवस्थित करने से अधिक कुछ नहीं हैं, कई समाप्ति इसलिए होती हैं क्योंकि ऐप फ़्रीज़ हो गया है, और उपयोगकर्ता के पास स्वाइप करने और सत्र समाप्त करने के अलावा कोई विकल्प नहीं है।
निःसंदेह, जिस उपयोगकर्ता को अपना सत्र समाप्त करने के लिए मजबूर किया जाता है, वह संभवतः असंतुष्ट होगा और इसके बजाय किसी प्रतिस्पर्धी का ऐप चुन लेगा।
इसे रोकने के लिए, औसत उपयोगकर्ता समाप्ति दर की निगरानी करना संभावित मुद्दों का एक उत्कृष्ट संकेतक है जो मंथन का कारण बन सकता है, जिसमें शामिल हैं:
औसत उपयोगकर्ता समाप्ति दरों का अवलोकन प्रदान करने के अलावा, मोबाइल टीमों को प्रत्येक खराब उपयोगकर्ता अनुभव के स्रोत को जानना होगा। इसलिए, एम्ब्रेस में हमारे द्वारा निर्मित प्रमुख विशेषताओं में से एक यह देखने की क्षमता है कि कौन सी स्क्रीन निराश उपयोगकर्ताओं को आपके ऐप को छोड़ने का कारण बनती है ।
इसलिए, मूल्यवान समय बर्बाद करने और बिक्री खोने के बजाय जब इंजीनियर यह अनुमान लगाते हैं कि समाप्ति कहां हो रही है, तो मोबाइल टीम को तुरंत समस्या पर निर्देशित किया जाता है ताकि वे समस्या को यथासंभव कुशलता से ठीक कर सकें।
आपके ऐप के भीतर कुछ उपयोगकर्ता क्रियाएं होने की संभावना है जो निश्चित रूप से 100% समय काम करनी चाहिए। उदाहरण के लिए, यदि कोई कार्यालय बिना चाबी के प्रवेश की पेशकश करता है, तो वह सुविधा हर बार काम करनी चाहिए। अन्यथा, लोग अतिरिक्त सहायता बुलाए बिना कार्यालय में प्रवेश नहीं कर पाएंगे।
इसलिए, कुछ प्रमुख उपयोगकर्ता क्रियाओं का चयन करें और उन्हें मोबाइल टीम द्वारा ट्रैक किए जा रहे प्रदर्शन मेट्रिक्स की सूची में जोड़ें।
कई मामलों में, ग्राहक समीक्षाएं यह नहीं बताती हैं कि उन्हें ऐप में कहां समस्या का सामना करना पड़ा, इसलिए विशिष्ट उपयोगकर्ता गतिविधियों पर नज़र रखना उन समस्याओं को पकड़ने का एक शानदार तरीका है जो अन्यथा तुरंत स्पष्ट नहीं होती हैं।
इससे आपको निम्न जैसे प्रश्नों का उत्तर देने में भी सहायता मिलती है:
कितने उपयोगकर्ताओं को ऐप के इन महत्वपूर्ण क्षेत्रों में समस्याओं का अनुभव होता है?
क्या ऐप और मंथन के विशिष्ट क्षेत्रों के मुद्दों के बीच कोई सीधा संबंध है?
उपयोगकर्ता ऐप छोड़ने और त्यागने से पहले कितनी देर तक प्रयास करते हैं?
उदाहरण के लिए, हमारे ग्राहकों में से एक ने देखा कि सभी खरीदारी प्रयासों में से लगभग 1% के परिणामस्वरूप खरीदारी विफल रही। हालाँकि, दोनों संबंधित नेटवर्क कॉल सफलतापूर्वक हल हो रही थीं, इसलिए निरीक्षण करने के लिए कोई स्पष्ट त्रुटियां नहीं थीं।
इसलिए, उन्होंने उस सटीक क्षण को ट्रैक करना शुरू कर दिया जब ग्राहक खरीदारी करेगा और पाया कि 1% खरीदारी प्रयासों में दो नेटवर्क कॉल ऑर्डर से बाहर हो रहे थे, जिसके परिणामस्वरूप खरीदारी विफल हो गई। हालाँकि ग्राहक इस समस्या के बारे में शिकायत कर रहे थे, मोबाइल टीम प्रभावित सत्रों के दौरान सभी घटनाओं के समय, परिणाम और क्रम को जाने बिना मूल कारण का पता नहीं लगा सकी। उच्च-निष्ठा उपयोगकर्ता अनुभव डेटा उनकी कुल बिक्री का 1% पुनः प्राप्त करने में मदद करने में महत्वपूर्ण था। 10 मिलियन डॉलर की वार्षिक बिक्री करने वाली कंपनी के लिए, यह $100,000 है जो अन्यथा हर साल खो जाएगा!
किसी भी संभावित मेमोरी लीक की पहचान करने के लिए अपने ऐप की मेमोरी खपत को ट्रैक करना महत्वपूर्ण है। आपके ऐप की मेमोरी उपयोग की दक्षता सीधे तौर पर इस बात से संबंधित है कि आपका उपयोगकर्ता अनुभव कितना प्रतिक्रियाशील है।
यही कारण है कि मेमोरी उपयोग की निगरानी और अनुकूलन एक सहज उपयोगकर्ता अनुभव प्रदान करने में महत्वपूर्ण भूमिका निभाता है।
आप अपने ऐप के मेमोरी उपयोग से संबंधित समस्याओं से बच सकते हैं:
अपने कोडबेस को अनुकूलित करना और उन क्षेत्रों को इंगित करना जहां मेमोरी अनजाने में बरकरार रहती है, मेमोरी उपयोग में वृद्धि का कारण बनती है।
अपने ऐप की मेमोरी खपत को नियमित आधार पर ट्रैक करना, नई रिलीज़ के बाद किसी भी बदलाव को नोट करना।
बड़ी छवियों को लोड करने या बड़ी फ़ाइलों को संसाधित करने और असामान्य स्पाइक्स या निरंतर उच्च मेमोरी उपयोग के लिए अलर्ट बनाने जैसे मेमोरी-गहन संचालन की सावधानीपूर्वक निगरानी करना।
आपके ऐप की मेमोरी खपत के संबंध में एक सुव्यवस्थित रणनीति प्रतिक्रियाशील, स्थिर और प्रभावी ऐप बनाती है जो आपके उपयोगकर्ताओं को पसंद आएगी।
मोबाइल ऐप्स अलग-अलग वातावरण में अलग-अलग नेटवर्क स्थितियों के साथ काम करते हैं, जिनमें 3जी, 4जी, 5जी, वाई-फाई और कभी-कभी सीमित या अस्थिर कनेक्टिविटी शामिल है।
यही कारण है कि बेहतरीन उपयोगकर्ता अनुभव बनाने के लिए इन अलग-अलग स्थितियों से उत्पन्न चुनौतियों को पहचानना महत्वपूर्ण है। खराब नेटवर्क प्रदर्शन के संकेतकों में शामिल हैं:
विलंबता और धीमी प्रतिक्रिया समय.
बैंडविथ उपयोग।
अकुशल एपीआई कॉल.
डिवाइस-विशिष्ट ऑफ़लाइन क्षमताएं.
उदाहरण के लिए, फार्म डॉग एक कृषि ऐप है जो किसानों और कृषिविदों को अपने साथियों और सहकर्मियों के साथ खेत में रहने के दौरान अपने निष्कर्षों का दस्तावेजीकरण करने की अनुमति देता है।
जब नेटवर्क प्रतिक्रिया समय असाधारण रूप से धीमा होता था और जब डिवाइस यह निर्धारित नहीं कर पाते थे कि वे कनेक्ट हैं या नहीं, तो ऐप अक्सर क्रैश हो जाता था। उन्होंने देखा कि Google मानचित्र का प्रतिक्रिया समय 18-22 सेकंड के बीच है जबकि उन्हें केवल कुछ सेकंड होना चाहिए।
उचित टूलींग के बिना, उन्हें खराब नेटवर्क कनेक्शन का अनुकरण करने के लिए प्रॉक्सी का उपयोग करके समस्याओं को हल करने के लिए जटिल वर्कअराउंड का उपयोग करने की आवश्यकता होगी। हालाँकि, उच्च-निष्ठा डेटा के साथ, वे उन सटीक स्थितियों को देख सकते हैं जो उपयोगकर्ताओं के पास फ़ील्ड में हैं, जिनमें शामिल हैं:
डिवाइस प्रकार, ऐप संस्करण, वाई-फ़ाई और सेल्युलर पर नेटवर्क कॉल।
समस्याग्रस्त मार्गों की पहचान करने के लिए सामान्य डोमेन में 4xx और 5xx त्रुटि प्रवृत्तियों की जानकारी।
टूटे हुए समापन बिंदु जो आपके उपयोगकर्ताओं को ऐप शुरू करने, मुख्य सामग्री लोड करने या महत्वपूर्ण लेनदेन पूरा करने से रोकते हैं।
क्लाइंट की ओर से प्रत्येक नेटवर्क कॉल की अवधि विलंबता के छिपे हुए बिंदुओं को प्रकट करती है।
इस जानकारी से लैस, फ़ार्म डॉग टीम ने अपने उपयोगकर्ताओं के सामने आने वाली समस्याओं का अनुकरण किया, समस्याग्रस्त स्थितियों को आसानी से पहचाना और उन्हें ठीक किया।
यदि आप मोबाइल अनुभवों की परवाह करते हैं, तो आपको उस डेटा की आवश्यकता है जो आपकी टीम को ऊपर उल्लिखित सभी मीट्रिक देखने में सक्षम बनाए।
एम्ब्रेस आपको केवल वह डेटा देकर बेहतर मोबाइल अनुभव बनाने में मदद करता है, जिससे आपके इंजीनियर अधिक कुशल बनते हैं और कठिन काम से कम परेशान होते हैं।
एम्ब्रेस के बारे में अधिक जानें और उपयोगकर्ताओं के अनुसार प्रमुख ऐप निराशाओं के बारे में जानने के लिए द स्टेट ऑफ़ मोबाइल एक्सपीरियंस रिपोर्ट डाउनलोड करें।
यहाँ भी प्रकाशित किया गया है.