Привет, Хабр! Меня зовут Витя, я работаю проектировщиком интерфейсов в Selectel. Проектируя интерфейс, мы предполагаем, что пользователи будут использовать его согласно задуманным сценариям: например, на странице со списком объектов воспользуются фильтрами для сортировки, а на странице заказа услуги заполнят определенные поля или выберут нужные опции. Но как узнать о реальных действия пользователей: что они используют, а что — нет?
Для ответа на этот вопрос используются инструменты аналитики, которые позволяют собирать данные, строить по ним графики и анализировать поведение пользователей. Об одном из таких инструментов я рассказывал в прошлой статье — это PostHog.
В этом материале хочу показать, как можно подойти в внедрению PostHog или любой другой системы событийной аналитики.
Сбор данных — целевые сценарии
PostHog позволяет вам минимизировать работу на старте и начать использовать автоматический сбор событий, например, просмотр страниц, клики по ссылкам и кнопкам. Кроме того, система собирает базовые параметры о пользователе: тип устройства, ОС, браузер и так далее.
Но для получения определенных данных, которые позволят ответить на вопросы, поставленные при проектировании системы, я бы рекомендовал определить основные целевые сценарии ваших пользователей и собирать данные именно по ним.
Просто ли пользователю выполнить целевое действие?
На каком этапе своего пути пользователь может столкнуться со сложностями?
Каковы особенности ваших пользователей?
Как определить целевые сценарии
Целевыми будут те сценарии, где пользователь получает необходимый результат от использования вашего продукта, например, заказ услуги или покупка. Как правило, целевое действие является финишным в спроектированном сценарии, поэтому проще начинать с таких событий.
Раз есть конечное событие в целевом действии, то должно быть и стартовое. Это та точка, в которой пользователь начинает свой путь: клик на кнопку оформления заказа или создания облачного сервера.
Скорее всего, в вашем продукте наберется несколько целевых сценариев. Допустим, перед тем, как перейти к оформлению заказа, нужно пройти через регистрацию. А после того, как пользователь зарегистрируется, он может пойти заказывать сначала одну услугу, а потом другую. Такие целевые события, которые могут быть выполнены в разное время и независищие друга от друга, лучше описывать отдельно.
Свойства целевых событий
Нам интересно не только количество пользователей, которые начали и закончили путь, но и опции, выбранные в процессе. Будет полезно узнать, сколько времени процесс занял, сталкивались ли они с ошибками и так далее. Дополнительно можем собирать и другие свойства пользователей, которые предусмотренные PostHog.
Таким образом, задав свойства, можно определять, какие именно юзеры выбирают те или иные опции, доходят до конца вашего сценария, а какие уходят из него.
При определении основных событий и их свойств стоит руководствоваться принципами достаточности, т.к. большое количество данных не гарантирует наличие ответов на все вопросы о пользователях. Планируете добавить новое свойство или событие? Ответьте на вопрос «Чтобы что?» — и зафиксируйте ответ в документации.
Игровой сервер с криперами и порталом в Незер. Добывайте ресурсы, стройте объекты, исследуйте мир Selectel в Minecraft и получайте призы.
Системный подход и документация
Итак, вы определили, какие события могут быть целевыми, какие свойства они имеют, узнали, «чтобы что». А что дальше?
А дальше нужно описать принципы, по которым вы определили события и свойства, и зафиксировать это в документации, чтобы спустя какое-то время вы вспомнили, а зачем это все. Желательно, чтобы не только вы, но и ваши коллеги смогли пользоваться вашей системой.
Проименуйте события
Сформулируйте правила для вашего продукта, по которым вы будете определять, что за событие перед вами, и следуйте им при создания новых событий. Например, ваш продукт помогает организовать путешествие и предлагает покупку билетов, бронирование отеля и аренду автомобиля. В каждом из продуктов будет начало и конец целевого события, к названиям которых логично применить общий паттерн: order_start и order_end.
Для того, чтобы его применять, нужно добавить еще слагаемое в начало имени, которое будет соответствовать разделу:
rent_order_start и rent_order_end
ticket_order_start и ticket_order_end
booking_order_start и booking_order_end
На какие базовые принципы стоит ориентироваться:
Простота. Чем короче и понятнее название, тем легче работать с ним в дальнейшем.
Однообразие. Следуйте единому стилю написания (вы можете выбрать snake_case или CamelCase, главное следовать ему).
Использование паттернов. Придумайте паттерн написания и переиспользуйте его в нейминге. Вам в помощь — префиксы или суффиксы, например btn_ для кнопок, и определяющие термины вроде start и end для начала и конца событий соответственно.
Определите цель
Обозначьте цель сбора данных, чтобы создать необходимые события и успешно получить ответы на свои вопросы.
Примеры целей
Простая количественная метрика определенного действия — подсчет востребованности фичи. Аналог из реального мира: счетчики посетителей в магазинах.
Определении конверсии: прохождение пользователем минимум двух шагов со сбором дополнительной информации, которая может повлиять на поведение пользователя — то есть вычисление эффективности решения. Аналог из реального мира: покупка в магазине, где начальный шаг — это вход в магазин, а финальный — оплата покупки на кассе. Дополнительные критерии, которые могут влиять на совершение конверсии: консультация перед покупкой или примерка.
Проверка сценария — похоже на конверсию, но содержит больше шагов, чтобы иметь возможность провести детальный анализ. Это подходит для оценки и анализа сложных путей пользователя. Аналог из реального мира: покупка в магазине, оформление доставки в специальном отделе и получение заказа дома.
Подберите метрики под цель
После того, как вы обозначили себе цель, можно перейти к подбору метрик и их свойств. Для примера возьмем за цель определение конверсии заказа услуги. Следовательно, у нас будет две метрики: первая определяет количество пользователей, которые пришли на страницу заказа услуги, а вторая — количество пользователей, которые оформили услугу.
У каждой из этих метрик могут быть свойства, которые помогут нам узнать больше о том, что способствует покупке, а что, наоборот, препятствует. Так стартовое событие в свойствах будет иметь источник, откуда пришел пользователь. Например, на вашей посадочной странице есть три места, где вы располагаете кнопку заказа. В стартовом событии вы можете отслеживать, какое из этих мест лучше всего работает, если в его свойствах добавите место, где событие совершается.
В свойствах финального события собираем все данные, которые определяют заказ: выбор доставки или самовывоза, способа оплаты, дополнительных услуг и так далее.
Таким образом, собрав статистику по прошествии времени, мы сможем получить портрет покупателя: он приходит на страницу оформления с баннера спецпредложения, выбирает доставку и оплачивает картой, дополнительные услуги не включает в заказ. И сразу рождается гипотеза — нужно подумать над тем, чтобы изменить дополнительные услуги или убрать вовсе.
Опишите события
Подводя итог всему описанному, можно привести следующий пример для описания события и анализа конверсии при оформлении заказа:
Последним шагом передаем разработчикам готовую документацию для интеграции в продукт. А также тестируем, что данные начали собираться, и ждем, пока будет собран статистически значимый объем данных. Какие возможности у вас появятся — читайте в моей статье.
Заключение
Инвестируйте время в анализ пользователей и их поведение, чтобы сделать продукты качественными и удобными. В этом вам могут помочь инструменты вроде PostHog, который упоминается в статье. Но главное — организовать системный подход к созданию и описанию метрик, если вы используете аналитику, построенную на сборе данных о событиях.