Рассылка по таксономии

Глава 2. Таксономия. Все о событиях и пользователях

Как отслеживать просмотры страниц и экранов?
Как вы структурируете события просмотра страниц, зависит от вопроса, на который вы пытаетесь ответить с помощью данных.
Вариант 1: событие просмотра одной страницы
Создайте универсальное событие для нескольких страниц и фиксируйте разницу в свойствах событий. Например:

  • событие: просмотр страницы завершенной игры,
  • свойство события: уровень = 1;
  • событие: просмотр страницы завершенной игры,
  • свойство события: уровень = 2.

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

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

Мы рекомендуем сгруппировать похожие просмотры страниц в одно событие. Например:
  • «загруженная страница с подробной информацией о продукте», где пользователь может просматривать множество разных товаров; 
  • «загруженная начальная страница», когда есть несколько страниц с онбордингом. 
Вы сможете быстро увидеть и понять пути пользователя, не углубляясь в конкретное свойство события, а также возможность агрегировать данные.

Например:
  • событие: «просмотр домашней страницы» (вариант 2);
  • событие: «просмотр страницы товара» (вариант 1),
  • свойство события: «идентификатор продукта» = «129092»,
  • свойство события: 'category' = «Женщины».
Как назвать события
Правильное наименование событий поможет вам получать более качественные данные. В этом вам помогут следующие правила:

Поддерживайте единообразное название событий. Например, «глагол + существительное»: submit order.
  • Нет


    – submit order,

    – cart open,

    – added discount item.

  • Да


    – submit order,

    – open cart,

    – add item.

Пишите все слова в наименовании с маленькой буквы, чтобы избежать ошибок из-за шрифта. Например, вместо Add items To cart, назовите add items to cart.
  • Нет


    – start trial, 

    – finish Onboarding,

    – view Welcome page.

  • Да


    – start trial,

    – finish onboarding,

    – view welcome page.

Не создавайте множество похожих событий. Например, «пройден уровень 1», «пройден уровень 2». Лучше создайте одно событие «пройден уровень», а номер спрятать в свойства события.
  • Нет


    – add apple,

    – add milk,

    – add %item%.

  • Да


    – add item

    item_id: 12343

    item: milk.

В event-based системах продумайте работу с просмотрами страниц. Их также лучше объединить и не дублировать с событиями кликов по кнопке.
  • Нет


    – click next button,

    – open page 2,

    – click next button,

    – open page 3.

  • Да


    – open page

       page_id: 2,

    – open page

       page_id: 3.

Добавьте категорию в название события. Например:

  • view welcome page [onboarding],
  • sign up [onboarding],
  • add transaction [onboarding].
Если в названии события есть ошибка, лучше исправить ее отображение в системе, а не в коде. Иначе будет сложно объединить старые записи с ошибкой и новые без ошибки.
Всегда отслеживайте, чтобы наименования событий были в едином синтаксисе. Например, Amplitude засчитает события 'Checkout Submitted Order' и 'Checkout submitted order' как два отдельных, и объединить их нельзя.

Когда данные дублируются, строить отчеты будет дольше и сложнее.
Свойства события
Описывают дополнительные свойства или атрибуты события. Например, если «Свайп» — это событие, которое вы отслеживаете, то свойство события «Направление» будет иметь значения «Влево» или «Вправо».

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

Свойствами событий могут быть:
  • описание,
  • категория,
  • тип,
  • продолжительность,
  • уровень,
  • процент завершения,
  • предыдущая страница/экран,
  • ошибка, ранг, действие и режим и так далее.
Пример
Допустим, вы хотите понять, не слишком ли затянут онбординг в продукте и не уходят ли пользователи во время его прохождения.

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

Пользовательскими свойствами могут быть:


Помните что эти свойства отражают состояние пользователя и применяются ко всем его событиям в будущем, пока свойства не будут обновлены.
Пример
Страница активности Марио от 3 июля:
Если вы используете Amplitude SDK, вы по умолчанию будете отслеживать следующие свойства пользователя: 

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

Остальные свойства нужно передавать самостоятельно.

Читайте подробнее про каждое свойство в статье от Amplitude.
Как идентифицировать пользователей
Отслеживание уникальных пользователей — сложный процесс, потому что пользователи могут заходить в ваш продукт и выходить из него, просматривать анонимно и использовать несколько устройств. Чтобы вести точный подсчет пользователей, Amplitude предлагает комплексное решение с комбинацией Device ID, User ID и Amplitude ID.

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

Рекомендуем продуктам с системой входа или системой UUID (уникальный идентификатор пользователя) назначать User ID. Преимущество в том, что Amplitude может сопоставлять события на нескольких устройствах под одним и тем же пользователем (один и тот же User ID).

Рекомендации по настройке идентификаторов пользователей
  • Не устанавливайте User ID, если вы не можете его определить. Например, установка User ID строки «Нет» для нескольких пользователей сгруппирует все события под этим User ID вместе. Вы можете установить User ID позже, и встроенная логика Amplitude объединит анонимные события с более поздним идентифицированным пользователем.

  • Не назначайте User ID, который может измениться. Если чей-то email может измениться в вашем приложении, не рекомендуется устанавливать его в качестве User ID. Если пользователь изменит адрес электронной почты, Amplitude пометит его как нового пользователя.

Data governance — один из важнейших элементов таксономии
Data governance — люди, процессы и инструменты в компании, которые отвечают за корректность и полезность данных. Очень важно настроить этот процесс при построении таксономии, если вы хотите улучшать пользовательский опыт на основе данных.

Основные направления работы Data Governor и их команды:

  1. Курирование таксономии. Создание реестра событий и ее поддержка.
  2. Планирование новых событий и свойств. Взаимодействие с разработкой для поддержки новых релизов.
  3. Тестирование и поддержка. Проверка работы отправки событий, исправление ошибок.
  4. Управление доступом. Чтобы данные были доступны нужным людям.
  5. Удаление данных. Регулярная очистка старых, нерелевантных и неиспользуемых данных.
Пример правильного курирования внедрения
  • Шаг 1


    Команда пишет запрос на внедрение новых событий. Он должен содержать:


    • описание юзкейсов: какие сценарии они хотят разметить;
    • ответ на вопрос: Зачем?
  • Шаг 2


    Governor говорит, где найти эти события (если уже внедрены), либо курирует процесс «Составление и верификация ТЗ -> Внедрение» .

Этот пост является переводом материала, опубликованного на сайте Amplitude.
Хотите внедрить Amplitude в свой продукт? Получите консультацию от агентства Adventum, партнёров Amplitude.
Больше про продуктовую аналитику