ऐप इन द एयर में रिटेंशनियरिंग कैसे कार्यान्वित की जाती है

किसी उपयोगकर्ता को मोबाइल एप्लिकेशन में रखना एक संपूर्ण विज्ञान है। पाठ्यक्रम के लेखक ने VC.ru पर हमारे लेख में इसकी मूल बातें बताईं ग्रोथ हैकिंग: मोबाइल ऐप एनालिटिक्स मैक्सिम गोडज़ी, ऐप इन द एयर में मशीन लर्निंग के प्रमुख। मैक्सिम एक मोबाइल एप्लिकेशन के विश्लेषण और अनुकूलन पर काम के उदाहरण का उपयोग करके कंपनी में विकसित उपकरणों के बारे में बात करता है। ऐप इन द एयर में विकसित उत्पाद सुधार के इस व्यवस्थित दृष्टिकोण को रिटेंशनियरिंग कहा जाता है। आप इन उपकरणों का उपयोग अपने उत्पाद में कर सकते हैं: उनमें से कुछ मौजूद हैं नि: शुल्क प्रवेश GitHub पर.

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

फ़नल से प्रक्षेप पथ तक

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

ऐप इन द एयर में, हमने अपना स्वयं का फ़नल बनाया, लेकिन उत्पाद की विशिष्टताओं के कारण, हमें एक ऑवरग्लास ही मिला। फिर हमने दृष्टिकोण का विस्तार करने और उस समृद्ध जानकारी का उपयोग करने का निर्णय लिया जो एप्लिकेशन हमें स्वयं देता है।

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

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

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

इसे कैसे उपयोग करे

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

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

अब हमारा मुख्य कार्य ऐसे उपयोगकर्ता को अपने एयरलाइन के वफादारी कार्यक्रम से जुड़ने के लिए प्रोत्साहित करना है, जबकि वह हमारे आंकड़ों का उपयोग कर रहा है। इस मामले में, हम उसके द्वारा खरीदी गई सभी उड़ानों को आयात करेंगे और जैसे ही वह नया टिकट खरीदेगा, उसे साइन अप करने के लिए प्रेरित करने का प्रयास करेंगे। इस समस्या को हल करने के लिए, हमने Aviasales, Svyaznoy.Travel और अन्य अनुप्रयोगों के साथ भी सहयोग करना शुरू किया। जब उनका उपयोगकर्ता टिकट खरीदता है, तो ऐप उन्हें ऐप इन द एयर में उड़ान जोड़ने के लिए संकेत देता है, और हम इसे तुरंत देखते हैं।

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

एक अन्य समूह में 5% उपयोगकर्ता स्क्रीन पर खो गए जहां ऐप उन्हें अपने स्मार्टफोन पर सभी कैलेंडर ऐप में से एक को चुनने के लिए संकेत देता है। उपयोगकर्ता बार-बार अलग-अलग कैलेंडर चुनेंगे और फिर ऐप से बाहर निकल जाएंगे। यह पता चला कि एक UX समस्या थी: किसी व्यक्ति द्वारा कैलेंडर चुनने के बाद, उन्हें शीर्ष दाएं कोने में Done पर क्लिक करना था। बात सिर्फ इतनी है कि सभी उपयोगकर्ताओं ने इसे नहीं देखा।

हवा में ऐप की पहली स्क्रीन

हमारे ग्राफ़ में, हमने देखा कि लगभग 30% उपयोगकर्ता पहली स्क्रीन से आगे नहीं जाते हैं: यह इस तथ्य के कारण है कि हम उपयोगकर्ता को सदस्यता लेने के लिए प्रेरित करने में काफी आक्रामक हैं। पहली स्क्रीन पर, ऐप आपको Google या Triplt का उपयोग करके पंजीकरण करने के लिए संकेत देता है, और पंजीकरण छोड़ने के बारे में कोई जानकारी नहीं है। पहली स्क्रीन छोड़ने वालों में से 16% उपयोगकर्ता "अधिक" पर क्लिक करते हैं और फिर से वापस आते हैं। हमें पता चला है कि वे एप्लिकेशन में आंतरिक रूप से पंजीकरण करने का तरीका ढूंढ रहे हैं और हम इसे अगले अपडेट में जारी करेंगे। इसके अलावा, जो लोग तुरंत चले जाते हैं उनमें से 2/3 लोग कुछ भी क्लिक नहीं करते हैं। यह पता लगाने के लिए कि उनके साथ क्या हो रहा है, हमने एक हीटमैप बनाया। यह पता चला है कि ग्राहक ऐप सुविधाओं की एक सूची पर क्लिक कर रहे हैं जो क्लिक करने योग्य लिंक नहीं हैं।

एक सूक्ष्म क्षण कैद करें

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

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

आइए देखें कि किसी एप्लिकेशन की समस्याओं और विकास क्षेत्रों का विश्लेषण करने के लिए उपयोगकर्ता प्रक्षेपवक्र में कौन से पैटर्न आम तौर पर दिलचस्प होते हैं:

• लूप और चक्र. ऊपर उल्लिखित लूप तब होते हैं जब एक घटना उपयोगकर्ता के प्रक्षेपवक्र में दोहराई जाती है, उदाहरण के लिए, कैलेंडर-कैलेंडर-कैलेंडर-कैलेंडर। बहुत अधिक दोहराव वाला लूप इंटरफ़ेस समस्या या अपर्याप्त ईवेंट अंकन का एक स्पष्ट संकेतक है। एक चक्र भी एक बंद प्रक्षेप पथ है, लेकिन लूप के विपरीत इसमें एक से अधिक घटनाएँ शामिल होती हैं, उदाहरण के लिए: उड़ान इतिहास देखना - उड़ान जोड़ना - उड़ान इतिहास देखना।
• फ़्लोस्टॉपर्स - जब उपयोगकर्ता, किसी बाधा के कारण, एप्लिकेशन के माध्यम से अपनी वांछित गति जारी नहीं रख पाता है, उदाहरण के लिए, एक इंटरफ़ेस वाली स्क्रीन जो क्लाइंट के लिए स्पष्ट नहीं है। ऐसी घटनाएं धीमी हो जाती हैं और उपयोगकर्ताओं के प्रक्षेप पथ को बदल देती हैं।
• द्विभाजन बिंदु महत्वपूर्ण घटनाएँ हैं जिनके बाद विभिन्न प्रकार के ग्राहकों के प्रक्षेप पथ अलग हो जाते हैं। विशेष रूप से, ये ऐसी स्क्रीन हैं जिनमें लक्ष्य कार्रवाई के लिए सीधा संक्रमण या कॉल-टू-एक्शन शामिल नहीं है, जो प्रभावी रूप से कुछ उपयोगकर्ताओं को इसकी ओर धकेलता है। उदाहरण के लिए, कुछ स्क्रीन जो सीधे तौर पर किसी एप्लिकेशन में सामग्री खरीदने से संबंधित नहीं हैं, लेकिन जिस पर ग्राहक सामग्री खरीदने या न खरीदने के इच्छुक हैं, वह अलग तरह से व्यवहार करेगी। द्विभाजन बिंदु प्लस चिह्न के साथ आपके उपयोगकर्ताओं के कार्यों पर प्रभाव के बिंदु हो सकते हैं - वे खरीदारी या क्लिक करने के निर्णय को प्रभावित कर सकते हैं, या ऋण चिह्न के साथ - वे यह निर्धारित कर सकते हैं कि कुछ चरणों के बाद उपयोगकर्ता एप्लिकेशन छोड़ देगा।
• निरस्त रूपांतरण बिंदु संभावित द्विभाजन बिंदु हैं। आप उन्हें ऐसी स्क्रीन के रूप में सोच सकते हैं जो लक्ष्य कार्रवाई का संकेत दे सकती हैं, लेकिन ऐसा नहीं है। यह एक ऐसा समय भी हो सकता है जब उपयोगकर्ता को कोई आवश्यकता हो, लेकिन हम उसे संतुष्ट नहीं कर पाते क्योंकि हमें इसके बारे में पता ही नहीं होता। प्रक्षेपवक्र विश्लेषण से इस आवश्यकता को पहचानने की अनुमति मिलनी चाहिए।
• व्याकुलता बिंदु - स्क्रीन/पॉप-अप जो उपयोगकर्ता को मूल्य प्रदान नहीं करते हैं, रूपांतरण को प्रभावित नहीं करते हैं और प्रक्षेप पथ को "धुंधला" कर सकते हैं, जिससे उपयोगकर्ता का लक्ष्य कार्यों से ध्यान भटक सकता है।
• ब्लाइंड स्पॉट एप्लिकेशन, स्क्रीन और सुविधाओं के छिपे हुए बिंदु हैं जिन तक उपयोगकर्ता के लिए पहुंचना बहुत मुश्किल है।
• नालियाँ - वे स्थान जहाँ यातायात लीक होता है

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

इससे मुझे एक बेहतरीन चुटकुला याद आता है. एक परीक्षक एक बार में जाता है और ऑर्डर देता है: एक गिलास बीयर, 2 गिलास बीयर, 0 गिलास बीयर, 999999999 गिलास बीयर, एक गिलास में एक छिपकली, -1 गिलास बीयर, क्वर्टयूआईपी बीयर का गिलास। पहला वास्तविक ग्राहक बार में आता है और पूछता है कि शौचालय कहाँ है। बार में आग लग जाती है और सभी लोग मर जाते हैं।

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

इसलिए हमने सहायता सेवा के कार्य को स्थापित करने का प्रयास करना शुरू किया ताकि कर्मचारी वास्तविक समय में समझ सकें कि समस्या क्या है। जब तक कोई व्यक्ति सहायता पृष्ठ पर आता है और अपना प्रश्न लिखना शुरू करता है, तब तक हम उसके प्रक्षेप पथ - पिछली 100 घटनाओं - को जानकर, समस्या का सार निर्धारित कर सकते हैं। पहले, हमने समर्थन अनुरोधों के पाठ के एमएल विश्लेषण का उपयोग करके सभी समर्थन अनुरोधों के वितरण को श्रेणियों में स्वचालित कर दिया था। वर्गीकरण की सफलता के बावजूद, जब सभी अनुरोधों में से 87% को 13 श्रेणियों में से किसी एक में सही ढंग से वितरित किया जाता है, तो यह प्रक्षेप पथ के साथ काम है जो स्वचालित रूप से उपयोगकर्ता की स्थिति के लिए सबसे उपयुक्त समाधान ढूंढ सकता है।

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

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

क्या ध्यान रखें

• केवल उदाहरण के रूप में फ़नल का उपयोग करके उपयोगकर्ता रूपांतरण का अध्ययन करने का अर्थ है उस समृद्ध जानकारी को खोना जो एप्लिकेशन स्वयं हमें देता है।

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

• वे उपयोगकर्ता के व्यवहार के गैर-स्पष्ट पैटर्न खोजने में मदद करते हैं।

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

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

स्रोत: www.habr.com