अॅप इन द एअरमध्ये रिटेन्शनियरिंग कसे लागू केले जाते

वापरकर्त्याला मोबाईल ऍप्लिकेशनमध्ये ठेवणे हे संपूर्ण विज्ञान आहे. अभ्यासक्रमाच्या लेखकाने VC.ru वरील आमच्या लेखात त्याचे मूलभूत वर्णन केले आहे ग्रोथ हॅकिंग: मोबाइल अॅप विश्लेषण मॅक्सिम गोडझी, अॅप इन द एअर येथील मशीन लर्निंगचे प्रमुख. मॅक्सिम मोबाइल ऍप्लिकेशनच्या विश्लेषण आणि ऑप्टिमायझेशनवरील कामाचे उदाहरण वापरून कंपनीमध्ये विकसित केलेल्या साधनांबद्दल बोलतो. ॲप इन द एअरमध्ये विकसित उत्पादन सुधारण्याच्या या पद्धतशीर दृष्टिकोनाला रिटेन्शनियरिंग म्हणतात. तुम्ही तुमच्या उत्पादनामध्ये ही साधने वापरू शकता: त्यापैकी काही आहेत मोफत प्रवेश GitHub वर.

अॅप इन द एअर हे जगभरातील 3 दशलक्षाहून अधिक सक्रिय वापरकर्ते असलेले अॅप्लिकेशन आहे, ज्याद्वारे तुम्ही फ्लाइट ट्रॅक करू शकता, प्रस्थान/लँडिंग वेळा, चेक-इन आणि विमानतळ वैशिष्ट्यांमधील बदलांबद्दल माहिती मिळवू शकता.

फनेल पासून मार्गक्रमण करण्यासाठी

सर्व विकास कार्यसंघ एक ऑनबोर्डिंग फनेल तयार करतात (उत्पादन वापरकर्त्याच्या स्वीकृतीच्या उद्देशाने एक प्रक्रिया). ही पहिली पायरी आहे जी तुम्हाला वरून संपूर्ण प्रणाली पाहण्यात आणि अनुप्रयोग समस्या शोधण्यात मदत करते. पण जसजसे उत्पादन विकसित होईल तसतसे तुम्हाला या दृष्टिकोनाच्या मर्यादा जाणवतील. साध्या फनेलचा वापर करून, तुम्ही उत्पादनासाठी अस्पष्ट वाढीचे बिंदू पाहू शकत नाही. फनेलचा उद्देश ऍप्लिकेशनमधील वापरकर्त्यांच्या टप्प्यांवर एक सामान्य देखावा देणे, तुम्हाला सर्वसामान्य प्रमाण मेट्रिक्स दाखवणे हा आहे. परंतु फनेल स्पष्ट समस्यांकडे किंवा त्याउलट, विशेष वापरकर्ता क्रियाकलापांकडे सर्वसामान्यांपासून विचलन लपवेल.

अॅप इन द एअरमध्ये, आम्ही आमचे स्वतःचे फनेल तयार केले, परंतु उत्पादनाच्या वैशिष्ट्यांमुळे, आम्ही एक घंटागाडीसह समाप्त झालो. मग आम्ही दृष्टीकोन वाढवण्याचे ठरवले आणि ऍप्लिकेशनने दिलेली समृद्ध माहिती वापरायची.

जेव्हा तुम्ही फनेल तयार करता, तेव्हा तुम्ही वापरकर्ता ऑनबोर्डिंग ट्रॅजेक्टोरीज गमावता. ट्रॅजेक्टोरीजमध्ये वापरकर्त्याच्या क्रियांचा एक क्रम असतो आणि स्वतः अनुप्रयोग (उदाहरणार्थ, पुश सूचना पाठवणे).

टाइमस्टॅम्प वापरून, तुम्ही वापरकर्त्याच्या प्रक्षेपकाची अगदी सहजपणे पुनर्रचना करू शकता आणि त्या प्रत्येकासाठी एक आलेख तयार करू शकता. अर्थात, बरेच आलेख आहेत. म्हणून, तुम्हाला समान वापरकर्त्यांचे गट करणे आवश्यक आहे. उदाहरणार्थ, तुम्ही सर्व वापरकर्त्यांना सारणीच्या पंक्तीनुसार व्यवस्था करू शकता आणि ते किती वेळा विशिष्ट फंक्शन वापरतात याची यादी करू शकता.

अशा सारणीच्या आधारे, आम्ही मॅट्रिक्स बनवले आणि फंक्शन्सच्या वापराच्या वारंवारतेनुसार, म्हणजेच आलेखामधील नोड्सद्वारे वापरकर्त्यांना गटबद्ध केले. हे सहसा अंतर्दृष्टीच्या दिशेने पहिले पाऊल असते: उदाहरणार्थ, आधीच या टप्प्यावर आपण पहाल की काही वापरकर्ते काही फंक्शन्स अजिबात वापरत नाहीत. जेव्हा आम्ही वारंवारता विश्लेषण केले, तेव्हा आम्ही अभ्यास करू लागलो की आलेखामधील कोणते नोड "सर्वात मोठे" आहेत, म्हणजेच वापरकर्ते कोणत्या पृष्ठांना वारंवार भेट देतात. तुमच्यासाठी महत्त्वाच्या असलेल्या काही निकषांनुसार मूलभूतपणे भिन्न असलेल्या श्रेणी त्वरित हायलाइट केल्या जातात. येथे, उदाहरणार्थ, वापरकर्त्यांचे दोन क्लस्टर आहेत जे आम्ही सदस्यत्वाच्या निर्णयावर आधारित विभागले आहेत (एकूण 16 क्लस्टर होते).

हे कसे वापरावे

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

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

आता आमचे मुख्य कार्य हे आहे की अशा वापरकर्त्याने आमची आकडेवारी वापरत असताना त्याला त्याच्या एअरलाइनच्या लॉयल्टी प्रोग्रामशी कनेक्ट होण्यासाठी प्रोत्साहित करणे. या प्रकरणात, आम्ही त्याने खरेदी केलेल्या सर्व फ्लाइट्स आयात करू आणि त्याने नवीन तिकीट खरेदी करताच त्याला साइन अप करण्याचा प्रयत्न करू. या समस्येचे निराकरण करण्यासाठी, आम्ही Aviasales, Svyaznoy.Travel आणि इतर अनुप्रयोगांसह सहकार्य करण्यास सुरुवात केली. जेव्हा त्यांचा वापरकर्ता तिकीट खरेदी करतो, तेव्हा अॅप त्यांना अॅप इन द एअरमध्ये फ्लाइट जोडण्यासाठी सूचित करतो आणि आम्ही ते लगेच पाहतो.

आलेखाबद्दल धन्यवाद, आम्ही पाहिले की सदस्यता स्क्रीनवर जाणारे 5% लोक ते रद्द करतात. आम्ही अशा प्रकरणांचे विश्लेषण करण्यास सुरुवात केली आणि पाहिले की एक वापरकर्ता आहे जो पहिल्या पृष्ठावर जातो, त्याच्या Google खात्याचे कनेक्शन सुरू करतो आणि ते त्वरित रद्द करतो, पुन्हा पहिल्या पृष्ठावर जातो आणि असेच चार वेळा. सुरुवातीला आम्हाला वाटले, "या वापरकर्त्यामध्ये काहीतरी स्पष्टपणे चुकीचे आहे." आणि मग आम्हाला समजले की, बहुधा, अनुप्रयोगात एक बग आहे. फनेलमध्ये, याचा अर्थ खालीलप्रमाणे केला जाईल: वापरकर्त्याला अनुप्रयोगाने विनंती केलेल्या परवानग्यांचा संच आवडला नाही आणि तो निघून गेला.

दुसर्‍या गटामध्ये 5% वापरकर्ते स्क्रीनवर गमावले होते जेथे अॅप त्यांना त्यांच्या स्मार्टफोनवरील सर्व कॅलेंडर अॅप्समधून एक निवडण्यास सूचित करते. वापरकर्ते वेगवेगळ्या कॅलेंडरची वारंवार निवड करतील आणि नंतर फक्त अॅपमधून बाहेर पडतील. एक UX समस्या होती: एखाद्या व्यक्तीने कॅलेंडर निवडल्यानंतर, त्यांना वरच्या उजव्या कोपर्यात पूर्ण झाले क्लिक करावे लागले. हे इतकेच आहे की सर्व वापरकर्त्यांनी ते पाहिले नाही.

ऍप इन द एअरची पहिली स्क्रीन

आमच्या आलेखामध्ये, आम्ही पाहिले की सुमारे 30% वापरकर्ते पहिल्या स्क्रीनच्या पलीकडे जात नाहीत: हे या वस्तुस्थितीमुळे आहे की आम्ही वापरकर्त्यास सदस्यता घेण्यास प्रवृत्त करण्यात जोरदार आक्रमक आहोत. पहिल्या स्क्रीनवर, अॅप तुम्हाला Google किंवा Triplt वापरून नोंदणी करण्यास सूचित करते आणि नोंदणी वगळण्याबद्दल कोणतीही माहिती नाही. जे प्रथम स्क्रीन सोडतात त्यांच्यापैकी 16% वापरकर्ते “अधिक” वर क्लिक करतात आणि पुन्हा परत येतात. आम्हाला आढळले आहे की ते अर्जामध्ये अंतर्गत नोंदणी करण्याचा मार्ग शोधत आहेत आणि आम्ही ते पुढील अपडेटमध्ये प्रसिद्ध करू. याव्यतिरिक्त, जे लगेच निघून जातात त्यापैकी 2/3 लोक काहीही क्लिक करत नाहीत. त्यांचे काय होत आहे हे शोधण्यासाठी, आम्ही एक हीटमॅप तयार केला. असे दिसून आले की ग्राहक क्लिक करण्यायोग्य लिंक नसलेल्या अॅप वैशिष्ट्यांच्या सूचीवर क्लिक करत आहेत.

एक सूक्ष्म क्षण कॅप्चर करा

तुम्ही अनेकदा डांबरी रस्त्याच्या शेजारी लोक मार्ग तुडवताना पाहू शकता. रिटेन्शनियरिंग म्हणजे हे मार्ग शोधण्याचा आणि शक्य असल्यास रस्ते बदलण्याचा प्रयत्न.

अर्थात, हे वाईट आहे की आम्ही वास्तविक वापरकर्त्यांकडून शिकतो, परंतु कमीतकमी आम्ही अनुप्रयोगामध्ये वापरकर्त्याची समस्या दर्शविणारे नमुने स्वयंचलितपणे ट्रॅक करण्यास सुरुवात केली. आता उत्पादन व्यवस्थापकाला मोठ्या संख्येने “लूप” आल्यास ईमेल सूचना प्राप्त होतात—जेव्हा वापरकर्ता त्याच स्क्रीनवर पुन्हा पुन्हा येतो.

अनुप्रयोगाच्या समस्या आणि वाढीच्या क्षेत्रांचे विश्लेषण करण्यासाठी वापरकर्त्याच्या मार्गातील कोणते नमुने सामान्यतः मनोरंजक आहेत ते पाहूया:

• लूप आणि सायकल. वर नमूद केलेले लूप म्हणजे जेव्हा वापरकर्त्याच्या मार्गक्रमणात एखादी घटना पुनरावृत्ती होते, उदाहरणार्थ, कॅलेंडर-कॅलेंडर-कॅलेंडर-कॅलेंडर. पुष्कळ पुनरावृत्तीसह लूप हे इंटरफेस समस्या किंवा अपुरी इव्हेंट चिन्हांकित करण्याचे स्पष्ट सूचक आहे. सायकल देखील एक बंद मार्ग आहे, परंतु लूपच्या विपरीत त्यात एकापेक्षा जास्त इव्हेंट समाविष्ट आहेत, उदाहरणार्थ: फ्लाइट इतिहास पाहणे - फ्लाइट जोडणे - फ्लाइट इतिहास पाहणे.
• फ्लोस्टॉपर्स - जेव्हा वापरकर्ता, काही अडथळ्यामुळे, अनुप्रयोगाद्वारे त्याची इच्छित हालचाल चालू ठेवू शकत नाही, उदाहरणार्थ, क्लायंटला स्पष्ट नसलेल्या इंटरफेससह स्क्रीन. अशा घटनांचा वेग कमी होतो आणि वापरकर्त्यांचा मार्ग बदलतो.
• द्विभाजन बिंदू महत्त्वपूर्ण घटना आहेत ज्यानंतर विविध प्रकारच्या क्लायंटचे मार्ग वेगळे केले जातात. विशेषतः, हे असे स्क्रीन आहेत ज्यात लक्ष्य क्रियेसाठी थेट संक्रमण किंवा कॉल-टू-ऍक्शन नसतात, काही वापरकर्त्यांना त्याकडे प्रभावीपणे ढकलतात. उदाहरणार्थ, अॅप्लिकेशनमधील सामग्री खरेदी करण्याशी थेट संबंधित नसलेली काही स्क्रीन, परंतु ज्यावर ग्राहक सामग्री विकत घेण्याकडे किंवा न घेण्याकडे झुकतात, त्या वेगळ्या पद्धतीने वागतील. द्विभाजन बिंदू हे तुमच्या वापरकर्त्यांच्या कृतींवर अधिक चिन्हासह प्रभाव पाडणारे बिंदू असू शकतात - ते खरेदी किंवा क्लिक करण्याच्या निर्णयावर किंवा वजा चिन्हावर प्रभाव टाकू शकतात - ते निश्चित करू शकतात की काही चरणांनंतर वापरकर्ता अनुप्रयोग सोडेल.
• निरस्त केलेले रूपांतरण बिंदू संभाव्य द्विभाजन बिंदू आहेत. आपण त्यांना स्क्रीन म्हणून विचार करू शकता जे लक्ष्य क्रिया सूचित करू शकतात, परंतु तसे करू नका. जेव्हा वापरकर्त्याला गरज असते तेव्हा हे देखील एक बिंदू असू शकते, परंतु आम्ही ते पूर्ण करत नाही कारण आम्हाला त्याबद्दल माहिती नसते. प्रक्षेपक विश्लेषणाने ही गरज ओळखण्याची परवानगी दिली पाहिजे.
• डिस्ट्रक्शन पॉइंट - स्क्रीन/पॉप-अप जे वापरकर्त्याला मूल्य देत नाहीत, रूपांतरणावर परिणाम करत नाहीत आणि प्रक्षेपकाला “अस्पष्ट” करू शकतात, वापरकर्त्याचे लक्ष्य क्रियांपासून लक्ष विचलित करू शकतात.
• ब्लाइंड स्पॉट्स हे ऍप्लिकेशनचे लपलेले पॉईंट, स्क्रीन आणि वैशिष्‍ट्ये आहेत ज्यापर्यंत पोहोचणे वापरकर्त्यासाठी खूप कठीण आहे.
• नाले - बिंदू जेथे रहदारी गळती

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

हे मला एका मोठ्या विनोदाची आठवण करून देते. एक परीक्षक बारमध्ये जातो आणि ऑर्डर देतो: एक ग्लास बिअर, 2 ग्लास बिअर, 0 ग्लास बिअर, 999999999 ग्लास बिअर, एका ग्लासमध्ये एक सरडा, -1 ग्लास बिअर, qwertyuip ग्लास बिअर. पहिला खरा ग्राहक बारमध्ये जातो आणि शौचालय कुठे आहे ते विचारतो. बारला आग लागली आणि प्रत्येकजण मरण पावला.

उत्पादन विश्लेषक, या समस्येमध्ये खोलवर बुडून, मायक्रोमोमेंटची संकल्पना सादर करू लागले. आधुनिक वापरकर्त्याला त्यांच्या समस्येचे त्वरित निराकरण आवश्यक आहे. Google ने काही वर्षांपूर्वी याबद्दल बोलण्यास सुरुवात केली: कंपनीने अशा वापरकर्त्याच्या क्रियांना मायक्रो-मोमेंट्स म्हटले. वापरकर्ता विचलित होतो, चुकून ऍप्लिकेशन बंद करतो, त्याला काय आवश्यक आहे हे समजत नाही, एक दिवसानंतर पुन्हा लॉग इन करतो, पुन्हा विसरतो आणि नंतर मित्राने त्याला मेसेंजरमध्ये पाठवलेल्या लिंकचे अनुसरण करतो. आणि ही सर्व सत्रे 20 सेकंदांपेक्षा जास्त काळ टिकू शकत नाहीत.

म्हणून आम्ही समर्थन सेवेचे कार्य सेट करण्याचा प्रयत्न करू लागलो जेणेकरून कर्मचार्यांना जवळजवळ वास्तविक वेळेत समस्या काय आहे हे समजू शकेल. जेव्हा एखादी व्यक्ती समर्थन पृष्ठावर येते आणि त्याचा प्रश्न लिहू लागतो, तेव्हा आम्ही त्याच्या मार्गक्रमण - शेवटच्या 100 घटना जाणून घेऊन समस्येचे सार निश्चित करू शकतो. पूर्वी, आम्ही समर्थन विनंत्यांच्या मजकुराचे ML विश्लेषण वापरून सर्व समर्थन विनंत्यांचे वर्गीकरणात वितरण स्वयंचलित केले. वर्गीकरणाचे यश असूनही, जेव्हा सर्व विनंत्यांपैकी 87% विनंत्या 13 पैकी एका श्रेणीमध्ये योग्यरित्या वितरीत केल्या जातात, तेव्हा ते प्रक्षेपकांसोबत कार्य करते जे वापरकर्त्याच्या परिस्थितीसाठी स्वयंचलितपणे सर्वात योग्य उपाय शोधू शकतात.

आम्ही त्वरीत अद्यतने रिलीझ करू शकत नाही, परंतु आम्ही समस्या लक्षात घेण्यास सक्षम आहोत आणि, जर वापरकर्त्याने आम्ही आधीच पाहिलेल्या परिस्थितीचे अनुसरण केले तर, त्याला पुश सूचना पाठवा.

आम्‍ही पाहतो की अॅप्लिकेशन ऑप्टिमाइझ करण्‍यासाठी वापरकर्त्‍याच्‍या मार्गक्रमणांचा अभ्यास करण्‍यासाठी समृद्ध साधनांची आवश्‍यकता असते. पुढे, वापरकर्ते जे मार्ग घेतात ते सर्व जाणून घेतल्यास, तुम्ही आवश्यक मार्ग मोकळा करू शकता आणि सानुकूलित सामग्री, पुश नोटिफिकेशन्स आणि अनुकूली UI घटकांच्या मदतीने वापरकर्त्याला त्याच्या गरजा पूर्ण करणार्‍या आणि पैसे मिळवून देणार्‍या लक्ष्यित कृतींकडे नेतात. , तुमच्या व्यवसायासाठी डेटा आणि इतर मूल्य.

काय लक्षात घ्यावे

• फनेल वापरून केवळ उदाहरण म्हणून वापरकर्त्याच्या रूपांतरणाचा अभ्यास करणे म्हणजे ऍप्लिकेशन स्वतःच आपल्याला देत असलेली समृद्ध माहिती गमावणे.

• आलेखांवरील वापरकर्त्याच्या प्रक्षेपणाचे विश्लेषण तुम्हाला वापरकर्ते टिकवून ठेवण्यासाठी कोणती वैशिष्ट्ये वापरता हे पाहण्यात मदत करते किंवा उदाहरणार्थ, त्यांना सदस्यत्व घेण्यासाठी प्रोत्साहित करते.
• रिटेन्शनियरिंग टूल्स आपोआप, रिअल टाइममध्ये, अनुप्रयोगातील वापरकर्त्याच्या समस्या दर्शविणारे नमुने ट्रॅक करण्यास, त्यांना लक्षात घेणे कठीण असलेल्या बग्स शोधण्यात आणि बंद करण्यात मदत करतात.

• ते वापरकर्त्याच्या वर्तनाचे स्पष्ट नसलेले नमुने शोधण्यात मदत करतात.

• रिटेन्शनियरिंग टूल्स मुख्य वापरकर्ता इव्हेंट्स आणि मेट्रिक्सचा अंदाज लावण्यासाठी स्वयंचलित ML टूल्स तयार करणे शक्य करतात: वापरकर्ता नुकसान, LTV आणि इतर अनेक मेट्रिक्स जे ग्राफवर सहजपणे निर्धारित केले जातात.

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

स्त्रोत: www.habr.com