Погледнете го вистинското лице на производот и преживејте. Податоци за транзиции на корисници како причина за пишување неколку нови услуги

На интернет има стотици статии за придобивките од анализата на однесувањето на клиентите. Најчесто ова се однесува на малопродажниот сектор. Од анализа на кошница за храна, анализа ABC и XYZ до маркетинг на задржување и лични понуди. Различни техники се користат со децении, алгоритмите се обмислени, кодот е напишан и дебагиран - земете го и употребете го. Во нашиот случај, се појави еден фундаментален проблем - ние во ISPsystem се занимаваме со развој на софтвер, а не со малопродажба.
Моето име е Денис и моментално сум одговорен за задниот дел на аналитичките системи во ISPsystem. И ова е приказната за тоа како јас и мојот колега Данил — оние кои се одговорни за визуелизација на податоците — се обидоа да ги погледнат нашите софтверски производи низ призмата на ова знаење. Да почнеме, како и обично, со историјата.

На почетокот имаше збор, а зборот беше „Да се ​​обидеме?

Во тој момент работев како програмер во одделот за истражување и развој. Сè започна кога Данил прочита овде на Хабре за задржување — алатка за анализа на корисничките транзиции во апликациите. Бев малку скептичен за идејата да го користам овде. Како примери, програмерите на библиотеката наведоа анализа на апликации каде целното дејство беше јасно дефинирано - давање нарачка или некоја друга варијација на начинот на плаќање на компанијата сопственик. Нашите производи се испорачуваат во просториите. Односно, корисникот прво купува лиценца, а дури потоа го започнува своето патување во апликацијата. Да, имаме демо верзии. Можете да го пробате производот таму за да немате свиња во ѕиркање.

Но, повеќето од нашите производи се наменети за хостинг пазарот. Станува збор за големи клиенти, а одделот за развој на бизнисот ги советува за можностите на производот. Исто така, произлегува дека при купувањето, нашите клиенти веќе знаат какви проблеми ќе им помогне нашиот софтвер да ги решат. Нивните правци во апликацијата мора да се совпаѓаат со CJM вградена во производот, а UX решенијата ќе им помогнат да останат на вистинскиот пат. Спојлер: ова не се случува секогаш. Воведувањето во библиотеката беше одложено... но не за долго.

Сè се смени со објавувањето на нашиот стартап - Картби — платформи за создавање онлајн продавница од сметка на Инстаграм. Во оваа апликација, на корисникот му беше даден период од две недели бесплатно да ја користи целата функционалност. Потоа требаше да одлучите дали да се претплатите. И ова совршено се вклопува во концептот „маршрута-целна акција“. Одлучено е: да се обидеме!

Први резултати или од каде да добиете идеи

Развојниот тим и јас го поврзавме производот со системот за собирање настани буквално за еден ден. Веднаш ќе кажам дека ISPsystem користи свој систем за собирање настани за посети на страници, но ништо не ве спречува да користите Yandex.Metrica за истите цели, што ви овозможува бесплатно преземање необработени податоци. Беа проучувани примери за користење на библиотеката и по една недела собирање податоци добивме графикон за транзиција.

График на транзиција. Основна функционалност, други транзиции отстранети за јасност

Испадна исто како во примерот: рамно, јасно, убаво. Од овој графикон, успеавме да ги идентификуваме најфреквентните рути и премини каде луѓето поминуваат најдолго време. Ова ни овозможи да го разбереме следново:

• Наместо големо СЈМ, кое опфаќа десетина субјекти, активно се користат само два. Потребно е дополнително да ги насочиме корисниците на местата што ни се потребни користејќи UX решенија.
• Некои страници, дизајнирани од дизајнери на UX за да бидат од крај до крај, завршуваат со луѓе кои трошат неразумно време на нив. Треба да откриете кои се стоп елементите на одредена страница и да ги прилагодите.
• По 10 транзиции, 20% од луѓето почнаа да се уморуваат и да ја напуштат сесијата во апликацијата. И ова земајќи го предвид фактот дека имавме дури 5 страници за влез во апликацијата! Треба да ги идентификувате страниците каде што корисниците редовно ги напуштаат сесиите и да го скратите патот до нив. Уште подобро: идентификувајте ги редовните маршрути и овозможете брза транзиција од изворната страница до страницата за дестинација. Нешто заедничко со ABC анализата и анализата на напуштена количка, не мислите?

И тука го преиспитавме нашиот став за применливоста на оваа алатка за производи во просториите. Беше одлучено да се анализира активно продаден и користен производ - VMmanager 6. Тоа е многу покомплексно, има по ред на големина повеќе ентитети. Возбудено чекавме да видиме каков ќе биде графикот на транзиција.

За разочарувањата и инспирациите

Разочарување број 1

Тоа беше крајот на работниот ден, крајот на месецот и крајот на годината во исто време - 27 декември. Акумулирани се податоци, напишани се прашања. Останаа секунди пред сè да се обработи и да го погледнеме резултатот од нашиот труд за да дознаеме каде ќе започне следната работна година. Одделот за истражување и развој, менаџерот на производи, дизајнерите на UX, лидерите на тимот, програмерите се собраа пред мониторот за да видат како изгледаат корисничките патеки во нивниот производ, но... го видовме ова:

График на транзиција изграден од библиотеката Retentioneering

Инспирација број 1

Силно поврзани, десетици ентитети, неочигледни сценарија. Беше јасно само дека новата работна година ќе започне не со анализа, туку со измислување начин да се поедностави работата со таков график. Но, не можев да се откажам од чувството дека сè е многу поедноставно отколку што изгледаше. И по петнаесет минути проучување на изворниот код на Retaineering, можевме да го извеземе конструираниот график во формат на точки. Ова овозможи да се постави графикот на друга алатка - Gephi. И веќе има простор за анализа на графикони: распоред, филтри, статистика - се што треба да направите е да ги конфигурирате потребните параметри во интерфејсот. Со оваа мисла тргнавме на новогодишен викенд.

Разочарување број 2

Откако се вративме на работа, се покажа дека додека сите се одмараа, нашите клиенти го проучуваа производот. Да, толку тешко што се појавија настани во складиштето што претходно не постоеја. Ова значеше дека прашањата треба да се ажурираат.

Мала позадина за да се разбере тагата на овој факт. Ги пренесуваме и настаните што сме ги означиле (на пример, кликнувања на некои копчиња) и URL-адресите на страниците што ги посетил корисникот. Во случајот на Картби, функционираше моделот „една акција - една страница“. Но, со 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. Така што веднаш се филтрира и ги влече потребните податоци од други извори. Вака се роди нашата прва аналитичка услуга со полноправна заднина. Имплементира пет главни фази на обработка на податоци:

1. Растоварување настани од складиштето на необработени податоци и нивно подготвување за обработка.
2. Појаснувањето е „отпакување“ на оние идентификатори на модални прозорци, параметри на настанот и други детали што го разјаснуваат настанот.
3. Збогатување (од зборот „да се стане богат“) е додавање настани со податоци од извори од трети страни. Во тоа време, ова го вклучуваше само нашиот систем за наплата BILLmanager.
4. Филтрирањето е процес на филтрирање на настани кои ги искривуваат резултатите од анализата (настани од внатрешни трибини, оддалечени итн.).
5. Поставување примени настани во складиштето, што го нарековме чисти податоци.
   Сега беше можно да се задржи релевантноста со додавање правила за обработка на настан или дури и групи на слични настани. На пример, оттогаш никогаш не сме го ажурирале распакувањето на URL-то. Иако, за ова време се додадени неколку нови варијации на URL-то. Тие се во согласност со правилата веќе пропишани во услугата и се обработуваат правилно.

Разочарување број 3

Откако почнавме да анализираме, сфативме зошто графикот е толку кохерентен. Факт е дека скоро секој N-грам содржеше транзиции што не можеа да се извршат преку интерфејсот.

Започна мала истрага. Бев збунет дека нема невозможни транзиции во еден ентитет. Ова значи дека ова не е грешка во системот за собирање настани или нашата услуга ETL. Имаше чувство дека корисникот работи истовремено во неколку ентитети, без да се движи од еден во друг. Како да се постигне ова? Користење на различни јазичиња во прелистувачот.

Кога го анализиравме Cartbee, бевме спасени од неговата специфичност. Апликацијата се користеше од мобилни уреди, каде што работата од неколку јазичиња е едноставно незгодно. Овде имаме работна површина и додека задачата се извршува во еден ентитет, разумно е да сакаме да го потрошиме ова време за поставување или следење на статусот во друг. И за да не го изгубите напредокот, само отворете уште еден таб.

Инспирација број 3

Колегите од развојот на предниот дел го научија системот за собирање настани да прави разлика помеѓу картичките. Анализата може да започне. И почнавме. Како што се очекуваше, CJM не одговараше на вистинските патеки: корисниците поминуваа многу време на страници со директориуми, напуштени сесии и јазичиња на најнеочекуваните места. Користејќи анализа на транзиција, успеавме да најдеме проблеми во некои изданија на Mozilla. Во нив, поради карактеристиките на имплементацијата, исчезнаа елементите за навигација или беа прикажани полупразни страници до кои треба да има пристап само администраторот. Страницата се отвори, но нема содржина од задниот дел. Пребројувањето на транзициите овозможи да се процени кои карактеристики всушност биле користени. Синџирите овозможија да се разбере како корисникот ја примил оваа или онаа грешка. Податоците дозволија тестирање врз основа на однесувањето на корисникот. Беше успех, идејата не беше залудна.

Автоматизација на аналитика

Во една од демонстрациите на резултатите, покажавме како Gephi се користи за анализа на графикони. Во оваа алатка, податоците за конверзија може да се прикажат во табела. И шефот на одделот за UX рече една многу важна мисла што влијаеше на развојот на целата насока за анализа на однесувањето во компанијата: „Да го сториме истото, но во Tableau и со филтри - ќе биде поудобно“.

Потоа помислив: зошто да не, Retentioneering ги складира сите податоци во структурата на панди.DataFrame. И ова е, во голема мера, маса. Вака се појави уште еден сервис: Data Provider. Тој не само што направи табела од графиконот, туку пресмета и колку е популарна страницата и функционалноста поврзана со неа, како тоа влијае на задржувањето на корисниците, колку долго корисниците остануваат на неа и кои страници корисниците најчесто ги напуштаат. И употребата на визуелизација во Tableau ги намали трошоците за проучување на графикот толку многу што времето на повторување за анализа на однесувањето во производот беше речиси преполовено.

Данил ќе зборува за тоа како се користи оваа визуелизација и какви заклучоци овозможува да се извлечат.

Повеќе маси за богот на масата!

Во поедноставена форма, задачата беше формулирана на следниов начин: прикажете го графикот на транзиција во Табела, обезбедете можност за филтрирање и направете го што е можно појасно и практично.

Навистина не сакав да цртам насочен графикон во Табло. И дури и ако беше успешна, добивката, во споредба со Гефи, не изгледаше очигледна. Ни требаше нешто многу поедноставно и подостапно. Табела! На крајот на краиштата, графикот може лесно да се претстави во форма на редови на табелата, каде што секој ред е раб од типот „извор-дестинација“. Покрај тоа, ние веќе внимателно подготвивме таква табела користејќи ги алатките Retentioneering и Data Provider. Остануваше само да се прикаже табелата во Табела и да се прочепка низ извештајот.

Зборувајќи за тоа како секој сака маси.

Меѓутоа, овде се соочуваме со друг проблем. Што да се прави со изворот на податоци? Беше невозможно да се поврзат пандите.DataFrame; Tableau нема таков конектор. Подигнувањето на посебна основа за складирање на графикот се чинеше премногу радикално решение со нејасни изгледи. И локалните опции за истовар не беа соодветни поради потребата од постојани рачни операции. Ја разгледавме листата на достапни конектори и погледот ни падна на предметот Веб конектор за податоци, кој ужасно се стутка на самото дно.

Tableau има богат избор на конектори. Најдовме еден што ни го реши проблемот

Какво животно? Неколку нови отворени јазичиња во прелистувачот - и стана јасно дека овој конектор ви овозможува да примате податоци при пристап до URL. Бексендот за пресметување на самите податоци беше речиси готов, остана само да се спријатели со WDC. Денис неколку дена ја проучуваше документацијата и се бореше со механизмите на Tableau, а потоа ми испрати линк што го залепив во прозорецот за поврзување.

Формулар за поврзување со нашиот WDC. Денис го направи својот фронт и се грижеше за безбедноста

По неколку минути чекање (податоците се пресметуваат динамично по барање), се појави табелата:

Вака изгледа низата необработени податоци во интерфејсот Tableau

Како што беше ветено, секој ред од таквата табела претставуваше раб на графикот, односно насочена транзиција на корисникот. Содржеше и неколку дополнителни карактеристики. На пример, бројот на единствени корисници, вкупниот број на транзиции и други.

Би било можно да се прикаже оваа табела во извештајот како што е, великодушно да се попрскаат филтрите и да се испрати алатката да плови. Звучи логично. Што можете да направите со масата? Но, ова не е наш начин, бидејќи не правиме само табела, туку алатка за анализа и донесување одлуки за производот.

Типично, кога се анализираат податоците, едно лице сака да добие одговори на прашања. Одлично. Да почнеме со нив.

• Кои се најчестите транзиции?
• Каде одат од одредени страници?
• Колку време поминувате во просек на оваа страница пред да заминете?
• Колку често правите премин од А во Б?
• На кои страници завршува сесијата?

Секој од извештаите или комбинација од нив треба да му овозможи на корисникот самостојно да најде одговори на овие прашања. Клучната стратегија овде е да ви дадеме алатки за да го направите тоа сами. Ова е корисно и за намалување на оптоварувањето на одделот за аналитика и за намалување на времето за донесување одлуки - на крајот на краиштата, повеќе не треба да одите на Youtrack и да креирате задача за аналитичарот, само треба да го отворите извештајот.

Што добивме?

Каде луѓето најчесто се оддалечуваат од контролната табла?

Фрагмент од нашиот извештај. По контролната табла, сите отидоа или на списокот со VM или на списокот на јазли

Ајде да земеме општа табела со транзиции и филтрирање по изворна страница. Најчесто, тие одат од контролната табла до списокот на виртуелни машини. Покрај тоа, колоната Регуларност сугерира дека ова е дејство што се повторува.

Од каде доаѓаат на листата на кластери?

Филтрите во извештаите работат во двете насоки: можете да дознаете каде сте заминале или каде сте отишле

Од примерите е јасно дека дури и присуството на два едноставни филтри и рангирањето на редовите по вредности ви овозможува брзо да добиете информации.

Да прашаме нешто потешко.

Каде корисниците најчесто ја напуштаат својата сесија?

Корисниците на VMmanager често работат во посебни јазичиња

За да го направите ова, потребен ни е извештај чии податоци се собираат со извори на упатување. И таканаречените точки на прекин беа земени како задачи - настани што служеа како крај на синџирот на транзиции.

Важно е да се забележи дека ова може да биде или крај на сесијата или отворање на нов таб. Примерот покажува дека ланецот најчесто завршува на табела со листа на виртуелни машини. Во овој случај, карактеристичното однесување е префрлање на друго јазиче, што е во согласност со очекуваната шема.

Корисноста на овие извештаи првенствено ја тестиравме на себе кога ја спроведовме анализата на сличен начин Веп, уште еден од нашите производи. Со доаѓањето на табелите и филтрите, хипотезите се тестираа побрзо, а очите беа помалку уморни.

Кога развивавме извештаи, не заборавивме на визуелниот дизајн. Кога работите со табели со оваа големина, ова е важен фактор. На пример, користевме мирен опсег на бои, лесни за перцепција monospace фонт за бројки, истакнување во боја на линиите во согласност со нумеричките вредности на карактеристиките. Ваквите детали го подобруваат корисничкото искуство и ја зголемуваат веројатноста алатката успешно да полета во компанијата.

Табелата се покажа доста обемна, но се надеваме дека не престана да се чита

Вреди да се спомене посебно за обуката на нашите внатрешни клиенти: специјалисти за производи и UX дизајнери. За нив беа специјално подготвени прирачници со примери за анализа и совети за работа со филтри. Вметнавме врски до прирачниците директно во страниците на извештаите.

Прирачникот го направивме едноставно како презентација во Google Docs. Алатките за табела ви дозволуваат да прикажувате веб-страници директно во работната книга за извештаи.

Наместо поговор

Што има во крајна линија? Релативно брзо и евтино успеавме да добиеме алатка за секој ден. Да, ова дефинитивно не е замена за самиот график, топлинската карта на кликови или веб-прегледувачот. Но, таквите извештаи значително ги надополнуваат наведените алатки и обезбедуваат храна за размислување и хипотези за нов производ и интерфејс.

Оваа приказна послужи само како почеток за развојот на аналитиката во ISP системот. Во текот на изминатите шест месеци се појавија уште седум нови услуги, меѓу кои и дигитални портрети на корисникот во производот и услуга за креирање бази на податоци за таргетирање Look-alike, но за нив ќе зборуваме во следните епизоди.

Извор: www.habr.com