book-open 1 test
Курс «Настройка системы аналитики для продукта»

Создание структуры событий (events) для аналитики приложения | Глава 2

Какое событие должны совершить ваши пользователи, чтобы получить ценность от вашего продукта? Давайте разбираться.
Георгий Бирюков

Дизайн-инженер «Meta-Chrom». Специализируется на дизайне интерфейсов промышленных устройств. Исследует актуальные практики разработки и организации процессов создания интерактивных систем (UX/UI).

Май 31, 2023 · 15 мин читать

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

В предыдущей части мы обсуждали важность определения критического события (critical event) продукта. Какое событие должны совершить ваши пользователи, чтобы получить ценность от вашего продукта?  Для приложения доставки еды это может быть размещение заказа. Для приложения здравоохранения — это может быть запись на прием.

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

Определение широких (broad) категорий событий поможет вам осмыслить основные модули вашего продукта. Также такой подход поможет вам лучше организовать события в интерфейсе продуктовой аналитики (например Amplitude). Убедитесь, что каждая отслеживаемая категория способствует достижению хотя бы одной из ваших долгосрочных целей (goal) или KPI.

На основе краткосрочных бизнес-целей, в предыдущей части мы определили следующие варианты категорий событий:

Расставьте события по приоритету

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

Не нужно отслеживать каждое событие в продукте. Такой подход создаст много лишнего шума в проекте и усложнит понимание карты событий (или таксономии). Мы рекомендуем на первый раз измерять не больше 20-30 событий. Меньшее количество событий даст простор для размышлений и поможет сосредоточиться на том, что действительно важно отслеживать в продукте. Обратите внимание, вам следует разобрать на составляющие каждое событие в критическом пути (например, маршруты онбординга, воронки покупки). Важно прицепить метрики на каждый шаг воронки, чтобы увидеть всю картину и проанализировать потери (drop-offs).

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

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

Вопросы для, которые вам пригодятся:

Например, если вы хотите посмотреть что делают ваши наиболее вовлеченные пользователи и как это связано с удержанием, важно отслеживать конкретные действия в приложении ('add to cart, 'play stream', 'start game' | [“добавить в корзину”, “запустить стрим”, “запустить игру”]). Обычно в таких случаях события вроде “обновил настройки” не важны и их можно отложить на потом.

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

Именование событий

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

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

Например:

Также вам стоит приписывать к именам категории или использовать функцию Amplitude event categorization. Такая структура упрощает поиск событий. Если вы не знаете из каких событий состоит процесс заказа, вы можете набрать “checkout” и посмотреть все события из этой категории.

Также вам стоит учитывать и длину названий событий. Короткие имена делают данные читабельнее и понятнее.

Например, событие “game: completed game: level 1” можно переструктурировать как:

Убедитесь, что ваша карта событий непротиворечива.  Если вы добавите в Amplitude два события с названиями ‘Checkout Submitted Order’ и ‘Checkout submitted order’, они будут восприниматься как два разных события и их нельзя будет соединить.

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

События страниц и экранов (Page and screen view events)

Необходимо принять решение как отслеживать события: по действиям пользователей или по страницам, на которые они заходят.  Amplitude заточен под аналитику на основе событий. Тем не менее, вы можете выбрать отслеживание посещения страниц (или в случае мобильных приложений — экранов) в качестве событий. Это определенный компромисс и вы должны осознавать какая практика лучше подойдет вам для отслеживания страниц.

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

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

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

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

Также большое количество страниц еще сильнее засорит интерфейс Amplitude в вашей организации.

Рекомендации отслеживания страниц или экранов

То как вы структурируете ваши события страниц опять же зависит от вопросов, на которые вы ищете ответы.

Измерение отдельного события страницы

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

Свойство события: ‘level’ = ‘1’

Свойство события: ‘level’ = ‘2’

Такой подход также позволяет проще рассмотреть разделение на разные типы страниц. Вы сможете сгруппировать события по свойствам и посмотреть распределение событий без добавления каждого события на диаграммы.

Однако визуализация этим методом может оказаться сложнее, особенно при просмотре отдельных потоков (вы увидите следующий путь пользователя: Completed Game → Completed Game). Чтобы увидеть фактические шаги, нужно будет применить фильтр.

Измерение разных событий для каждой страницы

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

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

Вы можете использовать даже гибрид этих двух методов в зависимости от сути отслеживаемой страницы. Например, вы можете группировать похожие страницы в событиях, которые можно объединить (например: “loaded prroduct details page”, страница на которой есть несколько разных товаров, которые пользователи могут посмотреть; “loaded onboarding page”, страница, на которой есть несколько страниц онбординга, через которые может проходить пользователь). Этот способ дает вам гибкость, благодаря которой можно быстро узнать пользовательские маршруты без углубления в конкретное свойство события, сохраняя при этом определенную форму группирования при анализе данных.

Пример:

Свойство события: ‘product id’ = ‘129092’

Свойство события: ‘category’ = ‘Women’s’

Свойства

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

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

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

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

Свойства пользователей

Они отражают черты конкретного человека, использующего ваш продукт. Вы можете настроить свои собственные свойства пользователей, которые помогут вам более детально анализировать ваших пользователей. Они называются custom user properties.

Вот пара примеров кастомных свойств пользовательских событий:

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

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

Заметка: Amplitude отображает в проекте только 1000 первых свойств. Для более детальной информации изучите статью о пределах данных Amplitude в нашем Help Center. 

Если вы используете SDK Amplitude, по умолчанию у вас будут отслеживаться следующие свойства пользователей:

Для дополнительной информации посмотрите эту статью в нашем Help Center.

Предложения по пользовательским свойствам

Если у вас нет своего синтаксиса именования данных, мы рекомендуем: 

Не важно какой синтаксис для себя вы выбрали, главное - это следовать ему.

Свойства пользователейПримечание
registration status (идентификатор пользователя)Привязывайте ID только тем пользователям, действительно зашли в систему или зарегистрировались. Например Amplitude может отслеживать анонимных пользователей с уникальными Amplitude ID.
user type / status (тип/статус пользователя)‘Free’, ‘Paying’, ‘Seller’, ‘Buyer’
push notification status (статус push-уведомлений)Независимо от того, включены у пользователя push-уведомления или нет.
num total of Critical Actions performed (общее число выполненных критических событий)Идущий счетчик количества выполнений пользователем критического события.

Чтобы добавить значение прямо к свойству используйте функцию-инкримент Amplitude SDK.
signup date (дата регистрации)Когда пользователь впервые зарегистрировался в продукте
app install date (дата установки приложения)Дата когда пользователь впервые установил приложение.

В Amplitude вы можете отфильтровать по умолчанию можно отфильтровать новых пользователей (пользователей, которые использовали продукт впервые).
num total of sessions (общее количество сессий)Отслеживание общего совокупного количества сессий, проведенных пользователем в вашем продукте.
last seen date (дата последнего захода)Дата, когда пользователь в последний раз был активен в приложении.
AB testing variants (варианты A/B-тестирования)Больше информации о том, как собрать данные AB-тестирования в Amplitude можно найти здесь
customer profile information (информация из профиля клиента)Любая информация, которую пользователь может добавить в свой профиль.

Всегда будьте в курсе ваших пользователей и принятой у вас политики конфиденциальности. Также будет хорошей идеей убедиться, что отслеживание данных не нарушает законодательства.
Пользовательские свойства для значений, которые находятся в движении (например, подписчики) или интересных подсчетов LTV (например, общее количество заказов (total number of orders), общая выручка (total evenue)).Наличие кастомного свойства под эти значения сэкономит время анализа по двум причинам: не понадобится определять когорту для этих свойств и можно будет легко их сегментировать. Нет простого способа суммировать события с изменяющимися свойствами “Подписаться” и “Отписаться” для того, чтобы получить счетчик для определенного пользователя. Поэтому важно иметь свойство, означающее это число.

Вы можете просто добавлять по единице к значению этих свойств при каждом запуске события. Смотрите соответствующую документацию к SDK для получения дополнительно информации на Javascript, iOS или Android.

Свойства события (Event properties)

Свойства события описывают свойства или атрибуты события. Для примера, если вы отслеживаете событие “Свайп”, то свойство события может иметь значения “Влево” или “Вправо”.

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

Общие свойства события, которые мы видели, включают описание, категорию, типо, длительность, уровень, % завершения, название, количество, источник, предыдущую страницу/экран, откуда, сколько, продолжительность, аутентификацию, ошибку, ранг, действие и режим. Воспользуйтесь преимуществами свойств событий, чтобы сократить количество отслеживаемых событий, не теряя детализации. Смотрите раздел “Когда следует создать новое событие или новое свойство события для похожих действий пользователя?” в этой статье.

Одно из распространенных кейсов использования свойств события - отслеживание значений, которые должны быть постоянными, чтобы учитывать их в конверсии воронки. Например, e-commerce компания может анализировать по такому критическому пути:

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

В воронках вы можете держать постоянным только одно значение свойства. Итак, для данного e-commerce примера лучше всего подойдут два значения кастомных свойства событий, например, ‘Property ID’, ‘Cart ID’. Далее, чтобы отследить просматривал ли пользователь один и тот же товар и приобрел ли его, используйте две воронки.

Пара примеров:

Воронка добавления товара в корзину

Воронка корзины покупок

Пример

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

Возможно у вас есть гипотеза о том, что приглашенные друзьями пользователи вероятнее всего будут удержаны (retained). Чтобы проверить это, воспользуйтесь свойством события с названием “Source”:

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

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

Рекомендации для свойств

Когда следует создать новое событие или новое свойство события для похожих действий пользователя?

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

Вариант 1

Вариант 2

Насколько важно отслеживать поток событий от ‘Purchase Coins’ до ‘Purchase Gems’?

Если это достаточно важно, проще считать это как два разных события в Pathfinder, Pathfinder Users, Show Users Streams и Show User Paths. С другой стороны, если действие покупки не зависит от того, что они покупают, монету или драгоценный камень,  и вы хотите отфильтровать его, измеряйте его как одно событие ‘Purchase’ со свойством события, принимающим значение ‘Coins’ или ‘Gems’.

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

Идентификация пользователей

Отслеживание уникальных пользователей - это процесс сложный. Пользователи могут заходить в аккаунт, выходить из него или из приложения, сидеть в браузере анонимно или пользоваться несколькими устройствами. Чтобы вести точный подсчет пользователей, Amplitude использует комбинацию ID устройств, ID пользователей и ID Amplitude. Подробнее о том как в Amplitude подсчитываются и отслеживаются уникальные пользователи читайте здесь.  

Продукты с системой логинации способны отслеживать пользователей даже если они меняют устройства. Хотя присвоение ID пользователей и не требуется, мы рекомендуем продуктам с системой логинации или UUID (уникальный идентификатор пользователя) присваивать пользователям ID.

Преимущество присвоения ID в том, что Amplitude может сопоставлять события одного пользователя на разных устройствах. ID пользователя назначать не обязательно сразу. Не назначайте ID анонимным пользователям. Данные о события пользователя объединяются на сервере, поэтому все анонимные события до момента назначения ID будут связаны с назначенным ID (если нет противоречий с ID устройства).

Рекомендации по настройке ID

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

← Назад | Продолжение (Глава 3) →

Курс «Настройка системы аналитики для продукта»