उत्पादनाचा खरा चेहरा पहा आणि टिकून राहा. काही नवीन सेवा लिहिण्याचे कारण म्हणून वापरकर्ता संक्रमणावरील डेटा

ग्राहकांच्या वर्तनाचे विश्लेषण करण्याच्या फायद्यांबद्दल इंटरनेटवर शेकडो लेख आहेत. बहुतेकदा हे रिटेल क्षेत्राशी संबंधित असते. फूड बास्केट विश्लेषण, ABC आणि XYZ विश्लेषणापासून ते धारणा विपणन आणि वैयक्तिक ऑफरपर्यंत. अनेक दशकांपासून विविध तंत्रे वापरली गेली आहेत, अल्गोरिदमचा विचार केला गेला आहे, कोड लिहिला गेला आहे आणि डीबग केला गेला आहे - ते घ्या आणि वापरा. आमच्या बाबतीत, एक मूलभूत समस्या उद्भवली - आम्ही ISPsystem मध्ये सॉफ्टवेअर डेव्हलपमेंटमध्ये गुंतलो आहोत, किरकोळ नाही.
माझे नाव डेनिस आहे आणि मी सध्या ISPsystem मधील विश्लेषणात्मक प्रणालीच्या बॅकएंडसाठी जबाबदार आहे. आणि मी आणि माझा सहकारी कसा होतो याची ही कहाणी आहे डॅनिल — डेटा व्हिज्युअलायझेशनसाठी जबाबदार असलेले — या ज्ञानाच्या प्रिझमद्वारे आमच्या सॉफ्टवेअर उत्पादनांकडे पाहण्याचा प्रयत्न केला. चला, नेहमीप्रमाणे, इतिहासापासून सुरुवात करूया.

सुरुवातीला एक शब्द होता, आणि शब्द होता "आम्ही प्रयत्न करू का?"

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

परंतु आमची बहुतेक उत्पादने होस्टिंग मार्केटला उद्देशून आहेत. हे मोठे ग्राहक आहेत आणि व्यवसाय विकास विभाग त्यांना उत्पादन क्षमतांबद्दल सल्ला देतो. हे देखील अनुसरण करते की खरेदीच्या वेळी, आमच्या ग्राहकांना आधीच माहित आहे की आमचे सॉफ्टवेअर त्यांना कोणत्या समस्या सोडवण्यास मदत करेल. ऍप्लिकेशनमधील त्यांचे मार्ग उत्पादनामध्ये एम्बेड केलेल्या CJM सोबत असणे आवश्यक आहे आणि UX उपाय त्यांना ट्रॅकवर राहण्यास मदत करतील. स्पॉयलर: हे नेहमीच होत नाही. ग्रंथालयाचा परिचय पुढे ढकलण्यात आला... पण फार काळ नाही.

आमच्या स्टार्टअपच्या प्रकाशनासह सर्व काही बदलले - कार्टबी — Instagram खात्यावरून ऑनलाइन स्टोअर तयार करण्यासाठी प्लॅटफॉर्म. या ऍप्लिकेशनमध्ये, वापरकर्त्याला सर्व कार्यक्षमता विनामूल्य वापरण्यासाठी दोन आठवड्यांचा कालावधी देण्यात आला होता. मग सदस्यत्व घ्यायचे की नाही हे ठरवायचे होते. आणि हे "मार्ग-लक्ष्य कृती" संकल्पनेत पूर्णपणे बसते. हे ठरले: चला प्रयत्न करूया!

प्रथम परिणाम किंवा कल्पना कुठून मिळवायची

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

संक्रमण आलेख. मूलभूत कार्यक्षमता, स्पष्टतेसाठी इतर संक्रमणे काढली

हे उदाहरणाप्रमाणेच बाहेर वळले: प्लॅनर, स्पष्ट, सुंदर. या आलेखावरून, आम्ही सर्वाधिक वारंवार जाणारे मार्ग आणि क्रॉसिंग ओळखण्यात सक्षम होतो जिथे लोक सर्वाधिक वेळ घालवतात. हे आम्हाला खालील गोष्टी समजून घेण्यास अनुमती देते:

• एका मोठ्या CJM ऐवजी, ज्यामध्ये डझनभर घटक समाविष्ट आहेत, फक्त दोन सक्रियपणे वापरले जातात. UX सोल्यूशन्स वापरून आम्हाला आवश्यक असलेल्या ठिकाणी वापरकर्त्यांना निर्देशित करणे देखील आवश्यक आहे.
• काही पृष्ठे, UX डिझायनर्सनी एंड-टू-एंड अशी डिझाइन केलेली असतात, लोक त्यावर अवास्तव वेळ घालवतात. तुम्हाला विशिष्ट पृष्ठावर स्टॉप घटक कोणते आहेत हे शोधून काढणे आणि ते समायोजित करणे आवश्यक आहे.
• 10 संक्रमणांनंतर, 20% लोक थकले आणि अनुप्रयोगातील सत्र सोडू लागले. आणि हे लक्षात घेत आहे की आमच्याकडे अर्जामध्ये तब्बल 5 ऑनबोर्डिंग पृष्ठे होती! तुम्हाला अशी पृष्ठे ओळखण्याची आवश्यकता आहे जिथे वापरकर्ते नियमितपणे सत्रे सोडून देतात आणि त्यांचा मार्ग लहान करतात. आणखी चांगले: कोणतेही नियमित मार्ग ओळखा आणि स्त्रोत पृष्ठावरून गंतव्य पृष्ठावर द्रुत संक्रमणास अनुमती द्या. एबीसी विश्लेषण आणि सोडलेल्या कार्ट विश्लेषणामध्ये काहीतरी साम्य आहे, तुम्हाला वाटत नाही का?

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

निराशा आणि प्रेरणा बद्दल

निराशा #1

तो कामाच्या दिवसाचा शेवट, महिन्याचा शेवट आणि त्याच वेळी वर्षाचा शेवट होता - 27 डिसेंबर. डेटा जमा झाला आहे, शंका लिहिल्या गेल्या आहेत. सर्वकाही प्रक्रिया होण्यापूर्वी काही सेकंद शिल्लक होते आणि पुढील कामकाजाचे वर्ष कोठे सुरू होईल हे शोधण्यासाठी आम्ही आमच्या श्रमांचे परिणाम पाहू शकतो. R&D विभाग, उत्पादन व्यवस्थापक, UX डिझायनर्स, टीम लीड, डेव्हलपर त्यांच्या उत्पादनामध्ये वापरकर्ता मार्ग कसा दिसतो हे पाहण्यासाठी मॉनिटरसमोर जमले, पण... आम्ही हे पाहिले:

रिटेन्शनियरिंग लायब्ररीद्वारे तयार केलेला संक्रमण आलेख

प्रेरणा #1

जोरदारपणे कनेक्ट केलेले, डझनभर संस्था, स्पष्ट नसलेली परिस्थिती. हे फक्त स्पष्ट होते की नवीन कामकाजाचे वर्ष विश्लेषणाने नव्हे तर अशा आलेखासह काम सुलभ करण्याच्या मार्गाच्या शोधाने सुरू होईल. पण सर्व काही दिसते त्यापेक्षा सोपे आहे ही भावना मी हलवू शकलो नाही. आणि रिटेन्शनियरिंग सोर्स कोडचा पंधरा मिनिटांचा अभ्यास केल्यानंतर, आम्ही तयार केलेला आलेख डॉट फॉरमॅटमध्ये एक्सपोर्ट करू शकलो. यामुळे आलेख दुसर्‍या टूलवर अपलोड करणे शक्य झाले - गेफी. आणि आलेखांचे विश्लेषण करण्यासाठी आधीच वाव आहे: मांडणी, फिल्टर, आकडेवारी - तुम्हाला फक्त इंटरफेसमध्ये आवश्यक पॅरामीटर्स कॉन्फिगर करायचे आहेत. हा विचार मनात घेऊन आम्ही नवीन वर्षाच्या वीकेंडला निघालो.

निराशा #2

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

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

/host/item/24/ip(modal:modal/host/item/ip/create)

म्हणजे “IP पत्ते” पृष्ठावर वापरकर्त्याने IP पत्ता जोडला आहे. आणि येथे दोन समस्या एकाच वेळी दृश्यमान आहेत:

• URL मध्ये काही प्रकारचे पथ पॅरामीटर असते - व्हर्च्युअल मशीनचा ID. ते वगळण्याची गरज आहे.
• URL मध्ये मॉडेल विंडो आयडी आहे. तुम्हाला अशा URLs कसे तरी "अनपॅक" करावे लागतील.
  दुसरी समस्या अशी होती की आम्ही चिन्हांकित केलेल्या घटनांमध्ये पॅरामीटर्स होते. उदाहरणार्थ, सूचीमधून व्हर्च्युअल मशीनबद्दल माहितीसह पृष्ठावर जाण्याचे पाच भिन्न मार्ग होते. त्यानुसार, एक इव्हेंट पाठविला गेला, परंतु वापरकर्त्याने कोणत्या पद्धतीद्वारे संक्रमण केले हे दर्शविणारे पॅरामीटरसह. अशा अनेक घटना होत्या, आणि सर्व पॅरामीटर्स भिन्न होते. आणि आमच्याकडे क्लिकहाऊससाठी SQL बोलीमध्ये सर्व डेटा पुनर्प्राप्ती तर्क आहे. 150-200 ओळींचे प्रश्न काहीसे सामान्य वाटू लागले होते. समस्यांनी आम्हाला घेरले.

प्रेरणा #2

एका पहाटे, डॅनिलने दु:खाने दुस-या मिनिटाच्या विनंतीवरून स्क्रोल करत मला सुचवले: "चला डेटा प्रोसेसिंग पाइपलाइन लिहू?" आम्ही याबद्दल विचार केला आणि ठरवले की आम्ही ते करणार आहोत तर ते ईटीएलसारखे काहीतरी असेल. जेणेकरुन ते ताबडतोब फिल्टर करते आणि इतर स्त्रोतांकडून आवश्यक डेटा खेचते. अशाप्रकारे पूर्ण वाढ झालेल्या बॅकएंडसह आमची पहिली विश्लेषणात्मक सेवा जन्माला आली. हे डेटा प्रोसेसिंगचे पाच मुख्य टप्पे लागू करते:

1. कच्च्या डेटा स्टोरेजमधून इव्हेंट्स अनलोड करणे आणि त्यांना प्रक्रियेसाठी तयार करणे.
2. स्पष्टीकरण म्हणजे मॉडेल विंडो, इव्हेंट पॅरामीटर्स आणि इव्हेंटचे स्पष्टीकरण देणारे इतर तपशीलांचे "अनपॅकिंग" करणे.
3. समृद्धी ("श्रीमंत होण्यासाठी" या शब्दापासून) तृतीय-पक्षाच्या स्त्रोतांकडील डेटासह इव्हेंटची भर आहे. त्या वेळी, यात फक्त आमची बिलिंग सिस्टम BILLmanager समाविष्ट होती.
4. फिल्टरिंग ही इव्हेंट फिल्टर करण्याची प्रक्रिया आहे जी विश्लेषणाचे परिणाम विकृत करतात (अंतर्गत स्टँड, आउटलियर इ. इ.).
5. स्टोरेजमध्ये प्राप्त इव्हेंट अपलोड करणे, ज्याला आम्ही क्लीन डेटा म्हणतो.
   आता इव्हेंट किंवा तत्सम इव्हेंटच्या गटांवर प्रक्रिया करण्यासाठी नियम जोडून प्रासंगिकता राखणे शक्य होते. उदाहरणार्थ, तेव्हापासून आम्ही कधीही URL अनपॅकिंग अपडेट केलेले नाही. जरी, या काळात अनेक नवीन URL विविधता जोडल्या गेल्या आहेत. ते सेवेमध्ये आधीच घालून दिलेल्या नियमांचे पालन करतात आणि योग्यरित्या प्रक्रिया केली जातात.

निराशा #3

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

एक छोटीशी चौकशी सुरू झाली. मी गोंधळून गेलो होतो की एका अस्तित्वात कोणतीही अशक्य संक्रमणे नाहीत. याचा अर्थ इव्हेंट कलेक्शन सिस्टम किंवा आमच्या ETL सेवेमध्ये हा दोष नाही. अशी भावना होती की वापरकर्ता एकाच वेळी अनेक संस्थांमध्ये काम करत होता, एकापासून दुसऱ्याकडे न जाता. हे कसे साध्य करायचे? ब्राउझरमध्ये वेगवेगळे टॅब वापरणे.

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

प्रेरणा #3

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

विश्लेषण ऑटोमेशन

एका परिणाम प्रात्यक्षिकात, आलेख विश्लेषणासाठी गेफीचा वापर कसा केला जातो ते आम्ही दाखवले. या टूलमध्ये, रूपांतरण डेटा टेबलमध्ये प्रदर्शित केला जाऊ शकतो. आणि UX विभागाच्या प्रमुखांनी सांगितले की एक अतिशय महत्त्वाचा विचार ज्याने कंपनीच्या संपूर्ण वर्तन विश्लेषणाच्या दिशानिर्देशाच्या विकासावर प्रभाव टाकला: "चला तेच करू, परंतु झांकी आणि फिल्टरसह - ते अधिक सोयीस्कर होईल."

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

हे व्हिज्युअलायझेशन कसे वापरले जाते आणि ते कोणते निष्कर्ष काढू देते याबद्दल डॅनिल बोलेल.

टेबल देवासाठी अधिक टेबल!

एका सोप्या स्वरूपात, कार्य खालीलप्रमाणे तयार केले गेले: झांकीमध्ये संक्रमण आलेख प्रदर्शित करा, फिल्टर करण्याची क्षमता प्रदान करा आणि ते शक्य तितके स्पष्ट आणि सोयीस्कर बनवा.

मला टॅबलेओमध्ये निर्देशित आलेख काढायचा नव्हता. आणि जरी यशस्वी झाले तरी, गेफीच्या तुलनेत फायदा स्पष्ट दिसत नव्हता. आम्हाला खूप सोपे आणि अधिक प्रवेश करण्यायोग्य काहीतरी हवे होते. टेबल! शेवटी, आलेख सहजपणे सारणी पंक्तीच्या रूपात दर्शविले जाऊ शकते, जेथे प्रत्येक पंक्ती "स्रोत-गंतव्य" प्रकाराची एक किनार आहे. शिवाय, आम्ही अशा प्रकारचे टेबल रिटेन्शनियरिंग आणि डेटा प्रोव्हायडर टूल्स वापरून आधीच काळजीपूर्वक तयार केले आहे. फक्त टेबलाला टेबलाओमध्ये दाखवणे आणि अहवालाद्वारे रॅमेज करणे बाकी होते.

प्रत्येकाला टेबल कसे आवडते याबद्दल बोलणे.

तथापि, येथे आपल्याला आणखी एका समस्येचा सामना करावा लागतो. डेटा स्त्रोताचे काय करावे? pandas.DataFrame कनेक्ट करणे अशक्य होते; Tableau मध्ये असा कनेक्टर नाही. आलेख संचयित करण्यासाठी एक स्वतंत्र आधार वाढवणे हे अस्पष्ट संभाव्यतेसह खूप मूलगामी समाधान वाटले. आणि सतत मॅन्युअल ऑपरेशन्सच्या गरजेमुळे स्थानिक अनलोडिंग पर्याय योग्य नव्हते. आम्ही उपलब्ध कनेक्टरची यादी पाहिली आणि आमची नजर त्या वस्तूवर पडली वेब डेटा कनेक्टर, जो अत्यंत तळाशी निराधारपणे अडकला होता.

झांकीमध्ये कनेक्टर्सची समृद्ध निवड आहे. आम्हाला आमच्या समस्येचे निराकरण करणारा एक सापडला

कोणत्या प्रकारचे प्राणी? ब्राउझरमध्ये काही नवीन उघडे टॅब - आणि हे स्पष्ट झाले की हे कनेक्टर तुम्हाला URL मध्ये प्रवेश करताना डेटा प्राप्त करण्यास अनुमती देते. डेटाची गणना करण्यासाठी बॅकएंड जवळजवळ तयार होता, फक्त ते WDC शी मैत्री करणे बाकी होते. बरेच दिवस डेनिसने दस्तऐवजीकरणाचा अभ्यास केला आणि टॅब्यू यंत्रणेशी लढा दिला आणि नंतर मला एक लिंक पाठवली जी मी कनेक्शन विंडोमध्ये पेस्ट केली.

आमच्या WDC ला कनेक्शन फॉर्म. डेनिसने आपला मोर्चा काढला आणि सुरक्षिततेची काळजी घेतली

काही मिनिटांच्या प्रतीक्षेनंतर (विनंती केल्यावर डेटा डायनॅमिकपणे मोजला जातो), टेबल दिसला:

टेबलाऊ इंटरफेसमध्ये रॉ डेटा अॅरे असे दिसते

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

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

सामान्यतः, डेटाचे विश्लेषण करताना, एखाद्या व्यक्तीला प्रश्नांची उत्तरे मिळवायची असतात. मस्त. चला त्यांच्यापासून सुरुवात करूया.

• सर्वात वारंवार होणारी संक्रमणे कोणती आहेत?
• ते विशिष्ट पृष्ठांवरून कोठे जातात?
• निघण्यापूर्वी तुम्ही या पृष्ठावर सरासरी किती वेळ घालवता?
• तुम्ही A ते B मध्ये किती वेळा संक्रमण करता?
• सत्र कोणत्या पृष्ठांवर समाप्त होते?

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

आम्हाला काय मिळाले?

लोक बहुतेकदा डॅशबोर्डवरून कुठे वळतात?

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

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

क्लस्टरच्या यादीत ते कोठून येतात?

अहवालातील फिल्टर्स दोन्ही दिशांनी काम करतात: तुम्ही कुठे सोडले किंवा तुम्ही कुठे गेलात हे शोधू शकता

उदाहरणांवरून हे स्पष्ट आहे की दोन सोप्या फिल्टर्सची उपस्थिती आणि मूल्यांनुसार रँकिंग पंक्ती देखील आपल्याला त्वरीत माहिती प्राप्त करण्यास अनुमती देतात.

अजून अवघड काहीतरी विचारूया.

वापरकर्ते त्यांचे सत्र कोठे सोडून देतात?

VMmanager वापरकर्ते अनेकदा स्वतंत्र टॅबमध्ये काम करतात

हे करण्यासाठी, आम्हाला एका अहवालाची आवश्यकता आहे ज्याचा डेटा संदर्भ स्त्रोतांद्वारे एकत्रित केला जातो. आणि तथाकथित ब्रेकपॉईंट्स असाइनमेंट म्हणून घेतले गेले - अशा घटना ज्याने संक्रमणाच्या साखळीचा शेवट केला.

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

जेव्हा आम्ही अशाच प्रकारे विश्लेषण केले तेव्हा आम्ही सर्वप्रथम या अहवालांची उपयुक्तता स्वतःवर तपासली. Vepp, आमची दुसरी उत्पादने. टेबल्स आणि फिल्टर्सच्या आगमनाने, गृहीतकांची जलद चाचणी झाली आणि डोळे कमी थकले.

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

सारणी खूप मोठी होती, परंतु आम्हाला आशा आहे की ते वाचण्यासारखे थांबले नाही

आमच्या अंतर्गत ग्राहकांच्या प्रशिक्षणाबद्दल स्वतंत्रपणे उल्लेख करणे योग्य आहे: उत्पादन विशेषज्ञ आणि UX डिझाइनर. विश्लेषणाची उदाहरणे आणि फिल्टरसह काम करण्याच्या टिपांसह मॅन्युअल विशेषतः त्यांच्यासाठी तयार केले होते. आम्‍ही थेट अहवाल पृष्‍ठांवर मॅन्युअलच्‍या लिंक घातल्‍या.

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

ऐवजी उपखंडाऐवजी

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

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

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