Про веб-аналитику: Events & User profile

В данной статье я расскажу о том как концептуально устроены системы веб-аналитики (аналитики веб-сайтов), что такое “события”, какие события нам нужны и почему. Порассуждаю на тему User Profile и плавно подойду к концепции когортного анализа в разрезе общих поведенческих метрик.

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

Каждый более-менее опытный разработчик, маркетолог или продукт сталкивался с такими продуктами как Яндекс.Метрика или Google Analytics. Некоторым довелось поработать с Piwik (сейчас уже - Matomo). Крупные компании часто строят свои BI-системы используя различные платформы анализа данных и хранения “сырых” событий.

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

Дальнейшее развитие систем сбора и анализа данных открывает нам функционал предсказания действий (или отказов) пользователя и дает возможность принимать меры к его возврату/удержанию, пока не стало слишком поздно.

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

Понятно, что мы не сможем описать все системы полно, но все подобные системы аналитики концептуально устроены примерно одинаковым образом:

Что тут происходит?

1) Пользователи в ходе посещений сайта - визитов (ещё говорят visit, session, сессия) - совершают определенные действия, некоторые из них порождают события (events). Визиты обычно ограничены временем неактивности - обычно это 30 минут. Т.е. если за полчаса пользователь не совершил никаких действий в системе - мы считаем что визит завершился.

Product-owner или аналитик принимает решения о том какие события на сайте являются ключевыми, разработчик соответствующим образом модифицирует сайт/веб-приложение так, чтобы эти действия приводили к порождению событий (например, в яндекс метрике для этого нужно вызвать javascript-функцию ym(counterId, 'reachGoal',goalName) ).

2) Для пользователей Метрики, Analytics или любых пользователей готовых систем дальше “всё работает” само, а событие становится доступным в отчетах в панельке просмотра статистики. Всё :)

Но чтобы лучше понять какие нам нужны события в будущем - стоит посмотреть под капот этих волшебных систем.

Сначала события попадают в приемник событий, валидируются на возможность принять это событие из данного источника и откладываются в шину сообщений (ещё говорят “брокер сообщений” или “сервер очередей”) в виде потока событий. Яркими представителями таких шин являются Apache Kafka или RabbitMQ. Важно сказать, что почти все события внутри систем обычно перемещаются через подобных брокеров.

События обладают контекстом. Этот контекст нельзя определить однозначно, но он, как минимум, включает информацию о пользователе, его устройстве, состояниях внутри систем (например, принадлежность группам сплит-тестов), а также многих других вещах, которые покажутся важными.

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

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

Результаты обогащения не всегда используются для построения отчетов, но позволяют иметь более полную картину происходящего при последующем data mining.

Далее событие отправляется на “склад хранения”. В разных подходах для этого используются либо DWH (Data warehouse) либо Data Lake. Данные системы предназначены для хранения и достаточно быстрой выборки петабайтов данных, хранящихся на большом количестве серверов. Вы могли слышать такие слова как Clickhouse, Vertica, Amazon Redshift, Greenplum, Apache Spark, SAP Hana и т.п.

Хранение событий в таких количествах требует предварительной их подготовки, например - дедупликации, очистки, выделения данных из словарей, трансформации и разделения по таблицам и т.п. Для этих операций существуют специальные системы, которые осуществляют ETL-процессинг (ETL - Extract, Transform, Load - ровно то, что они делают с данными). Примеры ETL-систем: Apache NiFi, Streamsets.

В DWH/Data lake чаще всего хранятся так называемые факты (это представление наших событий на сайте), на базе которых необходимо сформировать отчеты/срезы/olap-кубы при помощи систем презентации данных. Чтобы мы смогли работать с отчетами более-менее быстро - факты необходимо представить в удобном для работы виде: создать “расширенные” факты, построить агрегаты и т.п.

Подобные действия требуют ещё одной etl-трансформации и более “быстрого” и “маленького” хранилища - витрины данных. В качестве витрин данных могут использоваться совершенно разные системы и инструменты, мы остановили свой выбор на PostgreSQL.

Ну и последний шаг - данные из витрины нужно отобразить в виде таблиц, графиков и понятных табличек. Для этого подходят системы вроде Tableau, Microsoft PowerBI, Qlikview, Apache Zeppelin.

Ровно с этим интерфейсом мы взаимодействуем, когда смотрим отчеты в яндекс-метрике или гугл-аналитике.

Надеюсь, теперь стало чуть-чуть понятнее почему после клика на сайте событие в метрике появляется с небольшой задержкой :)

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

На каждом этапе пользователь должен совершить действие для перехода в следующий уровень; сам переход отмечаем как событие и - мы молодцы?

Не совсем: давайте посмотрим на воронку чуть внимательнее. Между “переходами на лендинг” и “регистрацией” существует целая форма, которую можно заполнить неправильно или получить ошибки валидации (например, нельзя будет использовать домен hi.io в адресе электронной почты). Поможет ли нам знание CR шага лендинг->регистрация ответить на вопрос “а почему конверсия такая низкая”? Ответ очевиден - нет. Для этого нам не хватит данных.

С пробным уроком всё ещё сложнее - пользователь может на него не приходить, остаться недовольным (например - из-за преподавателя или качества связи) и т.п.То есть: отслеживая переходы внутри воронок мы совершенно ничего не сможем сказать о причинах таких ее рейтов. Важная часть работы продуктовых аналитиков именно в том, чтобы находить не только “проблемные” точки, но и причины возникновения проблем.

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

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

Двигаясь по этой логической цепочке мы вскоре придем к простому факту: мы хотим знать о пользователе всё на каждом этапе его взаимодействия с нашей системой. А была бы у нас возможность - мы бы хотели знать и о том что он ел на ужин, какого цвета лоток у его кошки и каков его средний чек в баре по пятницам.

Добро пожаловать в мир Big data :)

Если представить что мы могли бы собрать все эти факты (а представьте сколько о вас знает Google или Facebook), то у нас бы получилась некоторая фактологическая модель пользователя (ещё говорят “цифровой двойник”), при помощи которой мы могли бы предсказывать его поведение, желания, побуждения и понимать мотивы.

В реальности, все эти данные нам недоступны, но мы можем попробовать построить “виртуальный портрет” или профиль пользователя (профайл) нашего сайта. Сюда должна попадать и интегральная активность в рамках сессий и переходов, и глубина просмотра и карта переходов. Эти данные избыточны для построения простых воронок и определения очевидных связей, однако при глубоком анализе (то что называют data mining) мы имеем возможность предсказать вполне полезные вещи. Например:

• по активности при заполнении формы и перед подготовкой первого урока - мотивированность его посещения. И по результатам работы модели можем “добить” пользователя письмом или смс-сообщением с напоминанием об уроке;
• по результатам интегральной активности и уровне вовлеченности в урок предсказать вероятность оплаты и воспользоваться доступными механиками удержания и т.п.

То есть, обладание профилем пользователя позволяет нам повышать эффективность маркетинговых каналов путем повышения конверсии, а также улучшать retention (и как следствие - LTV) путем воздействия на пользователя в возможных точках отказа. И если без профайла это будет ковровой бомбардировкой и механики возврата будут применены на большое количество пользователей, а общая стоимость кампании может легко превысить экономический эффект от реально возвращенных пользователей, то в случае использования профайлов такие акции будут точечными и, при хорошей настройке, показывать заметно большую эффективность.

Профайлы позволяют кастомизировать продукт и угадывать потаённые желания пользователей или факты, о которых сам пользователь может даже не подозревать (впечатляющий пример).

И, да, это - уже давно наше с вами настоящее.

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

Отдельно стоит акцентировать внимание на том, что все эти штуки крайне вредны небольшим компаниям или тем кто ещё в поисках своей рабочей модели - внедрение и поддержка систем глубокой аналитики сбивает фокус с продукта, требует выделенных менеджеров, которые будут про это постоянно думать и улучшать (и требовать зарплату); нужны будут специалисты как сбору, так и по анализу всех этих данных (и опять расходы). Системы требуют заметных серверных мощностей, которые надо арендовать и обслуживать. Прирост LTV на одного пользователя может быть в единицах процентов, а значительно больший эффект даст простое увеличение пользовательской базы или просмотр сессий пользователей в Hotjar или аналоге. В случае поиска модели, кроме пассива в виде TCO, вы будете накапливать большое количество данных, которые не будут накладываться на ваши текущие гипотезы (собирались-то они для старых гипотез!) и могут вносить сумбур ошибку.

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

Безусловно, человек - венец творения и индивидуальность. Однако, заметная часть людей покупает себе именно Apple Macbook Pro. Другая (не менее заметная) предпочитает пить кофе Nescafe по утрам. Совершенно разных людей разных полов, возрастов и национальностей объединяет некоторое общее предпочтение.

Обычно, когда речь идет о когортах, мы выделяем когорты пользователей, пришедших из примерно одного источника в примерно одно время. Этот когортный анализ является базой и позволяет оценить эффективность маркетинговых каналов трафика.

Но применение когорт в профайлинге позволяет нам сформировать продуктовые линейки, подходящие под наших конкретных пользователей. Приведу пример: если у вас средний ARPPU 8000 рублей, но есть когорта пользователей с ARPPU 80000, то стоит конкретно под них создать субпродукт или модифицировать корзину и интерфейс c целью увеличения чека хотя бы на 10% - один такой пользователь приносит уже как 10 других, а небольшие улучшения на таких когортах в процентах дают заметно более приятный абсолютный прирост. Часто таких пользователей называют “китами”.

Аналогичный анализ платящих или поведенческих когорт с прогнозированием вхождения в них позволяет оценивать эффективность тех или иных маркетинговых каналов (а при использовании сквозной аналитики - вплоть до рекламных объявлений) и оптимизировать расходы на маркетинг.

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

Инструменты должны развиваться вместе с вашим бизнесом и его требованиями и приносить максимальную пользу именно на текущем этапе развития продукта/компании или в обозримом будущем. Всем хорошего ROI!