Ինտերնետում կան հարյուրավոր հոդվածներ հաճախորդների վարքագծի վերլուծության առավելությունների մասին: Ամենից հաճախ դա վերաբերում է մանրածախ առևտրի ոլորտին։ Սննդի զամբյուղի վերլուծությունից, ABC և XYZ վերլուծությունից մինչև պահպանման մարքեթինգ և անձնական առաջարկներ: Տարբեր տեխնիկա են օգտագործվել տասնամյակներ շարունակ, ալգորիթմները մշակվել են, ծածկագիրը գրվել և կարգաբերվել է՝ վերցրե՛ք այն և օգտագործե՛ք այն: Մեր դեպքում առաջացավ մեկ հիմնարար խնդիր՝ մենք ISPsystem-ում զբաղվում ենք ոչ թե մանրածախ, այլ ծրագրային ապահովման մշակմամբ։
Իմ անունը Դենիս է, և ես ներկայումս պատասխանատու եմ ISPsystem-ի վերլուծական համակարգերի հետին պլանի համար: Եվ սա այն պատմությունն է, թե ինչպես ես և իմ գործընկերը — տվյալների վիզուալիզացիայի համար պատասխանատուները — փորձեցին մեր ծրագրային արտադրանքներին նայել այս գիտելիքի պրիզմայով: Սկսենք, ինչպես միշտ, պատմությունից։
Սկզբում մի բառ կար, և խոսքը՝ «Փորձե՞նք»:
Այդ պահին ես աշխատում էի որպես ծրագրավորող R&D բաժնում։ Ամեն ինչ սկսվեց, երբ Դանիլը կարդաց այստեղ Habré-ում — հավելվածներում օգտագործողների անցումները վերլուծելու գործիք: Ես որոշ չափով թերահավատ էի այն այստեղ օգտագործելու գաղափարին: Որպես օրինակ՝ գրադարանի մշակողները մեջբերեցին հավելվածների վերլուծություն, որտեղ հստակ սահմանված էր նպատակային գործողությունը՝ պատվեր կատարելը կամ սեփականատեր ընկերությանը վճարելու այլ տարբերակ: Մեր արտադրանքը մատակարարվում է տեղում: Այսինքն՝ օգտատերը նախ գնում է լիցենզիա, և միայն դրանից հետո սկսում իր ճանապարհորդությունը հավելվածում։ Այո, մենք ունենք ցուցադրական տարբերակներ: Դուք կարող եք փորձել ապրանքը այնտեղ, որպեսզի խոզուկ չմնաք:
Բայց մեր արտադրանքի մեծ մասն ուղղված է հոսթինգի շուկային: Սրանք խոշոր հաճախորդներ են, և բիզնեսի զարգացման բաժինը նրանց խորհուրդ է տալիս արտադրանքի հնարավորությունների վերաբերյալ: Դրանից բխում է նաև, որ գնման պահին մեր հաճախորդներն արդեն գիտեն, թե մեր ծրագրաշարը ինչ խնդիրներ կօգնի նրանց լուծել: Հավելվածում նրանց երթուղիները պետք է համընկնեն արտադրանքի մեջ ներկառուցված CJM-ի հետ, և UX լուծումները կօգնեն նրանց մնալ ուղու վրա: Սփոյլեր. սա միշտ չէ, որ տեղի է ունենում: Գրադարանի մուտքը հետաձգվեց... բայց ոչ երկար։
Ամեն ինչ փոխվեց մեր ստարտափի թողարկումով. — Ինստագրամի հաշվից առցանց խանութ ստեղծելու հարթակներ: Այս հավելվածում օգտատիրոջը տրվել է երկշաբաթյա ժամկետ՝ բոլոր գործառույթներն անվճար օգտագործելու համար։ Այնուհետև դուք պետք է որոշեիք, թե արդյոք բաժանորդագրվել: Եվ սա լիովին տեղավորվում է «երթուղի-թիրախ գործողություն» հայեցակարգի մեջ: Որոշվեց՝ փորձենք։
Առաջին արդյունքները կամ որտեղից գաղափարներ ստանալ
Մշակող թիմը և ես ապրանքը միացրինք իրադարձությունների հավաքման համակարգին բառացիորեն մեկ օրում: Անմիջապես կասեմ, որ ISPsystem-ը օգտագործում է իր սեփական համակարգը էջերի այցելությունների մասին իրադարձությունների հավաքագրման համար, բայց ոչինչ չի խանգարում ձեզ նույն նպատակներով օգտագործել Yandex.Metrica-ն, որը թույլ է տալիս անվճար ներբեռնել հումքային տվյալներ։ Ուսումնասիրվել են գրադարանից օգտվելու օրինակներ, և մեկ շաբաթ տվյալների հավաքագրումից հետո մենք ստացել ենք անցումային գրաֆիկ:
Անցումային գրաֆիկ. Հիմնական ֆունկցիոնալությունը, պարզության համար հեռացված այլ անցումներ
Պարզվեց այնպես, ինչպես օրինակում՝ հարթ, պարզ, գեղեցիկ: Այս գրաֆիկից մենք կարողացանք բացահայտել առավել հաճախակի երթուղիներն ու անցումները, որտեղ մարդիկ ամենաերկար ժամանակն են անցկացնում: Սա մեզ թույլ տվեց հասկանալ հետևյալը.
- Խոշոր CJM-ի փոխարեն, որն ընդգրկում է մեկ տասնյակ սուբյեկտ, ակտիվորեն օգտագործվում է միայն երկուսը։ Անհրաժեշտ է լրացուցիչ ուղղորդել օգտատերերին դեպի մեզ անհրաժեշտ վայրեր՝ օգտագործելով UX լուծումները։
- Որոշ էջեր, որոնք նախագծվել են UX դիզայներների կողմից, որպեսզի վերջ-վերջ լինեն, ի վերջո մարդիկ անհիմն ժամանակ են ծախսում դրանց վրա: Դուք պետք է պարզեք, թե ինչ է կանգառի տարրերը կոնկրետ էջում և կարգավորեք այն:
- 10 անցումներից հետո մարդկանց 20%-ը սկսեց հոգնել և դուրս գալ հավելվածի նիստից։ Եվ սա հաշվի առնելով այն փաստը, որ մենք ունեինք մինչև 5 ներբաշային էջ հավելվածում: Դուք պետք է նույնականացնեք այն էջերը, որտեղ օգտատերերը կանոնավոր կերպով հրաժարվում են նիստերից և կրճատում դրանց ճանապարհը: Նույնիսկ ավելի լավ. բացահայտեք ցանկացած կանոնավոր երթուղի և թույլ տվեք արագ անցում սկզբնական էջից դեպի նպատակակետ: Ինչ-որ ընդհանրություն ABC վերլուծության և լքված զամբյուղի վերլուծության հետ, չե՞ք կարծում:
Եվ այստեղ մենք վերանայեցինք մեր վերաբերմունքը այս գործիքի կիրառելիությանը ներքին արտադրանքի համար: Որոշվել է վերլուծել ակտիվորեն վաճառվող և օգտագործված ապրանքը. . Այն շատ ավելի բարդ է, մեծության կարգով ավելի շատ սուբյեկտներ կան: Մենք ոգևորված սպասում էինք տեսնելու, թե ինչպիսին կլինի անցումային գրաֆիկը:
Հիասթափությունների և ոգեշնչումների մասին
Հիասթափություն թիվ 1
Աշխատանքային օրվա ավարտն էր, ամսվա վերջը և տարեվերջը միաժամանակ՝ դեկտեմբերի 27-ը։ Տվյալներ են կուտակվել, հարցումներ են գրվել։ Վայրկյաններ էին մնացել, մինչև ամեն ինչ մշակվեր, և մենք կարող էինք նայել մեր աշխատանքի արդյունքին՝ պարզելու, թե որտեղ է սկսվելու հաջորդ աշխատանքային տարին: R&D բաժինը, արտադրանքի մենեջերը, UX դիզայներները, թիմի ղեկավարը, ծրագրավորողները հավաքվել էին մոնիտորի առջև՝ տեսնելու, թե ինչ տեսք ունեն օգտատերերի ուղիները իրենց արտադրանքում, բայց... մենք տեսանք սա.
Անցումային գրաֆիկ, որը կառուցվել է Retentioneering գրադարանի կողմից
Ոգեշնչում #1
Խիստ կապված, տասնյակ սուբյեկտներ, ոչ ակնհայտ սցենարներ։ Պարզ էր միայն, որ նոր աշխատանքային տարին սկսվելու է ոչ թե վերլուծությամբ, այլ նման գրաֆիկով աշխատանքը պարզեցնելու միջոցի գյուտով։ Բայց ես չէի կարող զսպել այն զգացումը, որ ամեն ինչ շատ ավելի պարզ էր, քան թվում էր: Եվ տասնհինգ րոպե ուսումնասիրելուց հետո Retaineering սկզբնական կոդը, մենք կարողացանք արտահանել կառուցված գրաֆիկը կետային ձևաչափի: Սա հնարավորություն տվեց ներբեռնել գրաֆիկը մեկ այլ գործիքի վրա՝ Gephi: Եվ արդեն կա գրաֆիկների վերլուծության հնարավորություն՝ դասավորություններ, ֆիլտրեր, վիճակագրություն. այն ամենը, ինչ դուք պետք է անեք, ինտերֆեյսի մեջ անհրաժեշտ պարամետրերի կարգավորումն է: Այս մտքով մեկնեցինք Ամանորի շաբաթավերջին։
Հիասթափություն թիվ 2
Աշխատանքի վերադառնալուց հետո պարզվեց, որ մինչ բոլորը հանգստանում էին, մեր հաճախորդներն ուսումնասիրում էին ապրանքը։ Այո, այնքան ծանր, որ պահեստում հայտնվեցին իրադարձություններ, որոնք նախկինում գոյություն չունեին։ Սա նշանակում էր, որ հարցումները պետք է թարմացվեին:
Մի փոքր նախապատմություն՝ հասկանալու այս փաստի տխուրությունը։ Մենք փոխանցում ենք և՛ այն իրադարձությունները, որոնք մենք նշել ենք (օրինակ՝ կտտացնում ենք որոշ կոճակների վրա), և՛ այն էջերի URL-ները, որոնք օգտատերը այցելել է։ Cartbee-ի դեպքում գործեց «մեկ գործողություն - մեկ էջ» մոդելը։ Բայց VMmanager-ի դեպքում իրավիճակը բոլորովին այլ էր՝ մի էջի վրա կարող էին բացվել մի քանի մոդալ պատուհան։ Դրանցում օգտատերը կարող էր լուծել տարբեր խնդիրներ։ Օրինակ, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
նշանակում է, որ «IP հասցեներ» էջում օգտատերը ավելացրել է IP հասցե: Եվ այստեղ միանգամից երկու խնդիր է երևում.
- URL-ը պարունակում է ինչ-որ ուղու պարամետր՝ վիրտուալ մեքենայի ID-ն: Պետք է բացառել։
- URL-ը պարունակում է մոդալ պատուհանի ID-ն: Դուք պետք է ինչ-որ կերպ «փաթեթավորեք» նման URL-ները:
Մյուս խնդիրն այն էր, որ հենց այն իրադարձությունները, որոնք մենք նշել ենք, ունեին պարամետրեր։ Օրինակ, ցանկից վիրտուալ մեքենայի մասին տեղեկություններով էջին հասնելու հինգ տարբեր եղանակ կար: Համապատասխանաբար, ուղարկվել է մեկ իրադարձություն, բայց պարամետրով, որը ցույց է տալիս, թե որ մեթոդով է օգտատերը կատարել անցումը: Նման միջոցառումները շատ էին, և բոլոր պարամետրերը տարբեր էին։ Եվ մենք ունենք տվյալների որոնման ողջ տրամաբանությունը SQL բարբառով Clickhouse-ի համար: 150-200 տողերի հարցումները սկսեցին սովորական թվալ: Խնդիրները շրջապատեցին մեզ։
Ոգեշնչում #2
Մի վաղ առավոտ Դանիլը, երկրորդ րոպեի համար տխուր թերթելով հարցումը, առաջարկեց ինձ. Մենք մտածեցինք և որոշեցինք, որ եթե դա անելու ենք, ապա դա կլինի ETL-ի նման մի բան: Որպեսզի այն անմիջապես զտվի և անհրաժեշտ տվյալները վերցնի այլ աղբյուրներից: Ահա թե ինչպես ծնվեց մեր առաջին վերլուծական ծառայությունը լիարժեք բեքենդով։ Այն իրականացնում է տվյալների մշակման հինգ հիմնական փուլեր.
- Իրադարձությունների բեռնաթափում չմշակված տվյալների պահեստից և պատրաստում դրանք մշակման:
- Հստակեցումը մոդալ պատուհանների, իրադարձության պարամետրերի և այլ մանրամասների հենց այդ նույնացուցիչների «ապափաթեթավորումն» է, որոնք պարզաբանում են իրադարձությունը:
- Հարստացումը («հարստանալ» բառից) իրադարձությունների ավելացում է երրորդ կողմի աղբյուրներից ստացված տվյալների հետ: Այն ժամանակ սա ներառում էր միայն մեր բիլինգի համակարգը՝ BILLmanager-ը:
- Զտումը վերլուծության արդյունքները խեղաթյուրող իրադարձությունների զտման գործընթացն է (միջոցառումներ ներքին դիրքերից, արտաքուստ և այլն):
- Ստացված իրադարձությունների բեռնումը պահեստում, որը մենք անվանեցինք մաքուր տվյալներ:
Այժմ հնարավոր եղավ պահպանել արդիականությունը՝ ավելացնելով իրադարձության կամ նույնիսկ նմանատիպ իրադարձությունների խմբերի մշակման կանոններ: Օրինակ, դրանից հետո մենք երբեք չենք թարմացրել URL-ի ապափաթեթավորումը: Չնայած այս ընթացքում ավելացվել են URL-ի մի քանի նոր տարբերակներ։ Դրանք համապատասխանում են ծառայությունում արդեն իսկ սահմանված կանոններին և ճիշտ են մշակվում:
Հիասթափություն թիվ 3
Երբ սկսեցինք վերլուծել, հասկացանք, թե ինչու է գրաֆիկն այդքան համահունչ: Փաստն այն է, որ գրեթե յուրաքանչյուր N-գրամ պարունակում էր անցումներ, որոնք հնարավոր չէ իրականացնել ինտերֆեյսի միջոցով:
Սկսվեց փոքրիկ հետաքննություն. Ես շփոթված էի, որ մեկ էության ներսում անհնարին անցումներ չեն եղել: Սա նշանակում է, որ սա իրադարձությունների հավաքագրման համակարգում կամ մեր ETL ծառայության սխալ չէ: Զգացողություն կար, որ օգտատերը միաժամանակ աշխատում է մի քանի սուբյեկտներում՝ առանց մեկից մյուսը անցնելու։ Ինչպե՞ս հասնել դրան: Օգտագործելով տարբեր ներդիրներ բրաուզերում:
Cartbee-ն վերլուծելիս մեզ փրկեց նրա առանձնահատկությունը։ Հավելվածն օգտագործվել է բջջային սարքերից, որտեղ մի քանի ներդիրներից աշխատելն ուղղակի անհարմար է։ Այստեղ մենք ունենք աշխատասեղան, և մինչ առաջադրանքը կատարվում է մի կազմակերպությունում, խելամիտ է ցանկանալ այս ժամանակը ծախսել մեկ այլ կազմակերպությունում կարգավիճակը կարգավորելու կամ վերահսկելու վրա: Իսկ առաջընթացը չկորցնելու համար պարզապես բացեք մեկ այլ ներդիր։
Ոգեշնչում #3
Front-end-ի մշակման գործընկերները միջոցառումների հավաքման համակարգին սովորեցրել են տարբերակել ներդիրները: Վերլուծությունը կարող է սկսվել։ Եվ մենք սկսեցինք. Ինչպես և սպասվում էր, CJM-ը չէր համընկնում իրական ուղիների հետ. օգտատերերը շատ ժամանակ էին ծախսում գրացուցակի էջերում, լքված նիստերին և ներդիրներին ամենաանսպասելի վայրերում: Օգտագործելով անցումային վերլուծություն՝ մենք կարողացանք խնդիրներ գտնել Mozilla-ի որոշ կառուցվածքներում: Դրանցում իրականացման հնարավորությունների պատճառով անհետացել են նավիգացիոն տարրերը կամ ցուցադրվել են կիսադատարկ էջեր, որոնք պետք է հասանելի լինեն միայն ադմինիստրատորին։ Էջը բացվեց, բայց հետնամասից բովանդակություն չկար: Հաշվիչ անցումները հնարավորություն տվեցին գնահատել, թե որ հատկանիշներն են իրականում օգտագործվել: Շղթաները հնարավորություն են տվել հասկանալ, թե ինչպես է օգտատերը ստացել այս կամ այն սխալը։ Տվյալները թույլ են տալիս փորձարկել՝ հիմնված օգտագործողի վարքագծի վրա: Հաջողություն էր, գաղափարն իզուր չէր։
Վերլուծության ավտոմատացում
Արդյունքներից մեկում մենք ցույց տվեցինք, թե ինչպես է Gephi-ն օգտագործվում գրաֆիկների վերլուծության համար: Այս գործիքում փոխակերպման տվյալները կարող են ցուցադրվել աղյուսակում: Իսկ UX բաժնի ղեկավարն ասաց մի շատ կարևոր միտք, որն ազդեց ընկերությունում վարքագծի վերլուծության ողջ ուղղության զարգացման վրա.
Հետո մտածեցի. ինչու ոչ, Retentioneering-ը պահում է բոլոր տվյալները pandas.DataFrame կառուցվածքում: Եվ սա, մեծ հաշվով, սեղան է։ Այսպես հայտնվեց մեկ այլ ծառայություն՝ Data Provider։ Նա ոչ միայն աղյուսակ է կազմել գրաֆիկից, այլև հաշվարկել է, թե որքան հայտնի է էջը և դրա հետ կապված ֆունկցիոնալությունը, ինչպես է դա ազդում օգտատերերի պահպանման վրա, որքան ժամանակ են օգտատերերը մնում դրանում և որ էջերից են օգտվողներն առավել հաճախ թողնում: Եվ Tableau-ում վիզուալիզացիայի օգտագործումը այնքան նվազեցրեց գրաֆիկի ուսումնասիրության ծախսերը, որ արտադրանքում վարքագծի վերլուծության կրկնության ժամանակը գրեթե կրկնակի կրճատվեց:
Դանիլը կխոսի այն մասին, թե ինչպես է օգտագործվում այս վիզուալացումը և ինչ եզրակացություններ է թույլ տալիս անել:
Ավելի շատ սեղաններ սեղանի Աստծո համար:
Պարզեցված ձևով առաջադրանքը ձևակերպվել է հետևյալ կերպ. ցուցադրել անցումային գրաֆիկը Tableau-ում, ապահովել զտելու հնարավորություն և դարձնել այն հնարավորինս պարզ և հարմար:
Ես իսկապես չէի ուզում Tableau-ում ուղղորդված գրաֆիկ նկարել: Եվ նույնիսկ եթե հաջողակ, ապա շահույթը, համեմատած Գեփիի հետ, ակնհայտ չէր թվում: Մեզ շատ ավելի պարզ և մատչելի բան էր պետք։ Սեղան! Ի վերջո, գրաֆիկը հեշտությամբ կարելի է ներկայացնել աղյուսակի տողերի տեսքով, որտեղ յուրաքանչյուր տող «աղբյուր-նպատակակետ» տեսակի եզր է: Ավելին, մենք արդեն խնամքով պատրաստել ենք նման աղյուսակ՝ օգտագործելով Retentioneering և Data Provider գործիքները։ Մնում էր միայն աղյուսակը ցուցադրել Tableau-ում և թերթել զեկույցը:
Խոսելով այն մասին, թե ինչպես են բոլորը սիրում սեղանները:
Սակայն այստեղ մենք կանգնած ենք մեկ այլ խնդրի առաջ. Ի՞նչ անել տվյալների աղբյուրի հետ: Անհնար էր միացնել pandas.DataFrame-ը, Tableau-ն նման միակցիչ չունի: Գրաֆիկը պահելու համար առանձին բազա բարձրացնելը չափազանց արմատական լուծում էր թվում՝ անորոշ հեռանկարներով: Իսկ տեղական բեռնաթափման տարբերակները հարմար չէին՝ մշտական ձեռքով գործառնությունների անհրաժեշտության պատճառով: Մենք նայեցինք հասանելի միակցիչների ցանկը, և մեր հայացքն ընկավ իրի վրա , որը տխուր կծկվել էր հենց ներքևում։
Tableau-ն ունի միակցիչների հարուստ ընտրություն: Մենք գտանք մեկը, որը լուծեց մեր խնդիրը
Ինչպիսի՞ կենդանի։ Բրաուզերում մի քանի նոր բաց ներդիրներ - և պարզ դարձավ, որ այս միակցիչը թույլ է տալիս ստանալ տվյալներ URL մուտք գործելու ժամանակ: Ինքնին տվյալների հաշվարկման հետնամասը գրեթե պատրաստ էր, մնում էր այն ընկերանալ WDC-ի հետ։ Մի քանի օր Դենիսը ուսումնասիրեց փաստաթղթերը և կռվեց Tableau մեխանիզմների հետ, իսկ հետո ինձ ուղարկեց հղում, որը ես տեղադրեցի միացման պատուհանում:
Միացման ձև մեր WDC-ին: Դենիսը պատրաստեց իր ճակատը և հոգ տարավ անվտանգության մասին
Մի քանի րոպե սպասելուց հետո (տվյալները հաշվարկվում են դինամիկ կերպով, երբ պահանջվում է), հայտնվեց աղյուսակը.
Ահա թե ինչ տեսք ունի չմշակված տվյալների զանգվածը Tableau ինտերֆեյսում
Ինչպես խոստացվել էր, նման աղյուսակի յուրաքանչյուր տող ներկայացնում էր գրաֆիկի եզրը, այսինքն՝ օգտագործողի ուղղորդված անցումը: Այն նաև պարունակում էր մի քանի լրացուցիչ բնութագրեր. Օրինակ՝ եզակի օգտագործողների թիվը, անցումների ընդհանուր թիվը և այլն։
Հաշվետվության մեջ այս աղյուսակը հնարավոր կլինի ցուցադրել այնպես, ինչպես կա, առատորեն շաղ տալ ֆիլտրերը և գործիքը ուղարկել նավարկության: Տրամաբանական է հնչում. Ի՞նչ կարող ես անել սեղանի հետ: Բայց սա մեր ճանապարհը չէ, քանի որ մենք պատրաստում ենք ոչ թե պարզապես աղյուսակ, այլ գործիք վերլուծության և արտադրանքի վերաբերյալ որոշումներ կայացնելու համար:
Սովորաբար, տվյալներ վերլուծելիս մարդը ցանկանում է հարցերի պատասխաններ ստանալ: Հիանալի: Սկսենք նրանցից:
- Որո՞նք են առավել հաճախակի անցումները:
- Որտեղ են նրանք գնում կոնկրետ էջերից:
- Միջին հաշվով որքա՞ն ժամանակ եք ծախսում այս էջում մեկնելուց առաջ:
- Որքա՞ն հաճախ եք անցում կատարում A-ից B-ին:
- Ո՞ր էջերում է ավարտվում նիստը:
Զեկույցներից յուրաքանչյուրը կամ դրանց համակցությունը պետք է օգտագործողին հնարավորություն տա ինքնուրույն գտնել այս հարցերի պատասխանները: Այստեղ հիմնական ռազմավարությունն այն է, որ ձեզ գործիքներ տա դա ինքներդ անելու համար: Սա օգտակար է ինչպես վերլուծության բաժնի բեռը նվազեցնելու, այնպես էլ որոշումներ կայացնելու ժամանակը կրճատելու համար. ի վերջո, դուք այլևս կարիք չունեք գնալ Youtrack և առաջադրանք ստեղծել վերլուծաբանի համար, պարզապես անհրաժեշտ է բացել զեկույցը:
Ի՞նչ ստացանք։
Որտե՞ղ են մարդիկ ամենից հաճախ շեղվում վահանակից:
Հատված մեր զեկույցից. Վահանակի վահանակից հետո բոլորը գնացին կա՛մ VM-ների, կա՛մ հանգույցների ցանկ
Վերցնենք ընդհանուր աղյուսակ՝ անցումներով և զտել ըստ աղբյուրի էջին: Ամենից հաճախ դրանք վահանակից անցնում են վիրտուալ մեքենաների ցանկին: Ավելին, Regularity սյունակը հուշում է, որ սա կրկնվող գործողություն է:
Որտեղի՞ց են նրանք գալիս կլաստերների ցանկում:
Հաշվետվությունների զտիչներն աշխատում են երկու ուղղությամբ՝ կարող եք պարզել, թե որտեղ եք գնացել կամ ուր եք գնացել
Օրինակներից պարզ է դառնում, որ նույնիսկ երկու պարզ զտիչների առկայությունը և ըստ արժեքների դասակարգման տողերը թույլ են տալիս արագ տեղեկատվություն ստանալ:
Եկեք ավելի բարդ բան հարցնենք.
Որտե՞ղ են օգտվողներն ամենից հաճախ թողնում իրենց նիստը:
VMmanager-ի օգտատերերը հաճախ աշխատում են առանձին ներդիրներում
Դա անելու համար մեզ անհրաժեշտ է հաշվետվություն, որի տվյալները համախմբված են ուղղորդման աղբյուրներով: Եվ այսպես կոչված բեկման կետերը վերցվեցին որպես հանձնարարություններ՝ իրադարձություններ, որոնք ծառայեցին որպես անցումների շղթայի վերջ:
Այստեղ կարևոր է նշել, որ դա կարող է լինել կա՛մ նիստի ավարտ, կա՛մ նոր ներդիրի բացում: Օրինակը ցույց է տալիս, որ շղթան ամենից հաճախ ավարտվում է վիրտուալ մեքենաների ցանկով աղյուսակով: Այս դեպքում բնորոշ վարքագիծը անցնում է մեկ այլ ներդիրի, որը համապատասխանում է ակնկալվող օրինաչափությանը:
Այս զեկույցների օգտակարությունը մենք առաջին հերթին փորձեցինք ինքներս մեզ վրա, երբ վերլուծությունն իրականացրինք նույն ձևով , մեր մեկ այլ ապրանք: Սեղանների և ֆիլտրերի հայտնվելով վարկածներն ավելի արագ էին փորձարկվում, և աչքերը ավելի քիչ էին հոգնում:
Հաշվետվություններ մշակելիս մենք չմոռացանք վիզուալ դիզայնի մասին։ Այս չափի սեղանների հետ աշխատելիս սա կարևոր գործոն է: Օրինակ՝ մենք օգտագործել ենք գույների հանգիստ տիրույթ, հեշտ ընկալելի թվերի համար՝ գծերի գունային ընդգծումը՝ բնութագրերի թվային արժեքներին համապատասխան։ Նման մանրամասները բարելավում են օգտատերերի փորձը և մեծացնում են ընկերության ներսում գործիքի հաջող դուրս գալու հավանականությունը:
Աղյուսակը բավականին ծավալուն է ստացվել, բայց հուսով ենք՝ չի դադարել ընթեռնելի լինել
Առանձին-առանձին հարկ է նշել մեր ներքին հաճախորդների՝ արտադրանքի մասնագետների և UX դիզայներների վերապատրաստման մասին: Նրանց համար հատուկ պատրաստվել են ձեռնարկներ՝ վերլուծության օրինակներով և ֆիլտրերի հետ աշխատելու խորհուրդներով։ Մենք ձեռնարկների հղումները տեղադրեցինք անմիջապես հաշվետվության էջերում:
Մենք ձեռնարկը պատրաստել ենք պարզապես որպես ներկայացում Google Փաստաթղթերում: Tableau գործիքները թույլ են տալիս ցուցադրել վեբ էջերը անմիջապես հաշվետվության աշխատանքային գրքույկի ներսում:
Կատարված բառի փոխարեն
Ի՞նչ է ներքևում: Մենք կարողացանք համեմատաբար արագ և էժան ձեռք բերել ամեն օրվա համար նախատեսված գործիք: Այո, սա հաստատ չի փոխարինում ինքնին գրաֆիկին, սեղմումների ջերմային քարտեզին կամ վեբ դիտիչին: Բայց նման զեկույցները զգալիորեն լրացնում են թվարկված գործիքները և սնուցում են մտքի և նոր արտադրանքի ու միջերեսի վարկածները:
Այս պատմությունը ծառայեց միայն որպես ISP համակարգում վերլուծության զարգացման սկիզբ: Անցած վեց ամիսների ընթացքում հայտնվել են ևս յոթ նոր ծառայություններ, այդ թվում՝ ապրանքի մեջ օգտագործողի թվային դիմանկարները և Look-alike թիրախավորման համար տվյալների շտեմարաններ ստեղծելու ծառայություն, սակայն դրանց մասին մենք կխոսենք հաջորդ դրվագներում:
Source: www.habr.com