Привет, Хабр! Меня зовут Екатерина Сивакова, я тимлид аналитики в Дзене (VK), а до этого работала в других бигтехах, и везде так или иначе сталкивалась с изучением CJM и пользовательской аналитикой. Сегодня хочу рассказать, как мы в Дзене делали единый инструмент по изучению пользовательского пути, зачем это понадобилось и что из этого вышло. А ещё о том, сколько это реально стоило по времени и ресурсам, потому что ответ отличается от первоначальной оценки примерно в 60 раз.

Текст будет вам полезен, если у вас продукт с большим количеством страниц и разветвлённой навигацией, с многочисленными однотипными переходами пользователей.

Дзен

Для начала немного контекста. Дзен — это информационная новостная платформа. Контент представлен в нескольких форматах: вертикальные короткие ролики, длинные видео, статьи, новости. Плюс к этому — лента рекомендаций, подписки, сохранённое и ещё целая россыпь страниц. Множество страниц и точек входа создают сложный пользовательский путь потребления контента. Он нелинейный, и без специального инструмента понять его трудно.

Откуда вообще взялась потребность

Чтобы было понятнее, расскажу на примере. Есть аналитик Василий, он занимается сложными аналитическими задачами в рамках спринта. И есть продакт Геннадий, которому нужны конкретные числа. Например, он приходит с запросом: «Нужна доля пользователей, которые переходят с Главной в Статьи, и сравнение с переходами в Видео. К утру, для презентации CEO». Василий смотрит на это, грустит и направляет Геннадия в очередь спринта.

Но Геннадий не один — у его коллег-продактов свои аналитики и свои вопросы: сколько пользователей читают одну новость и уходят, с каких страниц чаще переходят в статьи, какая доля из сюжета уходит на главную. Если обобщить, то все эти запросы об одном и том же — о том, как пользователи пользуются продуктом.

Стало понятно, что так дальше продолжаться не может.

Кому это может пригодиться

Решение, к которому мы пришли: создать единый инструмент по изучению CJM в Дзене. Мотивация складывалась из трёх вещей. Во-первых, сократить время, которое аналитики тратят на adhoc-задачи. Во-вторых, уменьшить time-to-market за счёт быстрого скоринга части гипотез: теперь продакт может сам посмотреть какие-то числа, не привлекая аналитика. В-третьих, получить системное знание о том, как пользователи двигаются по Дзену.

В каких случаях подобный инструмент может быть полезен? Если у вас большой продукт с большим количеством страниц, разветвлённая навигация и нет понимания user flow. Без такого инструмента типичные последствия: перегрузка аналитиков adhoc-запросами, отсутствие фокуса при улучшении CJM, неоптимизированные пользовательские пути.

Что такое CJM

Коротко про теорию. Customer Journey Map — это карта пути пользователя, инструмент, который помогает бизнесу понять, как пользователи взаимодействуют с продуктом на всех этапах. Визуализация может быть разной: таблица, граф, диаграмма переходов. Общие примеры из практики — последовательности вроде «Поиск → Выбор → Покупка» с долями перетоков на каждом шаге.

Почему выбрали этот тип визуализации

Мы перепробовали несколько вариантов и выбрали тот, который лучше подходил под нашу задачу. Нам нужно было смотреть перетоки между страницами, и для этого хорошо подошла Sankey-диаграмма — потоковая природа этой визуализации соответствует вопросу «откуда пользователь пришёл и куда ушёл дальше».

Но тут возникла проблема масштаба. Дзен большой, страниц много, и за небольшой промежуток времени пользователь может совершить больше 20 переходов. Если просто построить Sankey на всём подряд, то результат получается нечитаемым.

Две визуализации вместо одной

Выходом стало разделение на две взаимодополняющие визуализации. Первая отвечает на вопрос: «откуда и куда идёт трафик с конкретной страницы», — это локальная карта роли страницы в пользовательском пути. Вторая показывает популярные сценарии — наиболее частые паттерны сессий. Таким образом, мы не пытались уместить весь мир в одну диаграмму, а разбили задачу на две более понятные аналитические проекции.

Оценка «три дня» и реальность

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

С чем столкнулись на практике

Разметка событий

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

Коммуникации

Разработчики взяли задачу в работу, но после реализации оказалось, что часть команд не реализовала событие, часть отправляла его по неправильной логике, а кто-то просто не передавал важные параметры. Произошло это потому, что внутри Дзена много продуктовых команд — за видео отвечает одна, за новости другая, — и задачу на журналирование приносили в каждую отдельно, с множеством разных разработчиков и QA. Практический вывод: подобные вещи лучше делать централизованно через одного разработчика и одного QA.

Отдельной серьёзной сложностью оказались коммуникации между командами. В проекте, который затрагивает сразу много продуктовых команд, синхронизация — это отдельный фронт работ.

Работа с логами

Обычно в нашей отрасли есть есть два базовых типа логов — сырые и сессионные. И в собираемых данных есть свои особенности. Главное, что нужно было из логов получить, — таблицу определённой гранулярности: для каждого пользователя — его сессия, страница и номер страницы в последовательности просмотра. По сути, мы склеивали сырые и сессионные логи, чтобы восстановить упорядоченный маршрут пользователя внутри одной сессии. Без этой структуры честно анализировать пользовательский путь невозможно.

Данных много, а что из них нужно?

Даже когда событий и логов оказалось достаточно, встал вопрос отбора: какие сущности, уровни агрегации и переходы действительно нужны для карты пути, а какие только создадут шум? Само по себе наличие большого объёма данных проблему не решает — нужно определить, что из них релевантно.

Инфраструктурные ограничения

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

Автоматизация

После демо Геннадий задал закономерный вопрос: «Когда данные будут обновляться каждый день?» Василий прикинул: «Моего времени — дня два, а дальше нужна помощь коллег из data-портала». 

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

Что получилось

Первый инструмент — Sankey-диаграмма перетоков для конкретной страницы. Как она устроена: в центре находится рассматриваемая страница; красные линии показывают долю переходов из неё на другие страницы; синие — откуда на неё поступает трафик; зелёная — какая доля сессий начинается на этой странице; жёлтая — какая доля заканчивается. Отдельный случай — петля: если пользователь потребляет одну и ту же страницу с разным контентом подряд (например, листает шортсы), то это отображается как переход со страницы на саму себя.

На проде инструмент доступен через data-портал с набором фильтров: дата, конкретная страница, активность пользователя (новички, средние, активные), платформа (веб-десктоп, мобильный веб, приложения). Под графиком есть таблицы — например, топ-5 источников и топ-5 выходов для выбранной страницы.

Второй инструмент показывает топ-20 популярных путей пользователей. Каждая строка — это последовательность страниц, которые пользователь прошёл за сессию. Рядом с каждой указано количество сессий с таким путём и их доля от общего среза. Например: «Главная → Карточка товара → Главная» — 154 сессии, 7% от выбранного среза. Фильтрация аналогичная: дата, платформа, активность пользователя. Топ отобран по перцентилю.

Как начали использовать CJM

Инструмент нашёл применение в нескольких направлениях: подтверждение гипотез, покрытие adhoc-аналитики, анализ изменений CJM в A/Б-тестах, быстрые выгрузки по предагрегату, повторное использование визуализаций со своими данными, оптимизация пользовательских путей, дизайн навигации в сервисе, исследование основных паттернов переходов. Отдельно стоит отметить, что инструмент стал частью адаптации новых сотрудников — как первое знание о пользовательских сценариях для тех, кто ещё не знаком с платформой.

Принятие не произошло мгновенно. Поначалу продакты приходили с вопросами: «Что значит это число? Что за процент, когда я навожу на линию?» По мере того как у людей возникали реальные задачи, они начинали обращаться к инструменту.

Сколько это стоило

Прошло шесть месяцев от взятия задачи до выкатки на прод. По ресурсам: 7 разработчиков для внедрения журналирования, 7 QA для проверки, 1 аналитик на разметку, 1 аналитик на рецензирование логов и все скрипты, 1 DWH-аналитик для создания конвейера, 1 продакт с ТЗ. Это не маленькая история, и мы намеренно не пытается это скрыть.

Практический алгоритм

Если свести весь процесс к пошаговому плану, то получается так. Сначала продумать журналирование: если нужных событий нет, их придётся создать. Дальше — выделить разработку на внедрение этого журналирования и проверить результат с помощью QA. Из сырых данных и сессий собрать таблицу в формате «пользователь — ID сессии — страница — номер страницы в последовательности». Выбрать визуализацию — в нашем случае это Sankey-диаграмма для перетоков и блок-схема для топ-20 путей. И наконец, автоматизировать: первый SQL-скрипт собирает данные в нужном формате, второй формирует два агрегата для визуализаций, третий (Python) визуализирует данные из агрегатов, а готовые HTML хранятся облачно и подтягиваются в data-портал.

Что в итоге

Кому нужен такой инструмент? Большим продуктам с разветвлённой навигацией. Зачем? Для ускоренной проверки гипотез продактами и сохранения времени аналитиков. Стоит ли это шести месяцев работы? Вопрос, на который каждая команда отвечает для себя сама, исходя из масштаба продукта и количества adhoc-запросов. В нашем случае — стоило.