В интернет има стотици статии за ползите от анализа на поведението на клиентите. Най-често това се отнася за сектора на търговията на дребно. От анализ на хранителни кошници, ABC и XYZ анализ до маркетинг за задържане и лични оферти. Различни техники са използвани от десетилетия, алгоритмите са обмислени, кодът е написан и отстранен - вземете го и го използвайте. В нашия случай възникна един основен проблем - ние от ISPsystem се занимаваме с разработка на софтуер, а не с търговия на дребно.
Казвам се Денис и в момента отговарям за бекенда на аналитичните системи в ISPsystem. И това е историята за това как моят колега и аз — отговорниците за визуализацията на данни — се опитаха да погледнат нашите софтуерни продукти през призмата на това знание. Нека започнем, както обикновено, с историята.
В началото имаше една дума и думата беше „Да опитаме ли?“
В този момент работех като разработчик в отдел R&D. Всичко започна, когато Данил прочете тук на Хабре — инструмент за анализиране на потребителските преходи в приложенията. Бях донякъде скептичен относно идеята да го използвам тук. Като примери разработчиците на библиотеката цитираха анализ на приложения, където целевото действие беше ясно дефинирано - пускане на поръчка или някакъв друг вариант на плащане на компанията собственик. Нашите продукти се доставят на място. Тоест, потребителят първо купува лиценз и едва след това започва своето пътуване в приложението. Да, имаме демо версии. Можете да опитате продукта там, за да нямате прасе в джоба.
Но повечето от нашите продукти са насочени към хостинг пазара. Това са големи клиенти и отделът за бизнес развитие ги съветва относно продуктовите възможности. От това също следва, че в момента на покупката нашите клиенти вече знаят какви проблеми ще им помогне да решат нашият софтуер. Техните маршрути в приложението трябва да съвпадат с CJM, вграден в продукта, а UX решенията ще им помогнат да останат на път. Спойлер: това не винаги се случва. Запознаването с библиотеката беше отложено... но не за дълго.
Всичко се промени с пускането на нашия стартъп - — платформи за създаване на онлайн магазин от акаунт в Instagram. В това приложение на потребителя беше даден двуседмичен период да използва всички функции безплатно. След това трябваше да решите дали да се абонирате. И това се вписва идеално в концепцията „действие по маршрут-целя“. Беше решено: да опитаме!
Първи резултати или откъде да черпим идеи
Екипът за разработка и аз свързахме продукта със системата за събиране на събития буквално за един ден. Веднага ще кажа, че ISPsystem използва собствена система за събиране на събития за посещения на страници, но нищо не ви пречи да използвате Yandex.Metrica за същите цели, което ви позволява да изтегляте необработени данни безплатно. Бяха проучени примери за използване на библиотеката и след една седмица събиране на данни получихме графика на прехода.
Графика на прехода. Основна функционалност, други преходи са премахнати за яснота
Оказа се точно като в примера: плоско, ясно, красиво. От тази графика успяхме да идентифицираме най-честите маршрути и пресичания, където хората прекарват най-дълго време. Това ни позволи да разберем следното:
- Вместо голям CJM, който обхваща дузина обекти, активно се използват само два. Необходимо е допълнително да насочваме потребителите към местата, от които се нуждаем, използвайки UX решения.
- Някои страници, проектирани от UX дизайнери да бъдат от край до край, в крайна сметка хората прекарват неразумно много време върху тях. Трябва да разберете какви са стоп елементите на конкретна страница и да ги коригирате.
- След 10 прехода 20% от хората започнаха да се уморяват и да напуснат сесията в приложението. И това като вземем предвид факта, че имахме цели 5 onboarding страници в приложението! Трябва да идентифицирате страници, където потребителите редовно изоставят сесии и да съкратите пътя до тях. Още по-добре: идентифицирайте всички редовни маршрути и позволете бърз преход от изходната страница към целевата страница. Нещо общо с ABC анализа и анализа на изоставената количка, не мислите ли?
И тук преразгледахме отношението си към приложимостта на този инструмент за локални продукти. Беше решено да се анализира активно продаван и използван продукт - . Той е много по-сложен, има порядък повече единици. С вълнение чакахме да видим каква ще бъде графиката на прехода.
За разочарованията и вдъхновенията
Разочарование #1
Беше едновременно краят на работния ден, краят на месеца и краят на годината – 27 декември. Данните са натрупани, запитванията са написани. Оставаха секунди, преди всичко да бъде обработено и да видим резултата от нашия труд, за да разберем къде ще започне следващата работна година. Отделът за научноизследователска и развойна дейност, продуктов мениджър, UX дизайнери, ръководител на екипа, разработчици се събраха пред монитора, за да видят как изглеждат потребителските пътища в техния продукт, но... видяхме това:
Графика на прехода, изградена от библиотеката Retentioneering
Вдъхновение #1
Силно свързани, десетки обекти, неочевидни сценарии. Беше ясно само, че новата работна година ще започне не с анализ, а с изобретяването на начин за опростяване на работата с такава графика. Но не можех да се отърся от чувството, че всичко е много по-просто, отколкото изглеждаше. И след петнадесет минути изучаване на изходния код на Retentioneering, успяхме да експортираме изградената графика в точков формат. Това направи възможно качването на графиката в друг инструмент - 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 development научиха системата за събиране на събития да прави разлика между разделите. Анализът можеше да започне. И започнахме. Както се очакваше, CJM не съвпадна с реални пътища: потребителите прекараха много време в страници с директории, изоставени сесии и раздели на най-неочаквани места. Използвайки анализ на прехода, успяхме да открием проблеми в някои компилации на Mozilla. В тях, поради характеристиките на изпълнението, елементите за навигация изчезнаха или бяха показани полупразни страници, които трябва да бъдат достъпни само за администратора. Страницата се отвори, но от бекенда не дойде съдържание. Преброяването на преходите направи възможно да се оцени кои функции действително са използвани. Веригите позволиха да се разбере как потребителят получи тази или онази грешка. Данните, разрешени за тестване въз основа на потребителското поведение. Имаше успех, идеята не беше напразна.
Автоматизация на анализа
В една от демонстрациите на резултатите показахме как Gephi се използва за анализ на графики. В този инструмент данните за реализациите могат да бъдат показани в таблица. И ръководителят на UX отдела каза една много важна мисъл, която повлия на развитието на цялото направление за анализ на поведението в компанията: „Нека направим същото, но в Tableau и с филтри - ще бъде по-удобно.“
Тогава си помислих: защо не, Retentioneering съхранява всички данни в структура pandas.DataFrame. И това като цяло е маса. Така се появи още една услуга: Data Provider. Той не само направи таблица от графиката, но също така изчисли колко популярни са страницата и функционалността, свързана с нея, как влияе върху задържането на потребителите, колко време остават на нея и кои страници напускат най-често. А използването на визуализация в Tableau намали разходите за изучаване на графиката толкова много, че времето за итерация за анализ на поведението в продукта беше почти наполовина.
Данил ще говори за това как се използва тази визуализация и какви заключения позволява да се направят.
Още маси за бога на масата!
В опростена форма задачата беше формулирана по следния начин: покажете графиката на прехода в Tableau, осигурете възможност за филтриране и я направете възможно най-ясна и удобна.
Всъщност не исках да начертая насочена графика в Tableau. И дори при успех, печалбата в сравнение с Gephi не изглеждаше очевидна. Имахме нужда от нещо много по-просто и по-достъпно. маса! В края на краищата, графиката може лесно да бъде представена под формата на редове от таблица, където всеки ред е ребро от типа „източник-дестинация“. Нещо повече, ние вече сме подготвили внимателно такава таблица с помощта на инструментите Retentioneering и Data Provider. Остана само да изведем таблицата в Tableau и да поровим в отчета.
Говорейки за това как всички обичат масите.
Тук обаче се сблъскваме с друг проблем. Какво да правя с източника на данни? Беше невъзможно да се свърже pandas.DataFrame; Tableau няма такъв конектор. Създаването на отделна база за съхранение на графиката изглеждаше твърде радикално решение с неясни перспективи. А опциите за локално разтоварване не бяха подходящи поради необходимостта от постоянни ръчни операции. Прегледахме списъка с налични конектори и погледът ни падна върху елемента , който се сгушил унило в самото дъно.
Tableau разполага с богат избор от конектори. Намерихме такъв, който реши проблема ни
Какво животно? Няколко нови отворени раздела в браузъра - и стана ясно, че този конектор ви позволява да получавате данни при достъп до URL адрес. Бекендът за изчисляване на самите данни беше почти готов, оставаше само да го направим приятел с WDC. Няколко дни Денис изучаваше документацията и се бореше с механизмите на Tableau, след което ми изпрати линк, който поставих в прозореца за връзка.
Форма за връзка с нашия WDC. Денис направи своя фронт и се погрижи за безопасността
След няколко минути чакане (данните се изчисляват динамично при поискване) се появи таблицата:
Ето как изглежда масив от необработени данни в интерфейса Tableau
Както беше обещано, всеки ред от такава таблица представлява край на графиката, тоест насочен преход на потребителя. Той също така съдържаше няколко допълнителни характеристики. Например броя на уникалните потребители, общия брой преходи и други.
Би било възможно да се покаже тази таблица в отчета такава, каквато е, щедро да се поръсят филтри и да се изпрати инструментът да плава. Звучи логично. Какво можете да направите с масата? Но това не е нашият път, защото правим не просто таблица, а инструмент за анализ и вземане на продуктови решения.
Обикновено, когато анализира данни, човек иска да получи отговори на въпроси. Страхотен. Да започнем с тях.
- Кои са най-честите преходи?
- Къде отиват от конкретни страници?
- Колко време прекарвате средно на тази страница, преди да напуснете?
- Колко често преминавате от А към Б?
- На кои страници завършва сесията?
Всеки от докладите или комбинация от тях трябва да позволява на потребителя самостоятелно да намери отговори на тези въпроси. Ключовата стратегия тук е да ви даде инструментите, за да го направите сами. Това е полезно както за намаляване на натоварването на отдела за анализи, така и за намаляване на времето за вземане на решения - в крайна сметка вече не е необходимо да отивате в Youtrack и да създавате задача за анализатора, просто трябва да отворите отчета.
Какво получихме?
Къде хората най-често се отклоняват от таблото?
Фрагмент от нашия доклад. След таблото за управление всеки отиде или в списъка с виртуални машини, или в списъка с възли
Нека вземем обща таблица с преходи и филтрираме по изходна страница. Най-често те преминават от таблото за управление към списъка с виртуални машини. Освен това колоната Редовност предполага, че това е повтарящо се действие.
Откъде идват те в списъка с клъстери?
Филтрите в отчетите работят и в двете посоки: можете да разберете къде сте тръгнали или къде сте отишли
От примерите става ясно, че дори наличието на два прости филтъра и класиране на редове по стойности ви позволява бързо да получите информация.
Да попитаме нещо по-трудно.
Къде потребителите най-често изоставят сесията си?
Потребителите на VMmanager често работят в отделни раздели
За да направим това, се нуждаем от отчет, чиито данни са обобщени от източници на препратки. И така наречените точки на прекъсване бяха взети като задачи - събития, които служеха като край на веригата от преходи.
Тук е важно да се отбележи, че това може да бъде или краят на сесията, или отварянето на нов раздел. Примерът показва, че веригата най-често завършва до таблица със списък от виртуални машини. В този случай характерното поведение е превключване към друг раздел, което е в съответствие с очаквания модел.
Първо тествахме полезността на тези доклади върху себе си, когато извършихме анализа по подобен начин , друг наш продукт. С появата на таблици и филтри хипотезите бяха тествани по-бързо и очите бяха по-малко уморени.
При разработването на отчети не забравихме визуалния дизайн. Когато работите с маси с такъв размер, това е важен фактор. Например използвахме спокойна цветова гама, лесна за възприемане за числа, цветно подчертаване на линии в съответствие с числените стойности на характеристиките. Такива подробности подобряват потребителското изживяване и увеличават вероятността инструментът да се наложи успешно в рамките на компанията.
Таблицата се оказа доста обемна, но се надяваме, че не е престанала да се чете
Струва си да споменем отделно обучението на нашите вътрешни клиенти: продуктови специалисти и UX дизайнери. Специално за тях бяха изготвени ръководства с примери за анализ и съвети за работа с филтри. Вмъкнахме връзки към ръководства директно в страниците с отчети.
Направихме ръководството просто като презентация в Google Документи. Инструментите на Tableau ви позволяват да показвате уеб страници директно в работна книга с отчети.
Вместо последващо слово
Какво има в долния ред? Успяхме да получим инструмент за всеки ден сравнително бързо и евтино. Да, това определено не е заместител на самата графика, топлинната карта на кликванията или уеб визуализатора. Но такива доклади значително допълват изброените инструменти и дават храна за размисъл и хипотези за нови продукти и интерфейси.
Тази история послужи само като начало за развитието на анализите в ISPsystem. През последните шест месеца се появиха още седем нови услуги, включително цифрови портрети на потребителя в продукта и услуга за създаване на бази данни за Look-alike таргетиране, но за тях ще говорим в следващите епизоди.
Източник: www.habr.com