Бесплатный Python-скрипт, который поможет вам улучшить анализ воронок, CJM и даже поиск багов в продукте
Обычно вы используете кучу дорогих тяжелых приложений с закрытым кодом, чтобы анализировать путь клиента и интерпретировать данные о его поведении. Наш коллега Марк Сысоев создал свой простой инструмент для тех же задач и выложил на Github в виде небольшого открытого проекта. Пользуйтесь и давайте фидбек! В статье вы найдете пару историй, которые доказали эффективность этого решения.
Сегодня Марк работает на Skyeng из Франции (но вы могли встретить его на Матемаркетинге), он тимлид команды аналитиков в проекте обучения детей математике и, кажется, это только начало славной карьеры. А еще недавно — этой весной, он был студентом Вышки и писал диплом "[Используем] Большие данные для анализа пути клиента в онлайн-образовании".
В процессе написания диплома родился и инструмент. Марк решил применить цепи Маркова (они показывают вероятность того или иного события на основе предыдущих действий пользователя), чтобы визуализировать поведение наших учеников и сделать выводы для нескольких рабочих задач.
Результат превзошел ожидания. Мы по-новому взглянули на учебные и рабочие процессы, а также саму экосистему Skyeng. С лета другие аналитики в компании тоже используют этот инструмент. А мы работаем над ошибками.
Кейс #1: продукты, призванные дополнять друг друга, на деле могут друг другу мешать
Учить английский на разных платформах “бесшовно” — классная идея.
Вот есть основной интерактивный учебник и видеосвязь с преподавателем в браузере, а вот приложения, где можно заниматься дополнительно хоть на бегу, хоть в дороге или в любом перерыве: подучить слова, что назначил педагог, сделать задания и так далее. Но подозрения, что так идеально не всегда и не у всех, нет-нет да возникали у части команды. И мы решили феерически расставить все точки над i.
С чего все началось. Мы решили посмотреть, насколько эффективно работает мобильное приложение с нашей детской аудиторией, и исследовал путь юных учеников по нашему самому популярному продукту — курсу английского под названием General.
Имея id студента, набор ключевых событий (начал курс, прошел урок с преподавателем и сменил курс на другой), а также время, когда эти события произошли, мы можем достроить карту его активности и в итоге получить цепь Маркова — прогноз, что он сделает дальше: продолжит заниматься, сменит курс или вовсе “отвалится”.
Вот что получилось:
Как читать схему. Стартовав в узле Start General (слева сверху), ученик пользуется приложением (App session) и занимается с преподавателем на веб-платформе (Successful class). По итогам он попадает в одну из категорий снизу:
- Fell asleep — больше не проходит занятия: мы оптимистично говорим “заснул”, хотя, скорее всего, он “отвалился”,
- Dropped General — сменил курс,
- Finished course — прошел 80% уроков (не все уроки обязательны) и закончил курс.
Ок, а что с приложением? Мы построили отдельные цепи для каждого из результатов (отвалился, закончил курс) и далее сравнивали, что было, если:
- После сессии в приложении человек опять возвращался к нему,
- Начинал с приложения, продолжал занятием,
- После занятия шел в приложение.
Что мы ожидали увидеть: связь успеха студента с занятиями в приложении.
Что мы увидели: успешные ученики использовали приложение не так интенсивно, а вот те, кто отвалился, начинали проводить в нем все больше времени — и, в конце концов, “засыпали”.
Сперва мы удивились, но затем поняли логику. Приложение веселое, там геймификация, все просто, быстро и понятно — и если провисеть в нем достаточно долго, создастся ложное ощущение выполненной работы. Идти что-то слушать в браузере, включаться в работу с преподавателем, вникать нет никакого желания. А ведь основная наша метрика — прогресс студента. Надо исправлять...
Мы узнали страшное: команда мобильного приложения слишком хорошо справилась с задачей сделать приложение привлекательным — оно стало настолько самодостаточным, что начало вываливаться из нашей экосистемы. Сейчас работаем над тем, чтобы оно оттягивало меньше внимания: причем и у детей, и у взрослых.
Кейс #2: одномерная воронка ничего не предвещала, а затем мы подняли QA по тревоге — баг
Результаты прохождения через несколько страниц онбординга выглядели обычно:
Онбординг — необязательная процедура при регистрации нового ученика. Мы проверяем, что у него современный браузер, правильно настроен микрофон и звук, а если это школьник — что родители будут с ним на вводном занятии. На первых двух шагах большая часть посетителей “сливается”, поняв, что надо что-то заполнять и проверять. А вот все, кто дошел до третьего шага, уже почти наверняка дойдет до финала.
Мы решили проверить наш онбординг на цепях Маркова. Включили чуть больше событий, запустили скрипт и получили вот такое:
Онбординг — линейный процесс, в нем не должно быть паутины связей. А пользователя кидало между шагами, у которыми вообще не должно быть переходов. Некоторые пользователи зацикливались и ходили по кругу, другие — вываливались из середины в начало, третьи в принципе не могли выбраться из первых двух шагов.
Причины обычно две:
- косяки в базе логов;
- косяки в самом продукте — онбординге.
Лечить надо обе, но с UX надо было срочно что-то делать.
Мы выяснили страшное: передали данные в QA — и выяснилось, что продукт простой, проблем никто не ждал и его не тестировали достаточно глубоко.
В результате, мы поменяли весь процесс записи.
А что найдете вы?
Python-скрипт для обучения цепей Маркова лежит в открытом доступе - пользуйтесь на здоровье, библиотека NetworkX и визуализатор Graphviz тоже доступны вам. Пробуйте, а если не хватит документации на GitHub, пишите, подскажем.
На первый взгляд выглядит очень перспективно, главное в команде иметь людей, кто верно все сможет настроить и что еще важнее - правильно интерпретировать)
Вот сейчас не понял. Скайенг еще и пайтону обучает?
Математике и английскому)
А в Python аналитики умеют по работе