Каковы компоненты данных о событиях?

Это четвертая часть из пяти статей о клиентских данных. Вот первая, вторая и третья части.

Данные о клиентах состоят из данных о событиях и данных о сущностях — вы уже знаете это, если ознакомились с первой частью (Что такое данные о клиентах?).

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

Данные события

Поскольку вы, вероятно, покупали товары в Интернете, давайте начнем с примера электронной коммерции.

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

Путь покупателя, однако, не так прост, и может произойти несколько других событий, таких как:

• Товар просматривается
• Корзина просмотрена
• Товар удален из корзины
• Купон применяется
• Адрес выбран
• Способ оплаты выбран
• Заказ выполнен

И так далее.

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

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

Какие следующие два шага?

Рад, что вы спросили!

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

Что в имени?

Когда дело доходит до данных, все.

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

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

Вот почему:

Добавить в корзину, add_to_cart, productAdded, добавить в корзину, добавить в корзину, добавить товар — это разные способы определения одного и того же события.

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

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

Узнайте больше о настройке последовательной таксономии для ваших событий .

Компоненты данных о событиях

Есть два ключевых компонента события — объект (один или несколько) и свойства события.

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

В отсутствие уникального идентификатора, такого как user_id , данные события останутся анонимными, и невозможно будет узнать, кто выполнил указанное событие. Точно так же в контексте B2B SaaS, где пользователь потенциально может быть частью нескольких организаций, организация_id должна быть связана с событиями, чтобы знать, где происходят события.

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

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

Эти дополнительные фрагменты информации собираются в виде свойств события .

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

• Действие или событие, которое произошло
• Временная метка или точная дата и время, когда произошло событие
• Состояние или все другие свойства, связанные с событием (известные как свойства события).

Давайте посмотрим на событие Product Added (название в правильном регистре согласно структуре объектного действия для события Add to Cart ) и предположим, что оно было выполнено пользователем 1 января 2020 года в 10:00 UTC. Данные, собранные во время события, включают следующее:

• Действие: Продукт добавлен
• Отметка времени: 1577872800 (отметка времени Unix на ABZ 7.99 ( Состояние: 0123 ABZ 7.99 ( В этом примере свойствами, связанными с событием Product Added , являются user_id, product_id, price иquantity , каждое из которых предоставляет дополнительную информацию о событии. Отметка времени связана с событием, чтобы знать, когда оно произошло.

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

  Рекомендуемая таксономия для меток времени — это имя события, за которым следует «at»: product_added_at для события «Добавлен продукт».

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

  Вот окончательный взгляд на свойства, связанные с событием Product Added, и типы данных каждого из этих свойств:

  

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

  Дополнительное примечание: полезно помнить, что Теперь должно быть ясно, что сбор данных о событиях включает следующие этапы:

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

  Следующая (и последняя) часть этой серии посвящена процессу принятия решения о том, какие события отслеживать и какие данные собирать.

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

  Некоторые общие события и их свойства

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

  

  Типы объектов

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

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

  Данные объекта содержат свойства, связанные с объектом — если пользователь является объектом, вся информация о пользователе собирается в виде свойств пользователя.

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

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

  Типы данных объекта

  Сущностные данные можно разделить на следующие сегменты (также упомянутые в части 3 этой серии):

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

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

    Но разве данные о событиях также не генерируются из-за использования продукта?

    Конечно, свойства пользователя — это дополнительная информация, связанная с событием, собранная, когда событие происходит. Давайте посмотрим на событие Signed Up и его свойства:

    

    Как видите, все свойства, связанные с этим событием, предоставляют сведения о пользователях — сведения, которыми делятся сами пользователи ( first_name, last_name, электронная почта, телефон, страна ) или сведения, генерируемые автоматически ( signed_up_at, user_id ).

    Полезно помнить следующее:

    • Некоторые события, такие как Signed Up или Большинство пользовательских свойств, за исключением меток времени и идентификаторов, могут быть изменены. Пользователь может изменить свое имя, адрес электронной почты, телефон, местоположение, отрасль, должность и т. д. Но время регистрации (signed_up_at) или уникальный идентификатор (user_id) пользователь не может изменить.

    Свойства пользователя и свойства организации

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

    В контексте B2B SaaS пользователь и организация являются основными объектами, а собираемые события привязаны к пользователю или организации (или к обоим).

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

    Давайте рассмотрим некоторые общие пользовательские свойства, относящиеся к продуктам B2B SaaS:

    

    Когда пользователь является частью организации , многие важные элементы информации связаны с организацией, а не с пользователем.

    Некоторые общие свойства организации (также называемые групповыми свойствами ):

    

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

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

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

    Как только вы научитесь различать вышеперечисленное, станет легко добавлять новые объекты (такие как команды или проекты).

    Следующие шаги

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

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