Бесплатный Python-скрипт, который поможет вам улучшить анализ воронок, CJM и даже поиск багов в продукте

Обычно вы используете кучу дорогих тяжелых приложений с закрытым кодом, чтобы анализировать путь клиента и интерпретировать данные о его поведении. Наш коллега Марк Сысоев создал свой простой инструмент для тех же задач и выложил на Github в виде небольшого открытого проекта. Пользуйтесь и давайте фидбек! В статье вы найдете пару историй, которые доказали эффективность этого решения.

Сегодня Марк работает на Skyeng из Франции (но вы могли встретить его на Матемаркетинге), он тимлид команды аналитиков в проекте обучения детей математике и, кажется, это только начало славной карьеры. А еще недавно — этой весной, он был студентом Вышки и писал диплом "[Используем] Большие данные для анализа пути клиента в онлайн-образовании".

В процессе написания диплома родился и инструмент. Марк решил применить цепи Маркова (они показывают вероятность того или иного события на основе предыдущих действий пользователя), чтобы визуализировать поведение наших учеников и сделать выводы для нескольких рабочих задач.

Результат превзошел ожидания. Мы по-новому взглянули на учебные и рабочие процессы, а также саму экосистему Skyeng. С лета другие аналитики в компании тоже используют этот инструмент. А мы работаем над ошибками.

Учить английский на разных платформах “бесшовно” — классная идея.

Вот есть основной интерактивный учебник и видеосвязь с преподавателем в браузере, а вот приложения, где можно заниматься дополнительно хоть на бегу, хоть в дороге или в любом перерыве: подучить слова, что назначил педагог, сделать задания и так далее. Но подозрения, что так идеально не всегда и не у всех, нет-нет да возникали у части команды. И мы решили феерически расставить все точки над i.

С чего все началось. Мы решили посмотреть, насколько эффективно работает мобильное приложение с нашей детской аудиторией, и исследовал путь юных учеников по нашему самому популярному продукту — курсу английского под названием General.

Имея id студента, набор ключевых событий (начал курс, прошел урок с преподавателем и сменил курс на другой), а также время, когда эти события произошли, мы можем достроить карту его активности и в итоге получить цепь Маркова — прогноз, что он сделает дальше: продолжит заниматься, сменит курс или вовсе “отвалится”.

Вот что получилось:

Как читать схему. Стартовав в узле Start General (слева сверху), ученик пользуется приложением (App session) и занимается с преподавателем на веб-платформе (Successful class). По итогам он попадает в одну из категорий снизу:

• Fell asleep — больше не проходит занятия: мы оптимистично говорим “заснул”, хотя, скорее всего, он “отвалился”,

• Dropped General — сменил курс,

• Finished course — прошел 80% уроков (не все уроки обязательны) и закончил курс.

Ок, а что с приложением? Мы построили отдельные цепи для каждого из результатов (отвалился, закончил курс) и далее сравнивали, что было, если:

• После сессии в приложении человек опять возвращался к нему,

• Начинал с приложения, продолжал занятием,

• После занятия шел в приложение.

Что мы ожидали увидеть: связь успеха студента с занятиями в приложении.

Что мы увидели: успешные ученики использовали приложение не так интенсивно, а вот те, кто отвалился, начинали проводить в нем все больше времени — и, в конце концов, “засыпали”.

Сперва мы удивились, но затем поняли логику. Приложение веселое, там геймификация, все просто, быстро и понятно — и если провисеть в нем достаточно долго, создастся ложное ощущение выполненной работы. Идти что-то слушать в браузере, включаться в работу с преподавателем, вникать нет никакого желания. А ведь основная наша метрика — прогресс студента. Надо исправлять...

Мы узнали страшное: команда мобильного приложения слишком хорошо справилась с задачей сделать приложение привлекательным — оно стало настолько самодостаточным, что начало вываливаться из нашей экосистемы. Сейчас работаем над тем, чтобы оно оттягивало меньше внимания: причем и у детей, и у взрослых.

Результаты прохождения через несколько страниц онбординга выглядели обычно:

Онбординг — необязательная процедура при регистрации нового ученика. Мы проверяем, что у него современный браузер, правильно настроен микрофон и звук, а если это школьник — что родители будут с ним на вводном занятии. На первых двух шагах большая часть посетителей “сливается”, поняв, что надо что-то заполнять и проверять. А вот все, кто дошел до третьего шага, уже почти наверняка дойдет до финала.

Мы решили проверить наш онбординг на цепях Маркова. Включили чуть больше событий, запустили скрипт и получили вот такое:

Онбординг — линейный процесс, в нем не должно быть паутины связей. А пользователя кидало между шагами, у которыми вообще не должно быть переходов. Некоторые пользователи зацикливались и ходили по кругу, другие — вываливались из середины в начало, третьи в принципе не могли выбраться из первых двух шагов.

Причины обычно две:

• косяки в базе логов;
• косяки в самом продукте — онбординге.

Лечить надо обе, но с UX надо было срочно что-то делать.

Мы выяснили страшное: передали данные в QA — и выяснилось, что продукт простой, проблем никто не ждал и его не тестировали достаточно глубоко.

В результате, мы поменяли весь процесс записи.

Python-скрипт для обучения цепей Маркова лежит в открытом доступе - пользуйтесь на здоровье, библиотека NetworkX и визуализатор Graphviz тоже доступны вам. Пробуйте, а если не хватит документации на GitHub, пишите, подскажем.